Password Policy: Known Passwords Check Proposal
Status
Very initial stage - project proposal.
Introduction
Moodle 4.0 supports "Password policy" configurable in Site Administration under Security -> Site security settings.
The following checks can be applied to measure the password quality:
- Password length
- Digits
- Lowercase letters
- Uppercase letters
- Non-alphanumeric characters
- Consecutive identical characters
- Password rotation limit
NIST Special Publication 800-63B, Digital Identity Guidelines advises on another check:
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised.
For example, the list MAY include, but is not limited to:
- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and derivatives thereof.
If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.
This proposal suggest the implementation of the "known password" check above.
Approach
The standard way to check if the password is one of the known ones is to use https://haveibeenpwned.com/Passwords service. An API request can be sent to haveibeenpwned to check the password. It's implemented in a nice way - the original password is not sent to the service, as per https://haveibeenpwned.com/Privacy :
The Pwned Passwords feature searches previous data breaches for the presence of a user-provided password. The password is hashed client-side with the SHA-1 algorithm then only the first 5 characters of the hash are sent to HIBP per the Cloudflare k-anonymity implementation. HIBP never receives the original password nor enough information to discover what the original password was.
However, using haveibeenpwned.com adds external dependency to Moodle installation.
Instead, I'm suggesting the stand-alone approach for the check, with no dependency on the external service:
- A number (say top 1 million) of the most common, known password hashes is shipped with standard Moodle.
- Password hashes are stored in a binary file that allows for quick search.
- A path to the hashes file (this file is really a database) is configurable in Site Administration. This will allow administrators to upload bigger collection of the breached/known passwords.
Technical details
Password database
Each password is a SHA-1 hash and the full data can be downloaded from https://haveibeenpwned.com/Passwords .
Instead of shipping big, over 30GB file (uncompressed), we will:
- Extract and ship by default top (most common) 1 million password hashes
- Change SHA-1 from text to binary format
- Order SHA-1 hashes by their value.
Storing SHA-1 as binary means using 20 bytes per hash. 1 million entries means file size below 20 MB.
Database search
Because the hashes are per-ordered (in the ascending order) and each entry is the same size, then quick, binary search may be used to check if given hash exists in the database.
Configurable path to the hashes database (file)
Optionally site administrator will be able to upload custom file with SHA-1 hashes data. Such a database could contain much more know hashes and have significant size (tens of gigabytes).
Unresolved issues/ideas
Replace binary search with interpolation search
For big databases, interpolation search should be faster than binary search.
Implementation
The core implementation means extending function check_password_policy() from lib/moodlelib.php with the new check.
The alternative is to implement it as a local plugin and https://docs.moodle.org/dev/Login_callbacks#check_password_policy callback.
