It's interesting how much discussion there is here on ynews about the "Right" way to handle paswords... if it's so simple, why can nobody really agree?
A few things to consider.
1) storing plaintext passwords is a bad practice. It's fundamentally a bad practice because if someone gets ahold of a database table containing your names and passwords, you immediately have to change them all. You're broken, wide open.
2) storing passwords encryption, where the necessary apps have the keys, but the DB itself only has encrypted data. now if someone steals your DB, your passwords are relatively safe, unless someone ALSO managed to break into the right production app server and extract the key. This is acceptable for storing credit card numbers for PCI compliance... should be good enough for your website.
If the DB is breached, you are still going to through a password changing exercise, but you have time to do it without going into panic mode.
3) Hashed passwords + salt. It's worked well in unix for years. It's fine for web apps where you don't want to be able to recover a password, only reset it. Note the salt is really important here... it lives in your app, not in your DB. The idea is that if someone gets ahold of your DB, again, they can't just brute-force what they see because they don't know how you've salted it. You've made it much harder.
A few things to consider.
1) storing plaintext passwords is a bad practice. It's fundamentally a bad practice because if someone gets ahold of a database table containing your names and passwords, you immediately have to change them all. You're broken, wide open. 2) storing passwords encryption, where the necessary apps have the keys, but the DB itself only has encrypted data. now if someone steals your DB, your passwords are relatively safe, unless someone ALSO managed to break into the right production app server and extract the key. This is acceptable for storing credit card numbers for PCI compliance... should be good enough for your website. If the DB is breached, you are still going to through a password changing exercise, but you have time to do it without going into panic mode.
3) Hashed passwords + salt. It's worked well in unix for years. It's fine for web apps where you don't want to be able to recover a password, only reset it. Note the salt is really important here... it lives in your app, not in your DB. The idea is that if someone gets ahold of your DB, again, they can't just brute-force what they see because they don't know how you've salted it. You've made it much harder.