Why isn't encrypting the password enough to keep it safe if the database leaks?

Encrypting the password column does not make a stolen database harmless, because encryption is reversible and your login code must reverse it. The property you need is not secrecy but irrecoverability: somebody holding the stored value must not be able to produce the password. Encryption cannot give you that while it still lets your service check a login.

That distinction is easy to miss because both operations look like checking a password from the outside. At login, the server is handed a candidate and must answer yes or no. Encryption answers by going backwards from the stored ciphertext to the original and comparing. Hashing answers by going forwards from the candidate and comparing tags. The first puts the password back into memory every time, and anyone who can run the same code can do the same. The second never puts the original back, even for the legitimate service.

The natural guess is that an unreadable blob is safe so long as the key is secret. The failure is not that encryption is weak. It is that the key has to be available to the running service at the moment somebody logs in, so it lives in configuration, an environment variable, or a vault the service reaches with credentials that are themselves in configuration. Whoever copied the table was inside far enough to read a database; the step to the service configuration is short, and in many backup paths the key is in the same archive. With the table and the key, the attacker does not guess. They decrypt each row and read the password.

Store a one-way value with a per-user salt and a cost parameter. At login you recompute the value from the typed password and the stored salt, then compare tags. You never need the original password back. An attacker holding the table has a tag and a salt, not a ciphertext and a key, so the only way back is to guess a candidate and compute the same function. That is still possible, which is why the function must be slow. A fast hash is better than encryption but not enough on its own: it turns one decryption per row into a guessing race, and a fast function makes each guess cheap. The salt matters for a second reason. To test one candidate against all 40,000 rows with a different salt per row, the attacker needs 1 × 40,000 = 40,000 computations. With no salt, one computation can be compared against every row, so one lucky guess can open every account that reused that password.

There is a case where encryption is right: a credential you must recover later, such as a token for a third-party service you sign in to on the user's behalf. Then you have no choice, and the key belongs in hardware that will not release it. A password you only ever need to check is not that case. If the key were genuinely kept out of every backup and inside hardware the attacker cannot reach, a stolen table alone would be less damaging. But that is a narrower assumption than the one worth designing for, and the reversibility remains: anyone who can make your service check a login can also make it decrypt, if they have reached the service.