Innhold
1 Introduction
This document is mandated by https://jira.usit.uio.no/browse/CRB-1687.
It aims at generating suggestions for new and improved password rules for the overall password policy at UiO.
2 Goals for the new password rules
We set the following goals for the password rules:
- clear definition of what constitutes a strong password, considering modern technology and capabilities possessed by a potential attacker
- forcing the users to employ strong passwords and use them properly
- providing the users with the maximum amount of ease and convenience without compromising the criterion set above
3 Research and general considerations
This document will concentrate on defining what is a strong password as well as exploring the level of convenience for each of the current password rules.
Forcing the users to employ strong passwords and use them properly is outside of the scope of this document.
3.1 Password strength
NIST Special Publication 800-63 of June 2004 provides a scheme to roughly estimate the entropy of human-generated passwords.
Many modern systems and organizations use dynamic entropy calculation in order to decide which password is suitable (strong enough) and which not.
Currently the password policies of all Cerebrum partners use static password rules.
Concerns about possible leakage of password hashes due to security flows in Microsoft Windows have been expressed by CERT. For that reason the primary focus of this research has been to examine the technical capabilities of an attacker in running brute-force attack against NTLM and similar weak hashes and key derivation functions.
"In a test, the researcher’s system was able to churn through 348 billion NTLM password hashes per second." "With 348 billion NTLM per second, this means we could rip through any 8 character password (95^8 combinations) in 5.5 hours."
"If key stretching is not used, passwords with more entropy are needed."
RFC4048 8.1 provides the basic math.
3.2 Usability and convenience
Several studies point out the importance of a human-generated password being easy to remember in addition to being strong.
"Passwords that are too difficult to remember may be forgotten and so are more likely to be written on paper"
The are also studies that are arguing that the above statement does not describe a security risk.
We tend to believe that writing passwords on paper is indeed a security risk in a university environment with students changing venues several times a day.
Other studies suggest that enforcing too many constraints on human-generated passwords also tends to annoy users and "forces" them to choose passwords too similar to previous passwords.
4 Assumptions
- the attacker has a potential access to the weakest hash(es) available (NTLM hash used as a reference point)
- password lifetime is enforced (350 days)
- the attacker has a capability of 500 000 000 000 tries per second
- 1 in a 1000 chance required by RFC4048, we want 1 in 100 000
- A password can consist of potentially any characters (encoded in UTF-8) but only ASCII characters (94 characters not counting the space-character) provide the rough basis for our entropy calculation
5 Current password rules and criteria
- length: enforces password length of 8 characters
- ascii_characters_only: permits only ASCII characters to be used in passwords
- space_or_null: spaces and NULL-character not allowed in passwords
- multiple_character_sets: extremely complicated rule, prohibiting certain character-types at certain positions within the password
- character_sequence: prohibits certain sequences of characters (f.i. 'qwertyuiop', 'asdfghjkl')
- repeated_pattern: prohibits "repeated patterns" (f.i. 'ababab', 'abcabc', 'abcdabcd')
- username: enforces that the password should not contain the username of the user.
- owner_name: the password should not contain the (sur)name of the user
- dictionary: checks different parts of the password for dictionary words and/or predefined character sets
- history: should not allow a password too similar to a previous password
6 Evaluation of current rules
- length
- necessary (enforces entropy)
- cheap
- a length of 8 doesn't provide enough entropy
- ascii_characters_only
- protects old and faulty systems from utf-8 and unicode evils
- cheap
- reduces convenience and entropy
- space_or_null
- used to differentiate between passwords and passphrases. (Do we really need a differentiation by use of a known delimiter???)
- cheap
- protects stupid systems
- multiple_character_sets
- enforces a certain degree of unpredictability
- expensive
- greatly reduces convenience and entropy
- confusing
- character_sequence
- enforces a certain degree of unpredictability
- cheap
- reduces convenience
- repeated_pattern
- aimed at enforcing unpredictability (but does it???)
- expensive
- greatly reduces convenience and entropy
- username
- reduces predictability
- cheap
- Cerebrum-DB dependent
- owner_name
- reduces predictability
- cheap
- Cerebrum-DB dependent
- dictionary
- confusing
- very expensive
- reduces convenience and entropy
- history
- doesn't really work
- very expensive
- Cerebrum-DB dependent
7 Password length
Given the assumptions described above, the minimal length of the password should be > ceil(log94(500 000 000 000 * 60 * 60 * 24 * 350 * 100 000)), hence 13
8 Dynamic entropy calculator
A dynamic entropy calculator similar to the one suggested by NIST in 2004 may look like this:
- the entropy of the first character is four bits (points)
- the entropy of the next seven characters are two bits per character
- the ninth through the twentieth character has 1.5 bits of entropy per character
- characters 21 and above have one bit of entropy per character
- a "bonus" of six bits is added if at least 3 of the 4 character types (lowercase, uppercase, digits, punctuation characters) are used or a "bonus" of eight bits is added if there are at least 2 characters for each of those groups (this is the only modification of the original NIST specification)
9 Recommendations
- greatly increasing the password-space, hence increasing the entropy: increasing the minimal password length to 13 characters
- using a dynamic entropy calculator and requiring a minimum score of 33
- reimplementing history to only check whether the password is identical to previous passwords
- removing all other current rules (described above), including the seperate definition of a passphrase