tag:blogger.com,1999:blog-6466545174058573557.post1590059812761333575..comments2023-11-08T03:43:20.159-05:00Comments on Jerry on Java: 5 simple rules for securely storing passwordsJerry Orrhttp://www.blogger.com/profile/06855141821400610431noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6466545174058573557.post-85660367755522582922015-04-08T08:50:14.894-04:002015-04-08T08:50:14.894-04:00If all the passwords are stored in plain text, you...If all the passwords are stored in plain text, you can simply re-hash them all at once; nice and easy.<br /><br />When they are hashed using an inferior method (like MD5), I've done a phased approach, and it's actually fairly straightforward. You need to somehow identify users that were hashed using the older method: a 'hashtype' column, or the user has a null 'salt' column, whatever. Then when a user logs in, if their password is stored using the old method, the first step is to authenticate them. If authentication succeeds, you still have the plain text password they entered, so you can now hash it using bcrypt/scrypt/PBKDF2 and store it that way. <br /><br />So over time, as users log in to your system, you gradually transition everyone over to the stronger hash. It'd be ideal not to leave the inferior hashes around that long, but I think it's the best option.<br />Jerry Orrhttps://www.blogger.com/profile/06855141821400610431noreply@blogger.comtag:blogger.com,1999:blog-6466545174058573557.post-36536245069018041652015-04-07T23:09:24.119-04:002015-04-07T23:09:24.119-04:00This is good advice when designing new systems, bu...This is good advice when designing new systems, but what about legacy applications? Most of the time, programmers in industry aren't going to be designing new applications that store user credentials, they're going to be maintaining existing ones that were developed years ago. If you inherit a legacy application with a poorly-chosen password scheme, you've got four choices:<br />1) Leave it and hope you don't get compromised.<br />2) Replace the password storage code entirely and delete all the old hashes, which will require forcing all users to reset their password. Getting management approval for this can be difficult, if not impossible.<br />3) Somehow convince management to hire a cryptographer. Good luck with this one.<br />4) Use key stretching techniques to strengthen the existing hashes, e.g. by compositing hash functions. This removes the need to have all users reset their password, but it usually falls under "designing your own crypto".<br /><br />If you can't get management approval for 2 or 3, then what do you do?Anonymoushttps://www.blogger.com/profile/17353124638301463052noreply@blogger.com