[BBLISA] Reusing Passwords on Different Sites Should be OK

[John Stoffel]

>>>>> "Edward" == Edward Ned Harvey (bblisa4) <bblisa4 at nedharvey.com> writes:

>> 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.

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

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

Hmmm... I wish I had more mathematical chops to comment here... I'm
sure I'm missing something.

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

Exactly.  

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

But an attacker has all three values of the salt, right?  How do you
mix the salt into the bcrypt() hash of the password?  Esp since the
user only gives you back the encrypted value?  

Sorry, I'm not being clear here.  

User Bob at myemail.com logs into foo.com with password "Simple123".  

He also logs into bar.com with the exact same username and password.

The only difference between the two sites is the salt bcrypt("foo.com"
+ "sha512("bob at myemail.com") + pub_rand()) and how that salt it mixed
into the hash sent to the site.  

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

So what do you do when it's the cutover date between two time periods?
Do you try to use both valid certified random numbers?  

I think I see how using such a big, but easy to compute salt makes it
much more secure, but I still semi-suspect that you also need to have
a private/public pair from the server side as well that helps mix up
the encryption.

Gah... cryptography always makes my head spin.  :-)

Thanks for your comments, I appreciate the time you're spending on
this.

John