Dearest Reinier, I'm a little perturbed by your response.
Let's start with session handling. I had initially made a point that if you are using a J2EE back end, then you don't have to worry about handling session IDs because that is pretty much handled for you. You continue to make some sort of cryptic (pardon the pun) response to this. Let's try a straightforward question in hopes of a straightforward answer: Are you advising GWT developers to come up with their own session key handling when using a J2EE back end? (A simple "yes" or "no" will do). Next - on to hash input. Again, I'd like to steer away from the "BCrypt solves world hunger" argument and focus on my original advice, which was to hash more than just a password. One reason for this argument stems from my understanding that, generally speaking, "more is better" where key material is concerned (hence longer passwords are better?)... and if you are going to encrypt a password anyway, you can leverage that same mechanism to validate additional important information (such as a user's login, role, etc...). Let's take a look at a possible scenario where the person cracking into your system (perhaps a DBA) is after something other than your password - maybe that something is to invoke some sort of function rather than obtain data in the database. Whatever that something is, let's assume for a moment that it is easiest obtained through the administrative role within the application. Somehow this person has managed to gain access to the user table in your database server (but not your app server), and copies his hashed password into the administrators password field. What happens next? Can he now get into the application as the administrator? Answer: Most likely "YES". Why? Because the hashed password used only the cleartext password (+ random salt) as key material. Unless I have overlooked something, even BCrypt does not prevent this problem. He didn't even have to guess your password in order to hack into the admin account for your application. However... if the hashed password had been formed using username +password input as I suggested in the beginning, then the copied hashed password in the above example will not work. The attempt to hack into the admin account will fail because the password will only validate if used with the correct username. Note also that the same mechanism could be used to validate other information such as a person's role. Think of it as a parallel to the MD5 or PGP signatures used to validate downloads and perhaps you will see my point. So those were my two pieces of additional advice and I'm sorry but I still don't see any reason to withdraw them. Java app servers do a half-decent job of session ID management and I will continue to use them until I hear otherwise. As for the username+password argument... true, you made a valid point that a salted hash does not give you an easy "lookup token", but I also think the benefit of credential validation should not be overlooked even if it means changing your username is slightly more complex (it really is not a big deal to regen a password hash on a username change so I have to say that is a pretty weak argument). On a final note - I read up on jBCrypt and it looks great, but .... I would, however, add a concern that jBCrypt is currently a version 0.2 product produced by an individual, with a license containing no sort of warranty. This is fantastic for average Joe building a web application at home or for open source projects - but impractical (and possibly not even an option) for anyone building applications for financial, insurance, health care, government, or any other highly regulated vertical. There's that whole indemnity issue the lawyers and auditors will usually fight over unless they have already approved it. I would be interested in knowing if anyone has heard of a commercial or otherwise fully supported Java implementation of BCrypt. thanks, J On Sep 19, 8:15 pm, 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 Google-Web-Toolkit@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
