Security

Database Password Generator

Generate strong passwords for MySQL, PostgreSQL, MongoDB and other databases. Avoids problematic characters. Free, browser-based, no data stored.

About this database password generator

Database passwords protect your most valuable asset — your data. A compromised database password gives an attacker direct access to every record, bypassing all application-level security. Database passwords have unique requirements: they are often stored in configuration files, environment variables, or connection strings, where certain characters can cause parsing issues. Single quotes, double quotes, backslashes, semicolons, and the percent sign can break connection strings in many frameworks. This generator defaults to 32 characters with alphanumeric characters — long enough for maximum security while avoiding the special characters that commonly cause configuration headaches. For databases, the password is always copy-pasted from a vault or configuration management system, never typed manually, so extreme length has zero usability cost.

Database credential security fundamentals

Database passwords are categorically different from user account passwords in how they are used and where they live. A web application's database password is embedded in connection strings, stored in environment variables, and accessed thousands of times per minute by automated processes — never typed by a human. This changes the security calculus entirely: length can and should be maximized (32-64+ characters), the password should be cryptographically random with no human-readable patterns, and it should be stored in a secrets manager rather than a flat file. The threat model is also different: the primary risk is not brute-force attack but credential exposure through misconfigured servers, leaked configuration files, compromised CI/CD systems, or insider access. A strong random password is necessary but not sufficient — how the credential is stored and rotated matters as much as the password itself.

Connection string format and dangerous characters

Database connection strings follow URL-like formats where certain characters serve as delimiters. PostgreSQL uses the format postgresql://user:password@host:5432/dbname — the at sign (@) separates credentials from the host, the colon (:) separates username from password, and the forward slash (/) separates host from database name. MySQL uses similar JDBC URL syntax. MongoDB connection strings follow mongodb://user:password@host/database. If your password contains any of these delimiter characters, the parser splits your password at that point, treating the remainder as part of the host or database field, causing mysterious connection failures. Single and double quotes, backslashes, and percent signs cause additional issues in shell environments and config parsers. The safest approach is alphanumeric passwords with at most underscores and hyphens, which work safely in every connection string format across all database systems.

Database credential storage best practices

The storage of database credentials is as important as their complexity. The worst practice is hardcoding passwords directly in application source code — where they are visible to every developer, committed to version control, and potentially exposed in public repositories. Slightly better but still risky is storing them in configuration files committed to the repo (even with .gitignore, historical commits may contain them). Environment variables are the standard minimum: they keep passwords out of source code and can be set per-environment. Secrets managers (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) are the current best practice for production systems: they encrypt secrets at rest, control access through IAM policies, log every retrieval, support automatic rotation, and can inject credentials into containers at runtime. For local development, use a .env file (added to .gitignore) or a local vault configuration. The critical rule: never commit credentials to version control, even temporarily.

Database credential rotation strategies

Rotating database passwords on a schedule limits the damage window if a credential is silently compromised. The rotation process must be atomic to avoid application downtime: the standard approach is to set the new password on the database, update the secret in the secrets manager, and then allow applications to pick up the new credential through cache expiration or restart. AWS Secrets Manager and HashiCorp Vault both support automatic rotation with zero-downtime strategies for MySQL, PostgreSQL, and Oracle. For manual rotation, the blue/green approach works: create a new user with the new password and required permissions, update the application configuration, verify connectivity, then remove the old user. Rotation is also mandatory after team member departures, infrastructure incidents, and any suspected compromise. Keep rotation logs — knowing when credentials were last changed is valuable for incident response.

Principle of least privilege for database accounts

Application database accounts should have exactly the permissions they need — no more. A web application that only reads and writes to its own database has no need for CREATE TABLE, DROP, or access to other databases. Create a dedicated database user per application with GRANT SELECT, INSERT, UPDATE, DELETE on that application's specific tables or schema only. Database administrative accounts (root, postgres, sa) should be separate, stored with extra security, almost never used directly, and only accessible from specific administrative hosts. Read-only database replicas used for reporting or analytics should have separate credentials with SELECT-only access. Separate credentials for migrations (which need schema-altering permissions) from runtime credentials (which only need data access). This principle limits blast radius: if an application's credentials are compromised, the attacker can only access data that the application itself could access, not the entire database server.

FAQ

Common questions

Why are database passwords different from regular passwords?

Database passwords are stored in config files, environment variables, and connection strings where special characters like quotes, backslashes, and semicolons can cause parsing errors. They are also never typed manually, so they can be much longer without usability concerns.

How long should a database password be?

At least 32 characters. Since database passwords are always copy-pasted or stored in config, there is no reason to use anything shorter. MySQL supports up to 32 characters for native auth, PostgreSQL has no practical limit.

Which characters should I avoid in database passwords?

Avoid single quotes ('), double quotes ("), backslashes (\), semicolons (;), percent signs (%), and at signs (@) — these can break connection strings, SQL queries, or URL-format connection URIs. Alphanumeric with underscores and hyphens is safest.

How should I store database passwords?

Use environment variables, a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager), or encrypted configuration. Never hardcode database passwords in source code or commit them to version control.

Should database passwords be rotated regularly?

Yes — rotate database credentials on a schedule (every 90 days is common) and immediately after any suspected compromise, team member departure, or environment decommission. Use secrets managers with automatic rotation to make this seamless without application downtime.

What is the difference between a database user password and a root/admin password?

Database root or admin accounts have full privilege over all databases and users. Application credentials should use a dedicated user account with the minimum permissions needed (SELECT, INSERT, UPDATE on specific databases only). The root password should be much longer, stored in a vault, and almost never used directly.

How do connection string passwords get leaked?

The most common ways: accidentally committing .env files or config files to git, including connection strings in log output, exposing environment variables through debug endpoints, and storing them in plain text in CI/CD variable sections without masking. Use git hooks or secret scanning tools (like GitGuardian) to catch leaks before they reach remote repositories.

What is a secrets manager and should I use one?

A secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault) stores credentials encrypted, controls access through IAM policies, logs every access, and can automatically rotate secrets. For any production database, a secrets manager is strongly recommended over plain environment variables, which can be exposed through process inspection on a compromised server.