Feature: Provide password requirement definition capabilities that allow your clients to define policies that align with NIST and OWASP recommendations
Description: Currently Auth0 has in place some limitations that are either in direct contrast to best practices outlined by NIST and OWASP or that make compliance with their recommendations extremely challenging or impossible. This seems odd for a product meant to provide high-quality authentication security for your clients and their customers. Yes, I realize there is a “movement” to kill passwords. But no, that’s not going to happen in sufficient volume in the near term that paying no attention to passwords makes sense.
Use-case: There are actions that Auth0 either currently takes with regard to password definition rules–or that Auth0 does not support–that are recommended or even required in the memorized secrets guidelines put out by NIST and/or the OWASP recommendations for password strength.
Firstly there is the matter of silent password truncation at 72 bytes. I’ve read that this size limitation is a result of the hashing algorithm Auth0 has chosen to use. Seems perhaps a bit short-sighted. How do we convey to people who we are asking to define a password what the upper bound of length is? Unicode characters (support for which is recommended by both OWASP and NIST) are variable in terms of byte size. Also, is it really a good idea to store a password hash that will, in some use cases, not be representative of the full password provided by the user? And to allow that non-representative password to be used to access the account?
Any chance of making some improvements in this area?