- 🇵🇹Portugal jcnventura
I still think that the default being TRUE would be easier for us maintainers, but I don't truly care about that. The one thing should be that the update hook for existing installations should leave it as TRUE, so as to not suddenly change running sites. However, the release that contains this should warn site admins to change the setting, in order to have better security.
- 🇺🇸United States cmlara
It is worth considering SA-CONTRIB-2025-085 would not have been possible if the codes were hashed using only a 1-way algorithm.
It is worth referencing NIST-800-63b rev3 section 5.1.2.2
Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks. Look-up secrets having at least 112 bits of entropy SHALL be hashed with an approved one-way function as described in Section 5.1.1.2. Look-up secrets with fewer than 112 bits of entropy SHALL be salted and hashed using a suitable one-way key derivation function, also described in Section 5.1.1.2. The salt value SHALL be at least 32 in bits in length and arbitrarily chosen so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each look-up
(The draft of version 4 is even more strict and calls for a password hashing algorithm for those codes less than 112bit’s entropy)Given above I would suggest v2 implement this request as mandatory for v2 with non reversible storage of recovery codes.