Haszowanie haseł — nigdy nie przechowuj tekstu jawnego

If you store passwords as plaintext, one database leak hands attackers every account at once. The first rule of auth is simple: never save the raw password. 🔒

You protect passwords with hashing, a one-way transform. Unlike encryption, a hash cannot be reversed back into the original password, even by you.

Flask ships with Werkzeug, which gives you two helpers for password security. You import them straight from its security module, no extra install needed.

When a user registers, run generate_password_hash on their password and store only the result. The plaintext never touches your database.

generate_password_hash adds a random salt for you. That is why two users with the same password get totally different stored hashes.

At login you cannot un-hash anything. Instead you call check_password_hash with the stored hash and the typed password to get a True or False.

Remember the order: the stored hash comes first, the user-supplied password second. Swapping them silently breaks every login attempt.

By default Werkzeug uses a strong, slow algorithm on purpose. Slowness is a feature here, because it makes brute-force guessing far more expensive.

Your user table needs a single password_hash column. You never need a separate salt column, since the salt is baked into the hash string itself.

A clean trick is to put a set_password method on your User model so hashing lives in one place and your routes stay tidy.

Even during debugging, do not print or log the raw password. A stray log line can leak credentials just as badly as a database breach can.

You need to confirm a login. Which call should you use?

You learned to hash with generate_password_hash, store only the result, and verify with check_password_hash. Plaintext passwords are gone for good. 🎉