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