Bcrypt, Argon2 and PBKDF2 hash generator

bcrypt is an algorithm for storing passwords. What gets stored is not the password but its hash: a 60-character string that is calculated slowly on purpose and with a random salt, so trying millions of passwords is very expensive. When someone signs in, the system calculates the hash of what they typed with the same salt and cost, and compares it with the stored one.

OWASP recommends 10 as a minimum, and more if your server can take it. The cost is an exponent: each extra point doubles the time, and 10 means 1,024 rounds. PHP raised its default from 10 to 12 in version 8.4. Pick the highest value at which signing in still feels quick on your server and, if you are changing a user’s password in an existing system, use the same cost as that system so all the hashes behave the same.

In practice, none: they are versions of the same algorithm. $2a$ is the original; later came $2y$ (PHP’s mark for its fixed implementation) and $2b$ (OpenBSD’s, since 2014, which fixed a bug with very long passwords). For passwords of up to 72 bytes a correct implementation gives the same result with all three, and current libraries accept all three. Pick the one your system writes: $2b$ in Node.js and Python, $2y$ in PHP and Laravel, $2a$ in Spring Security.

Argon2id is OWASP’s first choice for new systems: besides being slow it uses a lot of memory, which makes it more expensive to attack with graphics cards. bcrypt is still a good choice and is supported by almost every language, although it only reads the first 72 bytes of the password. PBKDF2 is the simplest and the one some standards require, but it needs many iterations (OWASP states 600,000 with SHA-256). In practice, use the one your system already knows how to check: a hash your application does not understand is of no use to you.

Because every hash carries a new random salt inside it. All of them are valid for the same password: the system reads the salt from the stored hash, calculates again and compares. The salt makes two users with the same password have different hashes and makes tables of precomputed hashes useless.

No. A password hash only works one way. All anyone can do is try passwords one by one and compare, which is why these algorithms are slow. If a password has been lost, the right thing to do is replace it with a new one. And if you want to know whether a specific password corresponds to a hash, use the “Verify hash” tab.

The hash is calculated in your browser, in a thread separate from the page, and the password is not sent to our servers or saved anywhere: not in cookies, not in browser storage, not in the page address. It disappears when you close or reload the page. The only thing we measure, anonymously, is which algorithm is used, never the password or the hash. Even so, do it on a device and a browser you trust, and if you are changing someone else’s password, the best approach is to set a temporary one that they have to change when they sign in.

bcrypt only reads the first 72 bytes of the password and ignores the rest, so two passwords that match in those 72 bytes give the same hash. It is not 72 characters but UTF-8 bytes: an “ñ” takes 2 and an emoji 4. The tool warns you when you go over and calculates the hash from the first 72 bytes, as the real libraries do. For long passwords, use Argon2id or PBKDF2, which have no such limit.

Generate the hash with the same algorithm and values your system uses (look at the hash of an existing user: its prefix and cost tell you). Then open “Build the SQL statement”, enter the table, the column and the condition, and copy the UPDATE. Before you run it, check that you are connected to the right database, that the condition affects a single user and, better still, do it inside a transaction. Some systems add steps of their own, such as a pepper or a pre-hash of the password, and then this hash will not work. If you run the SQL from a terminal, wrap it in single quotes so the shell does not interpret the $ signs of the hash.

For Django choose “PBKDF2-SHA256 (Django)”: the result has the pbkdf2_sha256$iterations$salt$hash format that Django stores in the password column. Django accepts hashes with fewer iterations than its current value and upgrades them the next time that user signs in. For Flask choose “scrypt (Werkzeug / Flask)”, which is the default format of generate_password_hash.

Yes, in the “Verify hash” tab: paste the hash and type the password. The tool recognizes the algorithm from the start of the hash (bcrypt, Argon2, Django PBKDF2 or Werkzeug scrypt) and tells you whether it matches. Hashes in other formats, such as unsalted MD5 or SHA-1, are not supported.