Free Strong MySQL Password Generator [Updated 2026]

...

Quickstart: Click "regen" multiple times, then click "copy" to copy the MySQL user password to your clipboard. Adjust parameters below if needed.

How to set a MySQL User Password

Use the generated password in the following SQL commands:

CREATE USER 'user'@'hostname' IDENTIFIED BY '...';

Replace 'user' and 'hostname' with your desired username and host.

ALTER USER 'user'@'hostname' IDENTIFIED BY '...';

Replace 'user' and 'hostname' with the existing username and host.

...

...

Generate strong & secure random passwords for your MySQL database users. This tool creates strong, secure, random plain text passwords using crypto.getRandomValues, the browser's cryptographically secure random number generator, without sending the password over the internet or storing the generated password on a server. Whether you need to meet strict MySQL password requirements or reset MySQL password credentials, this generator helps you secure MySQL database accounts with high-entropy passwords. If you are still uncomfortable using this utility you can generate multiple passwords, save them to your device and use different parts from each to create a unique password.

I developed this password generator because security for database users matters. Every character comes straight from the browser's cryptographically secure random number generator, and each one is equally likely. By generating multiple passwords, saving them locally, and then perhaps even manually combining parts, you can achieve a very high degree of trust in your MySQL user credentials. This tool is especially useful when you need to quickly reset MySQL password values or create new accounts that meet MySQL password requirements for length and complexity.

This page is intentionally kept simple to minimize any potential attack surface. All password generation is done in-browser; no server requests are made when you click "generate", "copy", or modify parameters.

Common MySQL Password Errors

When setting or using MySQL passwords, you may encounter these common errors:

• ERROR 1819: Your password does not satisfy the current policy requirements - This means MySQL's password validation plugin is enabled and your password doesn't meet the requirements (length, complexity, etc.). Check your validation settings with SHOW VARIABLES LIKE 'validate_password%'; or generate a longer, more complex password.
• ERROR 1045: Access denied for user - This typically means the password is incorrect, the user doesn't exist, or the host doesn't match. Remember that 'user'@'localhost' and 'user'@'%' are treated as different accounts in MySQL.
• Special character issues in shell/command line - If your password contains special characters like !, $, ', or \, you may need to escape them or use single quotes in your shell. When using SQL commands directly, always wrap passwords in single quotes: IDENTIFIED BY 'password'.
• Password works in SQL but not in connection strings - Some characters may need URL encoding in connection strings (e.g., @ becomes %40). Check your database driver's documentation for proper escaping.

Most apps talk to more than one database, and each one has its own quirks with passwords in connection strings. The MongoDB password generator gives you the percent-encoded form for mongodb+srv:// URIs, the Redis password generator writes the requirepass and ACL SETUSER lines, and the SQL Server password generator makes passwords that always pass CHECK_POLICY.

MySQL Password Hash Generator: Creating Users Without the Plaintext

Most of the time you should just write IDENTIFIED BY 'password' and let MySQL do the hashing. The server already keeps that password out of its own logs: MySQL rewrites the password in CREATE USER, ALTER USER and SET PASSWORD statements before they reach the general query log, the slow query log and the binary log. The mysql client also skips any statement matching *IDENTIFIED* or *PASSWORD* when it writes its history file.

The problem is everything that isn't MySQL. The hash panel above exists for those cases.

When I pre-hash a MySQL password

• Provisioning scripts and migrations that live in Git. An init SQL file for a Docker image, a Flyway or Liquibase migration, a seed script. A hash in a repo still isn't great, but a plaintext password in a repo is how you end up rotating credentials on a Saturday.
• Config management. Ansible, Terraform, Puppet and friends love to echo rendered templates into CI output and write them to state files. If the SQL they run only contains a hash, that's what leaks.
• Handing SQL to someone else. If a DBA or another team runs account changes for you, send them IDENTIFIED WITH ... AS ... and give the actual password straight to the application's secret store. Nobody in the middle ever sees it.
• Your own tooling. Query consoles, audit proxies, ticket comments and chat logs don't know they should redact IDENTIFIED BY. The MySQL manual also notes that statements taking a hash are not rewritten in logs, which is fine when the thing being logged is a hash.

One caution before you get too comfortable: a password hash is still a secret. Anyone holding it can run an offline guessing attack. With a long random password from the generator at the top of this page, that attack goes nowhere. With Summer2024!, it goes somewhere quickly.

How caching_sha2_password stores a password

caching_sha2_password is the default authentication plugin in MySQL 8.0 and later. The value it keeps in the authentication_string column of mysql.user is 70 bytes long, and I built the panel above by reading MySQL's own source (sql/auth/sha2_password.cc and mysys/crypt_genhash_impl.cc):

• $A$: the digest type. A means SHA-256.
• 005$: the number of rounds in thousands, so 5,000. This comes from the caching_sha2_password_digest_rounds server variable, and 5,000 is the default.
• 20 bytes of random salt. Each byte is between 1 and 127 and is never $, which means the salt can include control characters.
• 43 characters of digest. This is the same SHA-256 crypt algorithm Linux uses for $5$ passwords in /etc/shadow, except MySQL feeds it a 20-byte salt instead of stopping at 16.

Because the salt can contain unprintable bytes, you can't safely paste the hash inside quotes. MySQL accepts a hexadecimal literal instead, which is what the panel produces:

CREATE USER 'app'@'10.0.0.%'
  IDENTIFIED WITH caching_sha2_password
  AS 0x24412430303524...;

The hex literal must not be quoted. MySQL stores the bytes as-is. It does not hash them again, so if you paste in something that isn't a valid hash, you just get an account nobody can log in to. If you want to see a hash MySQL made itself in the same form, run SET print_identified_with_as_hex = ON; and then SHOW CREATE USER 'app'@'10.0.0.%';.

There is also a length limit worth knowing: caching_sha2_password accepts passwords up to 256 bytes. I tried 257 on MySQL 8.4 and got ERROR 1396. The panel refuses anything over 256 bytes for the same reason.

Why the first login needs TLS or an RSA key

The "caching" part of the name is an in-memory cache on the server. After a user logs in successfully once, the server keeps a fast SHA-256 based digest of their password, and later logins use a challenge and response against that cache. The password never crosses the wire.

The cache starts empty for an account after it's created, after its password changes, after RENAME USER, after FLUSH PRIVILEGES, and after a server restart. A salted 5,000-round hash can't check a challenge response, so for that first login the server asks the client for the actual password. MySQL will only accept it over a secure connection (TLS, a Unix socket file, or shared memory) or encrypted with the server's RSA public key. Otherwise you get this:

ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password'
reported error: Authentication requires secure connection.

I tested all of this on MySQL 8.4 with an account created from this page's hash. Unencrypted with no RSA key: that error. Unencrypted with --get-server-public-key: logged in. Unencrypted again right afterward: logged in, because the cache now had the account. After FLUSH PRIVILEGES: the error came back. If an app connects fine for weeks and then fails after a restart, this is usually why. Use TLS and it stops mattering.

How mysql_native_password stores a password

The legacy plugin is much simpler. It stores * followed by the uppercase hex of SHA1(SHA1(password)), 41 characters in total. There is no salt, so the same password gives the same hash on every server in the world. That also means precomputed tables work against it, and two SHA-1 calls are very cheap to guess against.

At login, the client sends SHA1(password) XOR SHA1(nonce + SHA1(SHA1(password))). The server recovers SHA1(password), hashes it once more and compares. The stored hash alone isn't enough to log in, but the stored hash plus one captured unencrypted login is, because together they give up SHA1(password).

Its status, per the MySQL manual: deprecated in 8.0.34, disabled by default in 8.4, and removed in 9.0. On 8.4 you can still turn it on with --mysql-native-password=ON on the command line or mysql_native_password=ON under [mysqld]. Without that, creating one of these accounts fails with ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded.

If you want to make this hash offline without a browser, it's one line of Python:

python3 -c "import hashlib,getpass; p=getpass.getpass().encode(); print('*'+hashlib.sha1(hashlib.sha1(p).digest()).hexdigest().upper())"

For a caching_sha2_password hash without this page, the least fiddly offline option is a throwaway MySQL container. Create the user with IDENTIFIED BY, run SHOW CREATE USER with print_identified_with_as_hex turned on, copy the AS 0x... part, and delete the container.

Migrating users off mysql_native_password

Start by finding them:

SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password';

There is no way to convert an existing native hash into a caching_sha2_password hash. SHA-1 only goes one way, and the new format needs the original password. So each account needs a new password (or the old one, if you still have it):

ALTER USER 'app'@'10.0.0.%' IDENTIFIED WITH caching_sha2_password BY 'new-password';

Or use the ALTER USER ... AS 0x... statement from the panel above so the plaintext stays out of the migration script. Before you flip an account, make sure the client library connecting with it supports caching_sha2_password, and that it connects over TLS or can fetch the server's RSA key. Very old drivers don't. Do the whole migration while you're still on 8.4 with the native plugin enabled, because 9.0 doesn't have the plugin to fall back on.

MariaDB is different

MariaDB went its own way. On MariaDB 11.4, which I tested, a new account defaults to mysql_native_password, SELECT PASSWORD('...') returns the same * hash this page makes, and caching_sha2_password is listed as not installed. So the native hash from this page works on MariaDB, but the $A$005$ hash is for MySQL only. MariaDB's syntax is also a little different:

CREATE USER 'app'@'%' IDENTIFIED BY PASSWORD '*0DA3D1CD83EC6FAE79E8E3859E146E74E1CE416A';
-- or
CREATE USER 'app'@'%' IDENTIFIED VIA mysql_native_password USING '*0DA3D1CD83EC6FAE79E8E3859E146E74E1CE416A';

If you want something stronger on MariaDB, it ships an ed25519 plugin. Load it once with INSTALL SONAME 'auth_ed25519';, then CREATE USER 'app'@'%' IDENTIFIED VIA ed25519 USING PASSWORD('...');. That form has the server do the hashing, so the plaintext is in the statement, and this page doesn't generate ed25519 hashes.

MySQL User Password FAQ

import mysql.connector

connection = mysql.connector.connect(
    host='hostname',
    user='username',
    password='your_generated_password',
    database='database_name'
)

$dsn = "mysql:host=hostname;dbname=database_name";
$username = "username";
$password = "your_generated_password";
$pdo = new PDO($dsn, $username, $password);

const mysql = require('mysql2');
const connection = mysql.createConnection({
  host: 'hostname',
  user: 'username',
  password: 'your_generated_password',
  database: 'database_name'
});

Also check out the PostgreSQL Password Generator, SQL Server Password Generator, MongoDB Password Generator, Redis Password Generator, General Strong Password Generator, and Random Passphrase Generator, or browse all the free tools.

-Sethers