[BBLISA] Reusing Passwords on Different Sites Should be OK

[Edward Ned Harvey (bblisa4)]

> From: John Stoffel [mailto:john at stoffel.org]
> Sent: Thursday, September 17, 2015 5:21 PM
> 
> I'm just wondering how they generate the salt or seperate secret for
> each site, so that even though your password bcrypts to 'some long
> string', how do you keep it different enough for each site?
> 
> So if I goto foo.com, and bar.com using the same password, how do I
> use a determanistic mechanism to hash/crypt/obfuscrate foo.com + my
> password so that it's hard for attackers, but trivial for me?
> 
> That wasn't well explained at all on their site (I'm not going to
> watch videos...) at all.  I like the idea... I just wonder about the
> details.

Yeah, that's in the tech video. Summary:

There are three purposes for a salt. (1) Prevent easy detection of password reuse by different users. (2) Prevent easy detection of password reuse on different servers. And (3) force a time constraint - an attacker who gains the backend password file or database or whatever cannot begin the brute force until after the breach has occurred.

So how can we satisfy all these characteristics, when salts are exposed to unauthenticated users?

Let the salt be generated from: (1) the username, (2) a host identifier CBCryptHostID, and (3) certified random number published by certificate authorities. 

The certified random number is: Participating CA's generate a random number, timestamp, sign and publish. Do it periodically, say once a month. The CBCrypt servers fetch and redistribute those random numbers to clients. When the clients check the signature and timestamp, they can be assured that it's truly a random number first seen by the world at a particular date, so we have effectively limited the window of time that anybody could have used for brute force.