For more than two decades, MD5 hashing served as PostgreSQL’s default password authentication method. That era is ending. The open-source database’s development community has been signaling for years that MD5’s days were numbered, and now, with PostgreSQL 17 and the roadmap toward version 18, the deprecation is no longer theoretical. It’s happening, and database administrators who haven’t started planning their migration to SCRAM-SHA-256 are running out of runway.
The shift matters far beyond a simple configuration toggle. MD5 authentication in PostgreSQL carries known cryptographic weaknesses that make it fundamentally unsuitable for modern security requirements. As Percona detailed in a thorough technical analysis, the MD5 scheme used by PostgreSQL doesn’t just hash the password — it concatenates the password with the username before hashing, producing a fixed digest that can be replayed if intercepted. There’s no salting with random values. No iterative hashing to slow brute-force attacks. The hash stored in the database is, in effect, functionally equivalent to a plaintext password for anyone who obtains it.
That’s a damning assessment for any authentication system in 2025.
SCRAM-SHA-256, which became available in PostgreSQL 10 and was made the default for new installations starting with PostgreSQL 14, addresses every major shortcoming. The protocol uses a challenge-response mechanism with random salts and thousands of iterations of PBKDF2 key derivation, meaning the server never sees the actual password during authentication and the stored verifier is useless for replay attacks. It’s the kind of authentication protocol that security engineers actually endorse, rather than merely tolerate.
But defaults and deprecations are two different things. Changing the default for new clusters was the easy part. The hard part — forcing existing deployments to migrate — is where the PostgreSQL community now finds itself. According to Percona’s analysis, PostgreSQL 17 introduced explicit deprecation warnings when MD5 authentication is used. Server logs now emit notices that MD5 support will be removed in a future release. The community’s current trajectory suggests PostgreSQL 18, expected in late 2025, could be the version where MD5 support is either removed entirely or reduced to a vestigial compatibility mode that’s off by default.
The technical mechanics of migration are straightforward in principle. An administrator changes the password_encryption parameter from md5 to scram-sha-256 in postgresql.conf, updates pg_hba.conf to require SCRAM authentication, and then has every user reset their password so the new hash format is stored. Simple enough on paper. In practice, the complications multiply fast.
Consider a production environment with hundreds of application service accounts, connection poolers like PgBouncer, legacy client libraries, and monitoring tools that all authenticate against the database. Every single one of those components needs to support SCRAM-SHA-256. PgBouncer, for instance, didn’t add full SCRAM support until version 1.21.0, released in late 2023. Organizations running older versions of PgBouncer — and many are — face an upgrade dependency chain before they can even begin the authentication migration. As Percona notes, some older client drivers and connectors still lack SCRAM support entirely, which means applications may need library upgrades or even code changes.
And then there’s the coordination problem. Resetting passwords for every database user in a large enterprise isn’t a five-minute task. It requires coordination across application teams, rotation of secrets in vault systems, updates to CI/CD pipelines, and careful sequencing to avoid authentication failures that could trigger outages. For organizations running PostgreSQL at scale — and there are many, given that PostgreSQL has become the most popular database among developers according to Stack Overflow’s annual surveys — this is a project that demands planning months in advance.
The security case for urgency is compelling. MD5 has been considered cryptographically broken for general purposes since at least 2004, when researchers at Shandong University demonstrated practical collision attacks. While PostgreSQL’s specific use of MD5 for password hashing isn’t directly vulnerable to collision attacks, the broader weaknesses are relevant. The fixed hash can be captured and used in pass-the-hash attacks. Rainbow tables for MD5 are trivially available. And because PostgreSQL’s MD5 scheme uses the username as the only salt, two users with the same password on the same server will have different hashes — but the same user with the same password on different servers will have identical hashes, creating cross-system exposure.
SCRAM-SHA-256 eliminates all of these vectors. The random salt ensures every stored verifier is unique regardless of password reuse. The iteration count makes brute-force attacks computationally expensive. The challenge-response protocol means the password equivalent never crosses the wire, even over an unencrypted connection — though, of course, TLS should be used regardless.
The PostgreSQL community’s approach to this deprecation reflects its characteristic conservatism. Unlike some projects that rip out deprecated features aggressively, PostgreSQL has given users a multi-year window. SCRAM-SHA-256 was introduced in PostgreSQL 10, released in October 2017. That’s nearly eight years of availability before the likely removal of MD5. By the standards of enterprise software migration timelines, that’s generous. But generosity doesn’t eliminate the pain of the final deadline.
Recent discussions on the pgsql-hackers mailing list suggest that the core team is firm on the direction. There’s no appetite for extending MD5’s lifespan indefinitely. The deprecation warnings in PostgreSQL 17 are explicitly designed to create urgency. Some contributors have argued for an even faster timeline, pointing out that continued MD5 support gives a false sense of security to administrators who haven’t evaluated their authentication posture.
For managed PostgreSQL services — Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL, and others — the transition is somewhat simpler because the cloud providers control the infrastructure layer. Amazon’s documentation already recommends SCRAM-SHA-256 for RDS PostgreSQL instances and has set it as the default for new parameter groups. Google Cloud SQL similarly defaults to SCRAM for new instances. But even in managed environments, existing instances that were created years ago may still be running MD5 authentication, and migrating those requires the same application-level coordination as self-hosted deployments.
There’s a subtlety here that often gets overlooked. The pg_hba.conf authentication method md5 in PostgreSQL actually accepts both MD5 and SCRAM-SHA-256 credentials. So an administrator can change the password encryption to SCRAM-SHA-256, have users reset their passwords, and the existing md5 method in pg_hba.conf will still work. The reverse isn’t true: if pg_hba.conf specifies scram-sha-256, only SCRAM credentials are accepted. This asymmetry provides a useful migration path — change the encryption first, rotate passwords, then tighten the HBA configuration — but it also means that administrators who think they’ve migrated because they changed password_encryption may still be allowing weaker authentication methods through their HBA rules.
Percona’s analysis emphasizes this point: a complete migration requires changes in three places. The server configuration for password encryption. The HBA file for authentication method enforcement. And the actual stored credentials for every user. Miss any one of the three, and the migration is incomplete.
The broader context matters too. PostgreSQL’s authentication overhaul is part of a wider industry movement away from password-based authentication entirely. Certificate-based authentication, LDAP integration, GSSAPI with Kerberos, and RADIUS are all supported by PostgreSQL and are increasingly preferred in enterprise environments. Some organizations are using the MD5 deprecation as an opportunity to skip SCRAM entirely and move to certificate authentication or external identity providers. That’s a more ambitious project, but it eliminates password management overhead altogether.
So what should database teams be doing right now? First, audit. Run a query against pg_authid to identify any roles whose passwords are still stored in MD5 format — these will have hashes starting with md5 rather than SCRAM-SHA-256. Second, verify that every client library, connection pooler, and tool in the stack supports SCRAM. Third, develop a password rotation plan that accounts for service accounts, not just human users. And fourth, test the entire authentication flow in a staging environment before touching production.
None of this is glamorous work. It’s the kind of infrastructure hygiene that doesn’t generate headlines or executive attention until something breaks. But the deadline is approaching, and PostgreSQL’s maintainers have made their intentions clear. MD5 authentication is a relic of a less security-conscious era. Its removal from PostgreSQL won’t be sudden, but it will be final.
Organizations that treat this as a low-priority item are making a bet — that their current PostgreSQL version will remain supported and sufficient for their needs indefinitely. That’s rarely a good bet. The time to migrate is now, while the transition can be planned and executed on your own schedule rather than forced by an upgrade that removes the option entirely.
WebProNews is an iEntry Publication