If you are storing user-entered passwords in your system, it’s imperative to keep those passwords as secure as possible. With all the systems that require passwords, users often end up reusing one or two passwords for many sites. As users also often reuse usernames (or use a single email for all sites) that means if you have user information for logging in on one site, you then have information for logging in to many sites as that user. Example: even if you’re just a site where users can log in and create silly little drawings, if a user can enter their own password on your site, there’s a good chance you can use that information to get into that user’s online email, or possibly even their banking sites. So, good security rules would dictate treating that password as sensitive personal data, even if it’s not sensitive in your context. In face, I think this might even apply if your system assigns the user a password. If you are forcing the user to accept a new password, you might expect that once they have memorized that password they might start reusing THAT password elsewhere. (if anything this sort of reuse is probably MORE likely with the non word, mixed case, mixed letter and number high-security passwords, since people can remember very few of those and a lot of sites want that kind of thing)
So, what to do to treat passwords well? One-way hash it-nothing less is acceptable. You really don’t want anybody to ever be able to look at that password again.. remember, that password is black-hat hacker’s gold. If the user forgets their password, they can reset it.
Some organizations have a policy of a clear-text password for “good customer service” (if the user calls to say they forgot their password, the person answering the call can give them their password again) this is a REALLY bad idea-it could be someone impersonating the user, and even if it’s not, the person answering the phone is one more person unnecessarily exposed to that password. So, encrypt the password, and rethink the customer service angle. If a customer calls asking for their password, say something like “To protect your privacy and identity we do not store your password in a way that is retrievable by me or anyone else, so I cannot tell you your old password. However, I can reset your password for you, and you should receive the information to reset your password in an email. Please do not tell me your new password; I do not need to know it.”
Another argument sometimes used to store passwords in clear-text or a reversible encryption is so that administrators look up passwords so they can can log in to the system as that user to debug sepecific user-reported issues. While verifying issues at this level is a good idea, allowing admins to access user passwords is a bad idea, as they should NOT see these passwords, and it requires passwords to be stored in a viewable format. Asking users for passwords when issues appear is not ok either-the admin should not need any access to the passwords at all. However, theses admins have a legitimate need-the right solution is to build into applications an impersonation system. From an admin area, an administrator would have a backdoor into the system that allows them to access the application authenticated as a particular user-no literal logging in as that user required, so no password needed.