Require case-sensitive password matching? about asvs

[elarlang]

We have requirement 2.1.3:

#	Description	L1	L2	L3	CWE	NIST §
2.1.3	[MODIFIED] Verify that passwords are not truncated. (C6)	✓	✓	✓	521	5.1.1.2

Maybe we can make it more abstract, idea:
Verify that the application compares and hashes the password from the user as it was sent without doing any modification such as truncation or transforming to lowercase.

[Sjord]

Nice, I've shortened it a bit:

Verify that the application verifies the user's password exactly as received from the user, without any modifications such as truncation or case transformation.

[jmanico]

Case sensitivity matters. Many policies want upper and lower case in the past, even though NIST doesnt ask for it now. Forcing lowercase would harm the potency of any policy.

[elarlang]

Never seen it in practice... but whatever the policy is, if an attacker figures it out (and it is not hard to do that), it makes guessing passwords so much easier.

I think it's worth a separate or to be mentioned in some requirement - it is easy to test, easy to (not) implement, and for that effort, it provides a good impact.

[jmanico]

I like that idea, Elar.

[csfreak92]

Wordsmithing it a little bit just to make it clear where we are sending it to:

Verify that the application compares and hashes the password from the user as it was sent to the back-end without doing any modification such as truncation or transforming to lowercase.

What do you think?

[elarlang]

I analyzed my proposal and was able to verify 2 problems:

• it is not aligned with NIST, which allows to replacement multiple consecutive space characters with a single space character
• old-school applications add salt and pepper "manually" to the password and as it happens before hashing, one may interpret the requirement to disallow that

Quotes from NIST SP 800-63B

• To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length.
  https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers
• ... so it may be beneficial to remove repeated spaces in typed passwords prior to verification
  https://pages.nist.gov/800-63-3/sp800-63b.html#a3-complexity

[jmanico]

When setting up a new password during registration we are often asked to enter it in twice. Mistyped passwords during registration is not a common issue IMO. I say we break from NIST and keep away from messing with registered passwords.

[Sjord]

I don't understand why NIST has this exception for multiple spaces. Typing multiple spaces by accident does not seem common to me. Does anyone have more insight into why an exception is added for this particular situation? I think it's reasonable if the ASVS requires application to match as-is, and don't collapse multiple spaces.

I agree that this can be merged with 2.1.3, about truncating passwords.

old-school applications add salt and pepper "manually" to the password and as it happens before hashing, one may interpret the requirement to disallow that

I think this can be solved with a little bit better phrasing. It also depends on what you define as the "hash algorithm", whether that includes adding the salt or only concerns the MD5 function.

Perhaps we can leave it a bit more vague:

Verify that passwords are processed by the application exactly as received from the user, without any modifications such as truncation or case transformation.

Or we can define it more functionally and less technically. Only the exact password that the user configured should give access to the application.

Verify that the application grants access solely based on the exact password configured by the user without any alterations, such as trunaction or case transformation.

[elarlang]

"granting access" goes already away from authentication topic.

One more proposal:

Verify that the application uses the password from the user for password verification exactly as received from the user, without any modifications such as truncation or case transformation.

[elarlang]

I created PR #1814 , also removed CWE as it was not correct.