OWASP ASVS 4.0 Password Policy

Help
,
1

In trying to comply with the latest OWASP password policy standards, I’m running into a few issues. The OWASP ASVS 4.0 (March 2019) password recommendations state:

  • 2.1.1 Verify that user set passwords are at least 12 characters in length. (C6)
  • 2.1.2 Verify that passwords 64 characters or longer are permitted. (C6)
  • 2.1.3 Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced. (C6)
  • 2.1.4 Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.
  • 2.1.5 Verify users can change their password.
  • 2.1.6 Verify that password change functionality requires the user’s current and new password.
  • 2.1.7 Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system’s password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password. (C6)
  • 2.1.8 Verify that a password strength meter is provided to help users set a stronger password.
  • 2.1.9 Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. (C6)
  • 2.1.10 Verify that there are no periodic credential rotation or password history requirements.
  • 2.1.11 Verify that “paste” functionality, browser password helpers, and external password managers are permitted.
  • 2.1.12 Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as native functionality.

Most of these are covered well in Auth0, but I’ve run into a few problems on some. Specifically - in Auth0, I’ve noted:

  • 2.1.4 - Emojis seem to count as 2 characters. If my password policy says 12 characters or more, I can enter only 6 emojis and satisfy the policy.
  • 2.1.8 - The universal sign-on page does not seem to have the ability to have a password strength meter (especially, if following 2.1.9 and not having composition limits - which involves setting password strength to “Low” in the Password Policy Section)

Does anyone know if Auth0 plans to address these?

1 Like
3

Hi team!

We are revisiting older questions to provide solutions to concerns or questions.

  • 2.1.4 - Emojis seem to count as 2 characters. If my password policy says 12 characters or more, I can enter only 6 emojis and satisfy the policy.

Between 4.0.1 and 4.0.2 the OWAP ASVS 2.1.4 updated the policy from:

2.1.4 Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.

to

2.1.4 Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords.

Based on a discussion here → Discussion of unicode password requirement V2.1.4 · Issue #691 · OWASP/ASVS · GitHub

  • 2.1.8 - The universal sign-on page does not seem to have the ability to have a password strength meter (especially, if following 2.1.9 and not having composition limits - which involves setting password strength to “Low” in the Password Policy Section)

In terms of the Password Strength meter, the team is evaluating this feature at this moment. In terms of any update I will make sure to let you know.

Thanks
Dawid

4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.