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