Password Policy: Known Passwords Check Proposal: Difference between revisions
Tomasz Muras (talk | contribs) No edit summary |
Tomasz Muras (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
= Status = | = Status = | ||
Very initial stage - project proposal. | Very initial stage - project proposal. | ||
= Introduction = | = Introduction = | ||
Moodle 4.0 supports "Password policy" configurable in Site Administration under Security -> Site security settings. | Moodle 4.0 supports "Password policy" configurable in Site Administration under Security -> Site security settings. | ||
| Line 24: | Line 25: | ||
* ''Context-specific words, such as the name of the service, the username, and derivatives thereof.'' | * ''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 = | = 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 passwords. | |||
= Unresolved issues/ideas = | = Unresolved issues/ideas = | ||
= Tasks = | = Tasks = | ||
Revision as of 15:21, 27 April 2022
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 passwords.
