Password Management
Practice this topic in a realistic system design interview
Suppose we are building a login system. A user signs up with an email and a password.
The simplest approach is to store the password in the users table exactly as the user typed it. When they log in, we compare the submitted password with the stored one. This works.
But now imagine the database gets leaked. Maybe through a SQL injection bug, a misconfigured backup, or a stolen admin credential. The attacker now has every user's password in plain text.
And the damage does not stay inside our system. Many people reuse the same password across multiple websites. So the attacker can try those email and password pairs on email providers, banks, and shopping sites.
This is why password storage is designed around one assumption: at some point, the database may be stolen. Our goal is to make the stolen data as useless as possible.
In this chapter, we will look at how systems should store user passwords, why hashing alone is not enough, and how salts, slow hashing algorithms, and good reset flows protect users even when the database is stolen.