piapia123
en

PostgreSQL / MySQL / MariaDB Password Hashes

Encoding

Everything runs locally in your browser — nothing is uploaded

Input
Drop a file here to load its contents
Output

Work out what actually sits in the password column of three databases. None of these schemes belongs in anything new — PostgreSQL's md5 does a single md5 with no iteration at all, and MySQL's `PASSWORD()` has been removed outright with its double SHA-1 long obsolete — but they still sit in countless `pg_authid` and `mysql.user` rows and in setup scripts everywhere. Moving a user between databases, or repairing one record by hand, means having to compute the value. The PostgreSQL case deserves particular care: it uses the username as the salt (hash = md5(password + username)), so the same password against a different username gives a completely different hash. Copy that hash under a new username and the login will simply fail.

Features

  • Three dialects: PostgreSQL md5, and mysql_native_password for MySQL and MariaDB
  • PostgreSQL computes over "password + username" — with an explanation of why the username matters
  • Each dialect comes with a ready-to-run SQL statement (ALTER USER / SET PASSWORD)
  • The hash and the SQL are separate rows, each with its own copy button
  • Non-ASCII passwords are handled as UTF-8 bytes
  • Computed locally; the password is never uploaded

How to use

  1. Choose the database
  2. Supply a username for PostgreSQL (it is used as the salt)
  3. Paste the password into the input box
  4. Copy the hash, or that SQL line

FAQ

Why does PostgreSQL need the username?
Because its `md5` scheme uses the username as the salt: `md5` + md5(password + username). The upside is not having to store a separate salt column; the cost is that renaming a role invalidates the password — move the hash under a different username and the inner md5 still carries the old name, so login fails. It is the most common trap when migrating users, which is why this tool says so on the page.
MySQL removed PASSWORD() — is this still usable?
MySQL 8.0 removed the `PASSWORD()` function, but the `mysql_native_password` plugin is still there (merely no longer the default, which is now `caching_sha2_password`). This tool computes exactly what that plugin expects: an asterisk followed by the uppercase hex of a double SHA-1. To set it for a MySQL 8.0 user, use `IDENTIFIED WITH mysql_native_password AS '…'` — which is the SQL this tool hands you.
Are these schemes secure?
No, and none of them belongs in anything new. PostgreSQL's md5 does one md5 with no iteration, and a modern GPU computes billions per second. MySQL's double SHA-1 adds a layer but is nowhere near the strength of a deliberate slow hash. The deeper problem is that neither salts properly (PostgreSQL's "salt" is the username — public and fixed), so rainbow tables apply directly. For new systems use bcrypt, scrypt or Argon2id — all three have tools on this site. This one exists for migration, not for new work.

Related tools