Looking for information or guidance on how to best use Auth0 while also following the latest OWASP security standard v4.0.
From the standard, section V2.1 covering password requirements. Auth0 does by default and design follow most of the verifications outlined. However it does not encourage or make several possible.
- 2.1.3 Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced.
- 2.1.6 Verify that password change functionality requires the user’s current and new password.
- 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.
2.1.3 - It is explained in a FAQ here that passwords beyond 72 bytes are ignored, and therefore truncated. And with not being able to set a maximum length easily, this makes it difficult to avoid passwords being truncated.
2.1.6 - The current reset password flow requires a user have access to their email address but not to provide their existing password. There are two open requests for these features here and here.
2.1.8 - There is no current password meter functionality on any input forms of pages from Auth0. There is a community request to have one here.
2.1.9 - Current Auth0 interface recommendations are opposite and contradictory to this verification. The password policies in Auth0 enforce the requirement of certain characters. The documentation makes reference to the OWASP standard here. The current auth0 policies are in conflict with this standard;
- Allow usage of all characters including unicode and whitespace. There should be no password composition rules limiting the type of characters permitted.
On this blog by Auth0 the description of what a secure password is directly conflicts with the current password policies and strength requirements within Auth0. From that blog;
However, additional research shows that requiring new passwords to include a certain amount of complexity can actually make them less secure. And that’s why NIST has also removed all password-complexity requirements from their guidelines.
For example, many companies require that users include special characters, like a number, symbol, or uppercase letter, in their passwords to make them harder to decrypt.
Unfortunately, many users will add complexity to their password by simply capitalizing the first letter of their password or adding a “1” or “!” to the end. And while it technically does make a password more difficult to crack, most password-crackers worth their salt know users tend to follow these patterns and can use them to reduce the time needed to decrypt a stolen password.
Additionally, as password complexity increases, users tend to reuse passwords from account to account, increasing the risk that they could be the victim of a credential stuffing attack if one account is breached.
So instead of forcing users to create more complex passwords, ask them to create longer ones if you want to improve password security.
While some of these can be addressed and configured so they comply with the standard, in some cases this is non trivial to do and in other cases it is not possible. In some cases the contradiction is actually portraying the opposite of best practices and standards.
Are there any plans or discussions to work towards these practices being updated to more easily comply with the OWASP standard?