By Tech & Database Security Desk Published: November 2024 / Updated for PostgreSQL 18 and 19 Release Cycles
Main Facts: The End of an Era for Legacy Hashing
The global database management community is preparing for a definitive security transition. PostgreSQL, one of the world’s most robust, widely deployed, and trusted open-source relational database management systems, is moving decisively to eradicate support for MD5-authenticated passwords.
For years, database administrators (DBAs) and enterprise security architects have acknowledged the severe cryptographic vulnerabilities inherent in MD5. However, backward compatibility has kept the legacy hashing algorithm alive in production environments globally. That era is coming to an end.
Centering on a new configuration parameter introduced in PostgreSQL 18—md5_password_warnings—the core development team is enacting a deliberate, phased deprecation roadmap. This campaign is designed to force organizations out of decades-old technical debt and onto modern cryptographic standards like SCRAM-SHA-256.
The core facts of the rollout include:
The Vulnerability of MD5: MD5 has long been deemed cryptographically broken. Worse still, PostgreSQL’s historic implementation stores the actual hash directly inside the pg_authid catalog table. In many legacy configurations, a compromised hash does not even need to be cracked; the hash itself acts as the valid authentication credential.
The New Control Switch: PostgreSQL 18 introduces md5_password_warnings, a boolean server parameter defaulting to on, designed to flag the usage and creation of MD5 hashes.
Evolution Across Versions: While PostgreSQL 18 restricted its warnings primarily to the creation or alteration of roles via CREATE ROLE or ALTER ROLE, PostgreSQL 19 expands this oversight significantly. PostgreSQL 19 fires active connection warnings upon every successful login executed using an MD5-encrypted password.
The Roadmap to Removal: Although complete removal has not yet been hard-coded into an absolute version release date, proposals submitted to the pgsql-hackers mailing list point toward a future where authentication attempts using MD5 will be outright rejected by the engine.
Chronology: A Decade-Long Migration Path
Understanding how PostgreSQL arrived at this juncture requires tracing its security evolution over the past ten years.
The Introduction of SCRAM (PostgreSQL 10–14)
The foundation for MD5’s retirement was laid years ago. With the release of PostgreSQL 10, the project introduced SCRAM-SHA-256 (Salted Challenge Response Authentication Mechanism) as a vastly superior, cryptographically sound alternative to MD5. Recognizing the superiority of SCRAM against modern rainbow tables, dictionary attacks, and brute-force methodologies, the PostgreSQL Global Development Group officially made SCRAM-SHA-256 the default setting for the password_encryption configuration parameter starting in PostgreSQL 14.
Despite this shift, millions of legacy databases, automated provisioning scripts, and legacy applications continued to rely on MD5 simply because it remained operational out-of-the-box and broke nothing upon upgrade.
The October 2024 Retirement Proposal
The dormant technical debt finally sparked active institutional action in October 2024. Core developer Nathan Bossart formally proposed an aggressive retirement schedule on the pgsql-hackers developer mailing list. Bossart outlined a timeline wherein upcoming major versions would systematically restrict, warn against, and ultimately refuse MD5 authentication entirely. This proposal gained immediate traction among core maintainers, leading directly to the commit that established the deprecation pathway.
The PostgreSQL 18 Implementation
Released as the baseline for this deprecation wave, PostgreSQL 18 officially deprecated MD5 password hashes. Alongside deprecation notices embedded in system documentation, the developers shipped the md5_password_warnings parameter.
However, PostgreSQL 18’s implementation came with a notable blind spot. It warned administrators only when an MD5 hash was actively stored via CREATE ROLE or ALTER ROLE. Roles that had been utilizing the exact same MD5 password hashes continuously since 2015—surviving numerous major-version upgrades silently—did not trigger a single warning during normal day-to-day login operations.
The PostgreSQL 19 Correction
Recognizing that creation-time warnings missed long-standing production risks, database expert Tom Lane highlighted on pgsql-hackers that the actual login event is where the eventual system refusal will take place. Therefore, the login event is where the warning must live.
As seen in PostgreSQL 19 Beta 4 and subsequent builds, the scope of md5_password_warnings was drastically expanded. It now intercepts every single successful authentication handshake executed using an MD5 hash, transforming a silent vulnerability into an unignorable operational alert.
Supporting Data & Technical Mechanics
To safely navigate this transition, database administrators must understand the underlying mechanics of how md5_password_warnings behaves, how it interacts with infrastructure configurations, and how to query catalogs to discover lingering risks.
Parameter Behavior and Fleet Management
The md5_password_warnings parameter is a boolean with a default state of on and a configuration context of user. This means any role can toggle it off for its own session without requiring elevated superuser privileges.
A Crucial Fleet Warning for Mixed Environments:
Because md5_password_warnings does not exist prior to PostgreSQL 18, attempting to run a PostgreSQL 16 server with this parameter defined inside its postgresql.conf file will cause the server to refuse to start entirely. Organizations utilizing centralized configuration templates across a mixed-version server fleet must segment their configurations carefully before rolling out updates.
The Warning Disconnect: 18 vs. 19
In PostgreSQL 18, actions like running provisioning scripts, replaying pg_dumpall outputs via psql, or executing commands that set pre-hashed strings trigger a warning:
WARNING: setting an MD5-encrypted password
DETAIL: MD5 password support is deprecated and will be removed in a future release of PostgreSQL.
HINT: Refer to the PostgreSQL documentation for details about migrating to another password type.
Conversely, PostgreSQL 19 introduces runtime connection warnings. When a legacy application connects using an MD5 password, both the client terminal and the server logs capture an alert:
WARNING: authenticated with an MD5-encrypted password
DETAIL: MD5 password support is deprecated and will be removed in a future release of PostgreSQL.
Auditing the System Catalog
Because roles authenticating via alternative methods (such as local peer or trust authentication methods defined in pg_hba.conf) will never trigger runtime login warnings, administrators cannot rely on logs alone to audit their vulnerability footprint. The definitive source of truth is the system catalog itself.
Database superusers can run the following query to discover all roles currently burdened with an MD5 hash:
SELECT rolname
FROM pg_authid
WHERE rolpassword ~ '^md5[0-9a-f]32$';
Once identified, these roles must have their passwords explicitly re-set while password_encryption is set to scram-sha-256. Because cryptographic hashes cannot be directly converted backwards, a plain-text password must be supplied again via ALTER ROLE or the password interactive command.
Official Responses and Developer Consensus
The consensus among PostgreSQL core contributors is clear: the technical debt of MD5 poses an unacceptable risk to modern enterprise data architectures, and gentle nudges are no longer sufficient.
Nathan Bossart’s initial proposal galvanized the development community around the principle that deprecation must be paired with actionable telemetry. Discussions on the project’s developer forums emphasize that the transition cannot be executed overnight, given the vast web of legacy enterprise applications that still hardcode MD5 expectations into their connection strings.
Tom Lane’s advocacy for moving the warning mechanism directly into the authentication handshake (CheckMD5Auth()) underscores the project’s commitment to transparency. Rather than hiding deprecation notices deep within administrative documentation, PostgreSQL is engineering its software to actively announce security liabilities directly to the engineers and applications responsible for them.
The long-term architectural goal remains absolute: CheckMD5Auth(), the internal function currently responsible for queuing these warnings, is slated to be refactored in a subsequent major release to return a hard authentication failure instead of a warning.
Implications for Enterprise Architecture and Operations
The deprecation of MD5 passwords carries profound implications for database administrators, DevOps engineers, and security compliance officers worldwide.
1. Log Flooding and Monitoring Noise
In PostgreSQL 19, the warning fires on every successful connection. For high-throughput microservices or web applications that open and close database connections on a per-request basis, this behavior will immediately flood server log files with duplicate warning lines.
Administrators must be prepared to identify these chatty applications. Furthermore, standard log configurations utilizing the stock log_line_prefix ('%m [%p] ') do not natively display the identity of the role that just logged in. Teams will need to ensure their logging prefixes include %u (role name) or rely on specialized log analysis tools to map warnings to specific legacy services.
2. Granular Mitigation Strategies
Because the parameter context is set to user, operational teams have an emergency valve if a critical legacy application cannot be refactored immediately. An administrator can quiet the warnings for a specific, isolated legacy role without blinding the rest of the cluster:
ALTER ROLE legacy_app SET md5_password_warnings = off;
Alternatively, client connections can pass connection options directly (-c md5_password_warnings=off), or teams can adjust client_min_messages to suppress terminal output while preserving critical audit trails in the server log. However, experts strongly advise treating these suppressions strictly as temporary stopgaps rather than permanent operational states.
3. Migration Sequencing
Migrating away from MD5 does not require a simultaneous, terrifying rewrite of network access rules. Administrators can safely execute migrations iteratively:
Update individual roles to SCRAM-SHA-256 by resetting their passwords.
Leave existing md5 authentication lines intact within pg_hba.conf during the interim phase, as a line configured for md5 seamlessly transparently performs SCRAM authentication for any role equipped with a modern SCRAM secret.
Verify that all connecting client drivers fully support SCRAM.
Finally, clean up pg_hba.conf once all legacy dependencies have been purged.
Conclusion
PostgreSQL’s phased eradication of MD5 password hashes marks a mature, pragmatic masterclass in database security governance. By balancing the urgent need for cryptographic modernization against the harsh realities of enterprise technical debt, the project is giving organizations the tools, telemetry, and timeline necessary to secure their infrastructure before legacy vulnerabilities can be exploited in the wild.
