MD5 has long been the standard for authentication in PostgreSQL. However, accumulated limitations have led to a gradual phasing out and a transition to a more robust model.
The problem does not manifest immediately—until the security model begins to rely on outdated assumptions. MD5 proved to be a convenient choice: simple implementation, low overhead, minimal latency during authentication. As a result, it became entrenched as the default mechanism. However, the fundamental limitation is collisions. Different inputs can yield the same hash. For an authentication system, this means that “hash matching” no longer provides a strict guarantee. The situation is exacerbated by the fact that attacks often do not require a complete breach—it’s sufficient to find a matching hash through dictionary or simplified methods.
PostgreSQL has partially mitigated this risk. Unlike “pure” MD5, a combination of username and password is used before hashing. This reduces the likelihood of trivial matches and complicates hash reuse. However, it does not eliminate the underlying problem of the algorithm. If an MD5 hash is leaked, the risk of finding a matching string remains. Therefore, the community has chosen an evolutionary path: a phased deprecation of MD5. First, it was marked as deprecated, then the creation of new MD5 passwords was prohibited, followed by the disabling of authentication, and finally, the inability to upgrade with such data. This reduces the risk of abrupt failures in production and allows time for migration.
The alternative is scram-sha-256, available since PostgreSQL 10. Here, the interaction model itself changes. Authentication becomes mutual: the client and server exchange keys rather than simply comparing hashes. The password is not transmitted in plain text. A longer hash (256 bits) and additional protocol elements are used. This increases computational load and complicates implementation, but reduces the risk of pass-the-hash attacks. Essentially, the system moves from static verification to a protocol involving both parties.
In practice, the transition is not without cost. scram-sha-256 requires client updates and careful configuration. Some scenarios without an additional layer of authentication become more complex. The general principle remains: any algorithm is theoretically vulnerable. However, what matters here is not the absolute level of protection, but the likelihood of exploitation. In this sense, scram-sha-256 is a more resilient compromise.
The conclusion is pragmatic. MD5 in PostgreSQL was not entirely insecure due to the additional logic, but its model no longer meets current security expectations. Transitioning to scram-sha-256 is not an enhancement “just in case,” but rather the elimination of a known class of risks with controlled costs. Specific metrics of improvements are not provided, but the direction aligns with the overall industry trend: moving away from simple hashes to authentication protocols.