If I have an application that is using a less secure method for storing passwords, such as SHA-1, how would I go about converting to SHA-256 or SHA-512?

  • SHA-256 or SHA-512 is not necessarily more secure than SHA-1, assuming that we are talking about human passwords. Common attacks on SHA-1 take the form of a brute force or dictionary attack, in which every possible permutation within the known password parameters (such as max length, if you had one) is hashed to try and generate the same hash value that is stored. So the only thing that matters is the length of the input string (longer string means more permutations). You have confused certificate/secret-based encryption with password hashing.
    – Jeremy
    Jul 6, 2011 at 20:35

3 Answers 3


You mean something like a web application that is storing hashes rather than password for login? You won't be able to convert the SHA-1 hashes to anything else very easily.

You could store the new SHA value in your database as users log in, updating each user as they present their correct password, either making a marker in the users table as to what kind of hash their password is stored as, or just trying them in a preferred sequence. New login would look something like this:

  1. Hash the password with the preferred hash
  2. Authenticate, if correct, log in the user
  3. If not correct, try hashing with sha1 instead. If this is correct, update the database with the preferred password and log the user in.
  • 1
    I would rather advise to have two separate columns, one for SHA-1, the other for SHA-512. This is because those different hashes have different lengths, so you'll be unable to store the second one in a column created for the first one. Jul 6, 2011 at 19:51
  • 2
    Why not just make the field wider? That's easy enough to do with an alter table. Having two different fields just means you're wasting one or the other, and if you leave the sha1 in it just defeats the purpose of converting in the first place :)
    – Collin
    Jul 6, 2011 at 19:53
  • 1
    At some point you'll want to know if you can drop the SHA-1 check routine and it'll be faster/easier to check if there are any unpopulated SHA-512 rows. Jul 6, 2011 at 20:19
  • I'm lucky in that the application is only released to a few beta customers right now. It was my mistake not to research the better security protocols earlier, but I'll be able to switch the beta customers over before we go to general release. Jul 6, 2011 at 22:24
  • 3
    Check for empty values is no more difficult than checking the length of the hash. Don't store both, it defeats the purpose of switching over. Jul 6, 2011 at 22:27

Simply update your table to indicate which encryption method is used and force users to change their password after next login. They can even reuse the existing password, but then you can indicate in your table which method the password has was created with.

  • 2
    -1 for unnecessarily inconveniencing ALL the users. Jul 6, 2011 at 20:13
  • @Kevin It is safer to do it this way than refactoring the login routine. If the system has a password expiration policy already in place, you could wait for that. Jul 6, 2011 at 20:17

(Expanding upon what Collin and MainMa wrote..) Add a column to the table for the SHA-512 hashes. During the login process, see whether the SHA-1 or SHA-512 field is populated for the user. Validate using that field. If the field is SHA-1 instead of 512, display some screen describing "new security features" and ask them to input the same or a new password. Store this hashed password in the SHA-512 column and remove the SHA-1 value. Keep this logic until all users are using SHA-512.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.