Storing passwords — hashing that is slow on purpose

Why is bcrypt the right choice for a password when SHA-256 is stronger?

Because they are built for opposite goals. SHA-256 is designed to be fast, which is what you want for integrity and exactly what you do not want here — a GPU tries billions of SHA-256 guesses a second. bcrypt, scrypt and Argon2 are deliberately slow and tunable, with a work factor you raise as hardware improves, and they salt every password so two identical passwords do not produce the same hash and a rainbow table is worthless.

The number that makes it land: the same GPU that does billions of SHA-256 hashes a second does tens of thousands of bcrypt hashes. That ratio is the entire security margin.

What is a salt, and what is a pepper?

A salt is a unique random value stored alongside each hash. It does not need to be secret; its job is to make every hash unique so an attacker has to attack each password separately rather than the whole table at once. A pepper is a single secret value kept outside the database — in an environment variable or a KMS — and mixed in, so a stolen database alone is not enough to start guessing.

What is the difference between encryption and hashing?

Encryption is reversible with a key and exists so that someone authorised can read the data back. Hashing is one-way and exists so that nobody can, including you. Passwords are hashed because the system never needs the original — it only needs to check a candidate. Anything you must be able to display again, like an API key you show once or a stored document, is encrypted, and then the real question becomes where the key lives.