I have seen a number of independent reviews of BCrypt, I have talked to security people I trust, and, for the big finale: I reviewed it myself.
My assessment of BCrypt is: It's as secure as blowfish. I have also reviewed blowfish, but, that's a bit above my station. Fortunately, blowfish is designed by Bruce Schneier, -and- gone through a serious amount of peer review, so if you don't trust Blowfish, then you don't trust anything, and the only way to have piece of mind is become an expert crypto researcher and review -everything- yourself. Feel free to, but I think we're edging just -a tad- away from the intents of the LoginSecurityFAQ (namely: Practicality). BCrypt is not really a 'hash' in the traditional sense. Hashes are designed to have two properties. In order of importance: A) It is effectively impossible to generate some content which so happens to hash to the same value as given content, other than brute forcing. B) It is fast to calculate the hash. B is not unimportant. For example, git names every last little thing you do with a SHA-1 hash. If you go and checkout a couple of gigs worth of project, you really don't want that process to take significantly longer just because your CPU is choking on all the hashing it needs to do. Unfortunately, for password hashing, B is really bad. You want a hash which is -slow- to calculate. Which makes this a bit of a niche; there aren't many places where you really want slow hashing. (The reason slow hashing is good for password hashing, is because it makes the creation of 'rainbow tables' and brute forcing a limited set of likely passwords impossible or at least very very expensive). That principle is what BCrypt was built around: You can configure the salt factor size, which has very direct consequences for calculation time. The default is 10, but if you crank that up to, say, 25, then just calculating one hash takes literally years on a standard CPU. The idea is to set it to the highest value your CPU can handle without getting bogged down / what you need. I've gone with the standard 10 which is already extremely secure, but if you have very very sensitive data, you can go for 12 to 15. (If you read this as: Longer passwords take longer to hash, don't worry - that's not the case. The time to calculate is dependent on solely on the size of the input salt factor, which you set). Assuming the algorithms are up to snuff, BCrypt beats SHA-256 just because its a lot slower (and, very useful, -configurably- slower). On Sep 20, 2:23 pm, al0 <[EMAIL PROTECTED]> wrote: > I have not seen any proof that BCrypt works :) Yews, the authors > stated that it is great, but who believes to authors? Have you seen > any independent assesment of BCrypt? Or it comparision with other > modern hashes (e.g. SHA-256)? > > On Sep 20, 2:15 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > > > Answers inline... > > > On Sep 19, 3:12 pm, JasonG <[EMAIL PROTECTED]> wrote: > > > > First of all, I don't understand your (A) response. I said "you > > > don't need to worry so much about passing session IDs since the app > > > server will pretty much handle that for you"... and your response > > > seems to just reiterate what I said - but you stated it in a manner as > > > though you were disagreeing with me. I don't get it. > > > From a security point of view, which is what this thread is about, who > > does the sessionid passing is mostly immaterial. It should also be > > noted that the first servlet engine for tomcat started the boneheaded > > 'sessionid in the URL' security fart, so the userbase size of a j2ee > > container is no guarantee that the security is sorted out properly. > > > > Secondly, BCrypt is not mentioned in the original author's post at > > > all, nor does it seem to be mentioned in the linked guide to > > > security. > > > Huh? (j)BCrypt is the first link mentioned on the LoginSecurityFAQ. I > > didn't just add that - that's been there since I posted the second > > draft, a long long time ago. It wasn't mentioned in the original > > author's post, which is exactly why *I* mentioned it. BCrypt is a > > fantastic idea. You should be using it when storing passwords in a > > database. > > > > I was not intending to write an all encompassing guide here > > > but perhaps I should have been a little more clear. I said "in > > > addition to what others have said" and "regardless of which hash > > > algorithm". Put those two together and this was meant to be taken > > > as: it doesn't hurt to concatenate the username+password+some-other- > > > string on hashed passwords stored in the DB, regardless of algorithm. > > > No - you don't get it, evidently. > > > 1) You -cant- query the database for HASH(username+password), because > > if that worked, you by definition have really bad saltless hashing. So > > what's the point, then? Why store the username as well? You're just > > making it harder to rename usernames (bad), and... > > > 2) You risk collisions. Assuming that the idea is that this username > > +password combo is somehow a unique key, collisions can happen, and > > that's no good. > > > But mostly: > > > 3) my advice is: Use BCrypt. Your advice is: hash on username+password > > instead of just password, which is much worse than listening to me. > > Your point is basically: If you forget to listen to any (good) advice, > > then listen to MY advice. This makes no sense; the premise was > > already: Programmer did not listen to ANY advice. We've got three > > options here: > > > A) Programmer doesn't listen to advice. Okay. We can chat here until > > the end of days, but he's not listening. Shame, but, we can't stop > > him. > > > B) Programmer listens to the only advice that mattered: He uses > > BCrypt. Peachy. Your advice is now irrelevant and in fact slightly > > bad: He just lost the ability to rename his username and needs the > > username in his check routine which clutters his parameter lists. > > > C) Programmer wanted to listen to advice but the chatter is starting > > to confuse him, and he turns into #A: He stops reading and just goes > > his own way, most likely doing it very wrong. This is important, as > > java tends to suffer a lot form this principle: Don't overwhelm people > > with 15 answers. Just give the best answer, and if that particular > > answer doesn't fit the asker's needs, let him get back to you about > > that. Don't throw half a book at him, especially if most of the advice > > in it is pretty much irrelevant or useless. That's another very good > > reason why you shouldn't mention your username+password hashing > > scheme. It doesn't add anything useful to the discussion: Either the > > user is doing his salt/hashing correctly, and your scheme doesn't add > > anything, or he's not doing it correctly, and your scheme adds very > > very little. > > > > Why? Because if you happen to be using a weak algorithm or even a > > > strong one for which a weakness is later discovered, you are better > > > off > > > Just to set you straight on this one: If BCrypt's salt/hash concept is > > somehow broken, then a username+password hash is equally or even worse > > broken; BCrypt already uses different source material for the same > > passwords by different users. This is like screwing a highschool > > locker padlock on a $10,000 dollar safe door. If someone is going to > > get access to the safe's contents, you can be certain the padlock > > didn't stop the criminal for even a second. He either bypassed the > > lock entirely, or he got the code from someone, or he actually can > > pick locks; and if he can pick a safe, he can open that padlock in an > > instant. > > > In the mean time, the padlock, which has added absolutely no value to > > your security setup, IS annoying you everytime you want access to the > > safe. Hence, just get rid of the bloody thing, it's making it harder > > for you in operation, and its making it harder for a security analyst > > because it obscures the true protection measures with irrelevancy. > > > > A time could come when BCrypt "was" as well. > > > Again, your scheme adds nothing. Stop confusing people with > > fearmongering talk about BCrypt someday failing. DES never failed; > > it's just become too easy to brute force. BCrypt has a built in > > complication factor. You can screw it up as far as you like, though at > > some point authenticating a password starts taking a month. > > > > could you please restate some > > > useful advice or a best practice in such a manner? > > > Yes. Generic advice for security blows, other than: You suck at it, > > listen to the experts. Specifically: You should listen to very > > specific advice, complete solutions where the entire stack, soup to > > nuts, has been vetted by countless experts. 'generic advice' should > > consist of about 2000 pages of security research along with extensive > > testing to see if you grokked all of it. That's not really feasible, > > now is it? Or, to give a two word summary: > > > ** USE BCRYPT ** > > > and don't get distracted with your pet schemes that don't work. > > > > Thanks, > > > As always, > > > you are very very welcome. > > > -- Reinier "gently nudging the casual reader back onto the straight > > and narrow with a velvet touch" Zwitserloot --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
