2.7.5 is a security problem and weakness

[jmanico]

This requirement is a security weakness.

2.7.5	Verify that the out of band verifier retains only a hashed version of the authentication code.

Even 8 numerical digits when hashed are discoverable via rainbow tables.

I suggest we change this to:

2.7.5	Verify that the out of band verifier retains only a hashed version of the authentication code using password storage algorithms such as Argon2id.

[elarlang]

We have separate requirement for password storage:

#	Description	L1	L2	L3	CWE	NIST §
2.4.1	[MODIFIED] Verify that one of the following password hashing functions is used when storing the user's password for the application: argon2id, scrypt, bcrypt or PBKDF2. (C6)		✓	✓	916	5.1.1.2

Do we want to have hashing requirements separately for "usual password" and "out of band verifier" (and also for "lookup secrets")? My question (and a bit recommendation is) - can we move/merge hashing part from those requirements to 2.4.1?

#	Description	L1	L2	L3	CWE	NIST §
2.6.2	[MODIFIED, SPLIT TO 2.6.4] Verify that lookup secrets stored at the back-end with less than 112 bits of entropy (19 random alphanumeric characters or 34 random digits) are hashed with an approved password storage hashing algorithm that incorporates a 32-bit random salt. A standard hash function can be used if the secret has 112 bits of entropy or more.		✓	✓	330	5.1.2.2
2.7.5	Verify that the out of band verifier retains only a hashed version of the authentication code.		✓	✓	256	5.1.3.2

[jmanico]

I like the idea of combining these. Perhaps:

[MODIFIED] Verify that the application employs one of the following robust password hashing functions for securely storing secrets requiring verification. This includes user passwords, lookup secrets, out-of-band verifiers, and similar entities. The recommended hashing functions are argon2id, scrypt, bcrypt, or PBKDF2.

[elarlang]

Feels a bit wordy AI output for me.

What do you think about direction like:

Verify that argon2id, scrypt, bcrypt, or PBKDF2 password hashing function is used when storing the user's password for the application, including out-of-band verifier and lookup secrets.

[jmanico]

I like your requirement text better let’s do this.

[elarlang]

Anything to keep from current 2.6.2 and 2.7.5?

[elarlang]

@jmanico - should we keep anything from the current 2.6.2 and 2.7.5?

@tghosth - what do you think about it?

[jmanico]

Is there a way we can centralize the list of password storage algorithms and have other requirements point to it?

Otherwise is looks good to me.

[tghosth]

This is one of those NIST requirements that hurts my head to read and to be honest I think that it has been misinterpreted.

The NIST requirement talks about an identifying key and an authentication secret. It talks about hashing the former and it talks about the latter having at least 20 bits of entropy.

I think this is one of those sections that is going to need some sort of simplification to be usable so I would suggest either deleting this requirement or leaving this issue open for when someone does the V2 rewrite.

[jmanico]

My only point here is that secrets that only need to be verified (and not reversed) should use a password hash, not a normal hash (message integrity code).

[tghosth]

I propose deleting this as insufficient impact, I don't think this temporary code is important enough or long lived enough for me to care how it is stored.