Hash & Security

MySQL Password Hash Generator

Generate a MySQL 4.1+ PASSWORD() hash for legacy MySQL servers.

Rate this tool

How to use the MySQL Password Hash Generator

  1. Type or paste the password in the box.
  2. The 41-character hash appears as you type, starting with an asterisk.
  3. Copy it straight into your legacy mysql.user row.

About the MySQL Password Hash Generator

This is MySQL’s PASSWORD() function as it has worked from MySQL 4.1 onwards. The algorithm is SHA-1 applied twiceSHA1(SHA1(password)) over the raw bytes — with the result written in uppercase hex behind a leading asterisk, giving 41 characters in total. The asterisk is not part of the digest; it is a marker that tells MySQL this is the 4.1-era format rather than the shorter 16-character hash that came before it. If you want to see the underlying primitive by itself, our SHA-1 generator does one pass.

Note what is missing: there is no salt. Two accounts with the same password get the same 41-character string, and SHA-1 is fast, so this format offers very little resistance to an attacker who has your mysql.user table. MySQL knows this — PASSWORD() was deprecated in MySQL 5.7 and removed entirely in MySQL 8.0, which uses caching_sha2_password as its default authentication plugin instead.

So the honest use case is legacy: you are working with an old server, or you need to set a mysql.user row directly rather than going through SET PASSWORD, or you are migrating accounts off a system that still stores these. That is all fine. What you should not do is borrow this format for your own application’s passwords — it is unsalted, fast and deprecated by its own vendor. Use bcrypt instead.

Frequently asked questions

Why does the hash start with an asterisk?

The asterisk marks the MySQL 4.1+ format and distinguishes it from the older 16-character pre-4.1 hash. It is a prefix, not part of the digest — the hash itself is the 40 hex characters after it, for 41 in total.

Does PASSWORD() still exist in MySQL 8?

No. It was deprecated in MySQL 5.7 and removed in MySQL 8.0, which uses caching_sha2_password by default. This tool is for legacy servers and migrations.

Why is unsalted and fast a problem here?

With no salt, identical passwords produce identical hashes across every account, so one precomputed lookup table attacks the whole table at once and duplicates are visible at a glance. SHA-1 is also extremely fast, so a stolen mysql.user table can be attacked at enormous rates. Double-hashing does not meaningfully slow that down.

Can I use this for my application's user passwords?

Please don't. It is unsalted, fast and removed from modern MySQL. Store bcrypt or Argon2 hashes in a normal column instead.

Is my password stored?

No. It is sent to our server to be hashed, because browsers cannot compute SHA-1 in this exact double-pass form, then hashed and discarded immediately — never logged, never stored.