,
25 tweets,
5 min read
Read on Twitter
OWASP released v4.0 of the Application Security Verification Standard (ASVS) in March, listing security practices for orgs to design, code, and test apps against. github.com/OWASP/ASVS There was substantial content change in the authentication section, so I'll comment on it.
They state in the V2 Authentication Verification Requirements section that their goal is bringing this standard closer in line with significant authentication changes published by NIST in the SP 800-63 Digital Identity Guidelines update that came out after ASVS v3.0.
There are 57 requirements in section 2 for version 4.0, compared to 26 in same section of 3.0. Around 9 requirements are seemingly removed in 4.0. In the following tweets I’ll share my thoughts on some of these changes to the standard.
Requirement 2.1.1 establishes a minimum password length of 12 characters for users, which is one big divergence from NIST’s minimum of 8 chars. While this is justifiable for security, I do think it will cause protests, especially if dealing with third-party or legacy apps.
2.1.4 asks for support of Unicode characters in passwords. Another good change, and while I don’t have stats I suspect a large number of Internet apps can’t meet this requirement today. Many of them are still struggling just to allow symbols (see @PWTooStrong).
New requirement 2.1.5 says to let users change their own passwords. This seems like a core component of app authentication, but surprisingly there are still sites that don’t do this. My son recently had to call customer service to change his password on a pet ID chip site.
2.1.6 talks about verifying the old password to select a new password, but removes text from older standard about new password confirmation. I suspect that with the addition of 2.1.12 saying to add a password field unmasking option this was for usability: uxmovement.com/forms/why-the-…
Requirement 2.1.7 expands on previous guidance to prevent use of common/weak passwords to specifically recommend use of a 1,000 - 10,000 entry blacklist, either maintained locally or transmitted securely using a third party like @haveibeenpwned or Azure AD Password Protection.
2.1.9 says to eliminate any password complexity policy requirements or restrictions. This places responsibility on blacklists and minimum password lengths to prevent bad user password choices. It's a very contentious change for orgs who've used complexity policies for decades.
Speaking more generally, the migration away from password complexity policies to blacklists is a major shift that needs additional research. If you implement password blacklisting within your org please share your lessons learned, anonymously if needed, so we can all benefit.
New requirement 2.1.8 says to provide a password strength meter to guide users towards choosing stronger passwords or passphrases. However, not all meters are created equally, so I recommend taking the time to select a good one: passwordresearch.com/papers/paper79…
2.1.10 instructs the removal of password expiration policies, which has gained support in recent years. But this goes hand-in-hand with requirement 2.2.1 to implement controls to combat password attacks and reduce the chances of a password compromise leading to account takeover.
Requirement 2.2.2 discourages relying on ‘weak authenticators’ like SMS and email. 2.2.4 and 2.2.7 advocate prioritizing reliance on MFA options less likely to be compromised, like OTP tokencodes, U2F security keys, or client-side certificates.
2.2.3 says to securely notify users following any changes to their credentials, emails, addresses, or if new logins to their accounts occur from a riskier/previously unknown location. The use of push notifications is preferred to better direct user attention to these events.
Requirements in 2.4 expand OWASP guidance on password storage to include aspects like salt randomness and length. But they don’t mention Argon2 or scrypt, instead offering work factor advice for bcrypt and an oddly inflated PBKDF2 iteration count of 100,000 (NIST says 10,000).
They do discuss Argon2 and scrypt in the OWASP Password Storage Cheat Sheet (github.com/OWASP/CheatShe…), so it’s likely these documents just need to be aligned better. The PBKDF2 iteration count discrepancy may just be a typo.
2.5.2 now calls for the elimination of security questions rather than just making sure the ones in use are ‘good’. Many industries, especially US banking, still rely on these for secondary authentication. But with stronger MFA options OWASP thinks they can be phased out.
Sections 2.6 and 2.7 are brand new and describe recommended security elements for Transaction Authorization Numbers (TANs) and out-of-band (OOB) authenticators. These tie back directly to NIST guidance for designing or implementing these solutions.
Section 2.8 likewise gives guidance on one-time password (OTP) authenticator use, with section 2.9 discussing cryptographic security key authenticators (FIDO U2F). You may not develop these functions in-house but should validate that your vendor has done so properly.
Section 2.10 adds further guidance on storage of passwords or API keys used by application code, including not to “rely on unchanging passwords”. I think a better word would be “unchangeable” so they should be updated as needed but not on a set schedule.
So what was removed in the new 4.0 ASVS? Some practices in the old standard may have been considered too basic, such as ‘require authentication for anything non-public’, ‘enforce authentication on the server’, and ‘fail securely to a default deny.’
The old 2.2 is removed which stated “Verify that forms containing credentials are not filled in by the application.” This could be understood to include password managers autofilling credentials, rather than just browsers, which OWASP may have decided to no longer discourage.
One absence is the old 2.23 practice of making sure account lockout due to login failures was flagged separately from administrative account disabling. It was a logical recommendation, so I don’t know if it was also considered too basic or whether it's removal is an oversight.
Also removed is the 2.28 guidance to ‘make sure all authentication challenge responses take the same time.’ Intended to prevent things like timing attacks that leak credential info, this may have been considered too difficult to implement consistently for the value it provided.
Had to continue in a different thread here:
