>>>>> "Edward" == Edward Ned Harvey (bblisa4) <[email protected]> writes:
>> From: John Stoffel [mailto:[email protected]] 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 [email protected] 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("[email protected]") + 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 _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
