Align Auth0 Password Capabilities with Current Recommendations from NIST and OWASP

orogers · May 15, 2024, 4:46pm

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?

github.com

OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md

# Authentication Cheat Sheet

## Introduction

**Authentication** (**AuthN**) is the process of verifying that an individual, entity, or website is who or what it claims to be by determining the validity of one or more authenticators (like passwords, fingerprints, or security tokens) that are used to back up this claim.

**Digital Identity** is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service but does not necessarily need to be traceable back to a specific real-life subject.

**Identity Proofing** establishes that a subject is actually who they claim to be. This concept is related to KYC concepts and it aims to bind a digital identity with a real person.

**Session Management** is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forth between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict. The [Session Management Cheat Sheet](Session_Management_Cheat_Sheet.md) contains further guidance on the best practices in this area.

## Authentication General Guidelines

### User IDs

The primary function of a User ID is to uniquely identify a user within a system. Ideally, User IDs should be randomly generated to prevent the creation of predictable or sequential IDs, which could pose a security risk, especially in systems where User IDs might be exposed or inferred from external sources.

### Usernames

This file has been truncated. show original