I'm setting up a new web service and need to decide how to protect stored passwords. The main options I'm considering are: 1) simple unsalted hash (e.g., SHA‑256), 2) salted hash (adding a unique random salt per user), and 3) full encryption of the password field. Each has trade‑offs in terms of security, performance, and recovery. Which approach do you prefer for a typical production environment, and what reasons drive your choice? Looking forward to your thoughts.
Preferred way to store user passwords: plain hashing, salted hashing, or encryption?
👁️ 73 görüntüleme💬 2 cevap❤️ 0 beğeni
2 Cevap
I always go with a salted password hash using a purpose‑built KDF like bcrypt, Argon2 id, or PBKDF2 rather than a raw SHA‑256 or any kind of encryption. A unique random salt per user stops rainbow‑table attacks, and the work factor makes brute‑forcing costly without hurting normal login latency. Encryption isn’t a good fit because you’d have to manage decryption keys and you’d end up being able to recover the original password – something you really don’t need and that just adds another attack surface.
In practice I generate a 16‑byte salt, feed it to Argon2 id with a moderate memory‑cost and parallelism, and store the resulting hash (including the salt and parameters) in the DB. If you ever need to “reset” a password you just send a reset link instead of trying to decrypt anything. This setup gives you strong security, minimal performance impact, and no extra key‑management headaches.
When I first rolled out the auth layer for a SaaS product a couple of years back, we actually started with a plain SHA‑256 hash because it was the quickest thing to get working. It felt fine until a teammate pointed out that anyone who got hold of the DB could run a massive rainbow‑table attack on the hashes. We switched to a proper salted approach using bcrypt, and the change was painless – we just added a random 16‑byte salt per user and let bcrypt handle the work factor. The extra CPU hit was negligible for our traffic, and we got the peace of mind that even if the DB leaked, cracking passwords would be prohibitively slow.
I’ve never used full encryption for passwords because you end up needing to store the decryption key somewhere, which re‑introduces a single point of failure. If you ever need to “recover” a password, the usual workflow is to reset it via a token, not to decrypt it. So for a typical production environment I’d go with a modern password‑hashing algorithm (argon2id or bcrypt) combined with a unique per‑user salt (and maybe a global pepper). It gives you strong resistance against offline attacks, minimal performance impact, and you don’t have to worry about key management.