Answers inline. On Sep 22, 3:36 pm, JasonG <[EMAIL PROTECTED]> wrote: > 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.
No, I said that you have to worry about session id security, regardless of who sets it. This IS a security related post, isn't it? > 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). Security isn't a yes/no proposal. I suggest you do a little investigation and e.g. make sure that your back end doesn't try to stuff session ID into the URL if cookies are disabled. > > 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, BCrypt merely adds some measurable security which is useful when you don't know what you're doing. There is a reason I've been strenuously suggesting it to you. > 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. See, that doesn't even make sense. You make two non-sensical points, and no good ones. 1. If your users table is compromised, *YOUR USERS TABLE IS COMPROMISED*. If he can set password, he can set user. Duh. 2. Aside from being void due to the point above, you are arguing security by obscurity, which sucks, and there is no obscurity to speak of in the first place. Either the attacker knows your hash scheme and he can hash username+password just as easily as just a password, or he doesn't, and he has to guess all parameters to the hashing scheme. There are a lot of them: - salt length - where's the salt stored? prefix or postfix, or separate field? - which hashing algorithm is used? - what initialization values were used to set up the algorithm? - which information was used to create the hash? I think you're trying to argue that your solution will stop the hacker because he'll never guess that he's supposed to hash username+password instead of just password. This is exactly my point: Thinking that you're actually making things better which such a tiny roadbump is exactly what screws you over; your security approach is like tossing peas at a steamroller to try and impede its progress. You build a big wall, and you don't get distracted by pointless exercises. "More isn't better" at all. Especially if you don't know what you are doing. Get it right once, and then stop worrying. In other words: Use BCrypt, and don't complicate matters. > (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). It's a huge deal. Because you can't. Given a username + a salt + a hash of (salt+username+password), **You CANNOT change any one of those individually without knowing all of them!** So, there IS NO WAY to change a username, unless the user enters their password. Let's say you are changing someone's username because he asks you to in an email. You can't do it without mailing back if he'd like to provide you a password. Your previously suggested potential scheme of hashing in everything in the users table is even worse. While the pain of locking in usernames forever is manageable, that's the exception, and not the rule. > > 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. I'm really getting tired of your fear mongering. BCrypt, the canonical C version, has a singular job to do. Given input A, it must always produce input B. jBCrypt is compatible with BCrypt. It has been fully tested. IThe developer of BCrypt does not have a team of marketeers behind him to advise him about useful versioning, but, jBCrypt is 'done'. It does the bcrypt algorithm. There will not be another version. It's also open source. If your management thinks that you rolling your own password hashing scheme is perfectly acceptable, but using a 4-page open source extremely well vetted source file is somehow breaking the rules, then, well, you got the inevitable security leaks coming to you for sheer boneheadedness. > Thanks, With this final posting I trust I've convinced any remaining readers that they should listen to me and not to you, so, for any further questions, I'll be charging tuition. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
