Passwords are hashed with bcrypt at cost factor 5, below the OWASP minimum

[serendipty01]

What happened

hashPassword in server/services/userManagementService/utils.ts hashes passwords with bcrypt at cost factor 5.

Why this is a problem: bcrypt's cost factor is the only thing that makes offline brute-forcing of a leaked users.password column expensive, and it scales exponentially — each +1 doubles the work per guess. OWASP's minimum recommendation is 10; at cost 5 an attacker who obtains the password column (SQL injection, stolen backup, exposed replica) can run a dictionary attack roughly 32× faster than against the OWASP floor, putting every weak-to-moderate password within practical cracking range.

Agreed resolution

Rather than raising the bcrypt cost factor — which would churn the hash format now and again later — move straight to Argon2id, per OWASP's current recommendation: a minimum of 19 MiB of memory, 2 iterations, and 1 degree of parallelism. (Discussed in #901.)

Note that no migration is possible: re-hashing requires the plaintext password, which is only ever in memory for the instant of a login. Existing bcrypt hashes must therefore keep verifying indefinitely, and are upgraded opportunistically after a successful password check.

Version/commit

No response

Affected browser(s)

No response

Relevant logs/errors

Anything else

References:

• https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#argon2id
• https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#bcrypt
• https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-cryptography-with-passwords/
• https://soatok.blog/2024/11/27/beyond-bcrypt/

Screenshots

No response

Checklist

• I’ve reviewed and agree to follow the code of conduct