> 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.
No. I'm making the point that in a well organized environment, the database and application are separated and through division of responsibility your database people don't have access to your application just as your application people don't have access to your database (beyond what has been granted for operation of the application, obviously). Your hacker doesn't have to be someone from the outside and it doesn't have to be a developer. It could just as easily be a DBA (or someone acting the part). A DBA working alone will typically not have the knowledge of what goes into the hash - nor will a typical DBA even have the knowledge of how to produce the hash. By just hashing the password you make it pretty easy for him to get in using skills even a novice DBA already has (i.e. select, insert). Your entire argument seems to be based on the assumption that your attacker is intelligent and skilled and a developer - without consideration for the fact that there are many more people out there who are none of these things but who may be motivated to hack into an application just the same. No matter what you do - yes there will always be some way your system can become compromised. The goal of security is to make that job as difficult as possible without over- encumbering the application itself. IMHO if your application is deployed using division of responsibility best practices, then you should take advantage of that fact by ensuring your attacker requires knowledge of more than just one piece of the puzzle in order to break in. I think assuming your attacker will only come from one direction or that your attacker is only after your password or that your attacker will always be someone skilled at hacking or a developer is foolish. Why make it easy for even an unskilled DBA to break in with no knowledge of how the application or its security? > 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. Right. Exactly. In most real-life production systems, this is perfectly acceptable, and in fact it is often desired. As for the "fear mongering"... it was a simple and perfectly relevant question for this thread. Has anyone (and this means other people as well as Reinier) heard of a commercial or otherwise fully supported Java implementation of BCrypt? The reason for this question is also simple --> jBCrypt in its current state is a hard sell to any regulated organization's legal/audit department. I'm not bashing BCrypt. I'm not saying it is a bad product or a weak algorithm or that it should be avoided. I'm simply asking if there exists a Java implementation that is a little easier for legal/audit to swallow that jBCrypt. If the answer is "no", then just say so. There is no need for insults or name-calling. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
