The latest articles on DEV Community by Afzal Hassan (@iemafzalhassan). https://dev.to/iemafzalhassan https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1128570%2Fbc365452-24d5-4b32-bba3-d7ba53c3ca91.png https://dev.to/iemafzalhassan en Afzal Hassan Mon, 12 Oct 2026 21:05:07 +0000 https://dev.to/iemafzalhassan/enabling-fips-on-uat-postgres-servers-meant-moving-off-md5-passwords-3620 https://dev.to/iemafzalhassan/enabling-fips-on-uat-postgres-servers-meant-moving-off-md5-passwords-3620 <h2> The problem </h2> <p>We needed FIPS mode enabled on our UAT database servers, running RHEL 9.5. The reason was an RBI audit point, so it was not optional.</p> <p>The first attempt to enable FIPS did not stick, and the reason was on the database side: our Postgres databases were still using the older MD5 password hashing method, which is not compatible with FIPS mode.</p> <h2> Why this mattered more than a usual config change </h2> <p>These are not isolated databases. Our UAT Keycloak identity provider runs on them, and the dependency chain goes like this:</p> <ul> <li>If Postgres is down, Keycloak does not run.</li> <li>If Keycloak is down, Superset does not run.</li> <li>If Vault is down, all the application pods end up stuck in CrashLoopBackOff.</li> </ul> <p>So a password hashing change on the database silently sits upstream of the identity provider, the BI tool, and every application pod.</p> <h2> The fix </h2> <p>The order of operations turned out to be the whole trick:</p> <ol> <li>Change the password hashing from MD5 to SCRAM.</li> <li>Reformat the existing passwords and add them back under the new scheme.</li> <li>Enable FIPS again, and this time it worked.</li> </ol> <h2> Verifying it </h2> <p>After the change I confirmed FIPS mode was actually active using:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code><span class="nb">sudo </span>fips <span class="nb">enable</span> </code></pre> </div> <h2> What I would do differently </h2> <p>I would have checked what authentication and crypto settings the services on the host depend on before enabling FIPS, not after. FIPS is not a single-server change when the server is upstream of Keycloak, Superset and Vault. Mapping the dependency chain first would have made the MD5-to-SCRAM step obvious from the start instead of a fix after the fact.</p> postgres rhel fips security