Is using `crypt` in PostgreSQL for password comparison secure against timing attacks?

Question

I'm currently using PostgreSQL with the pgcrypto extension to store and verify user passwords. When a user logs in, I compare the entered password with the stored hash using the following query:

SELECT id FROM users WHERE email = '[email protected]' AND password = crypt('entered_password', password); 

Note: In this example, the password is passed as a constant, but in the real application, a SQL injection-free method is used.

My understanding is that this approach could be insecure against timing attacks because the use of = operator in the query.

However, I want to confirm with security experts if this method is indeed secure and if there are any potential vulnerabilities or better practices I should be aware of.

Question: Is the use of crypt in this manner secure against timing attacks?

Thank you for your insights!

Answer 1

No, a direct CHAR or VARCHAR comparison in PostgreSQL is not timing-safe.

PostgreSQL internally uses the memcmp function from the C standard library. At least in the GNU C Library (glibc), the function returns early as soon as it encounters a character that doesn't match – and it's hard to imagine any other implementation.

If you want a timing-safe comparison, you need to implement it yourself. You can, for example, iterate over all characters and compare them without returning early. Or you calculate a hash-based message authentication code (HMAC) of both operands and compare those HMACs. Since an attacker cannot calculate the HMACs themself (unless they've compromised the key), timing differences don't reveal anything useful about the password hashes.

Note that there are other issues:

• The crypt function and its algorithms are largely obsolete. Only bcrypt (called bf in pgcrypto) is still somewhat acceptable, but far stronger algorithms like Argon2 have been developed since 1999 (when bcrypt was first published).
• When you hash passwords in the database system, this means you have to transmit the plaintext password first. This greatly increases the risk of accidentally leaking the password, e.g., through the query log or in transit.

It's much better to hash the password in the application. This also lets you use more modern hash algorithms (like Argon2) which aren't currently implemented in pgcrypto.