Industry best practices recommend storing passwords in unreadable form. Typically, this means either storing the passwords as a hash value or an encrypted value.
As a developer, you will have to understand that there are advantages and disadvantages to both methods and you will have to choose the one that works for your particular situation. The most common method (and the most recommended) is hashing.
The biggest strength of hashing – the fact that it is irreversible, is also its biggest problem. The problem manifests itself when you want to change the hashing algorithm. For example, you are currently using MD5 and want to go to a more secure and newer SHA2 algorithm. You cannot just write a batch process that goes through the database and “unhashes” the value and then “rehashes” the value using the newer algorithm.
What you have to do is:
- You have to wait for the users to login
- Hash the user supplied password
- Compare the hashes
- If they are the same, apply the newer hash algorithm on the user supplied password
- Update the database with that value
The key is the first step “you have to wait for the users to login”. For a small set of users, you can ask them to reset their passwords. But when you are looking at a few million users, it becomes very difficult. Some users may not login for months or years. Till they do, their passwords are stored using insecure algorithms.
Business owners will never allow asking millions of users to be forced to change their passwords. Even if they do, there will be lots of resistance.
If you used encryption, this situation is a bit easier to handle. You have the option of running a batch operation to decrypt the values and then re-encrypt them using the newer algorithm. This can be completely transparent to the user and your purpose is also achieved. The problem with encryption is key management. You have to store the keys securely and that can raise a lot of issues. But they can be solved with HSM (hardware Security Modules).
But some regulations require passwords to not be known even to administrators and care should be taken when creating your “forgotten password” logic. It can be very tempting to just decrypt the current password and email it to the user. For a lot of reasons, which I will not go into here, that should be avoided.
I have only dealt with this dilemma in the context of storing passwords. There are many different scenarios that can pose an issue when deciding which way to go. You will ave to decide on a case by case basis.
PS: One solution that I suggested for the hashing issue described above is to encrypt the hashes using a secure encryption method. This ensures that all the values are secure. Then when the users login, decrypt the encrypted value (you will get the hash), hash the user supplied password and then compare the hashes.
After this, you can choose to just leave the values as they are or just move to the newer hashing/encryption algorithm by directly hashing/encrypting the user supplied password using the newer and more secure algorithm.