1. NetID Password Strength Initiative Gary Windham Senior Enterprise Systems Architect UITS Computing Services

2. A (brief) history of NetID passwords The UA NetID authentication system went live 6 years ago (January, 2002). No password expiration policy Rudimentary password strength rules:  must be >= 8 characters long  cannot be based on username or real name  dictionary and pattern checks (cracklib)‏ NetID directory was seeded from U Cluster population (general purpose UNIX accounts).  U Cluster established in early 1990’s Replacement for GAS system…were passwords carried over from GAS?  U Cluster password requirements: 6-8 characters 1 non-alpha character no password expiration Ergo, a portion of the NetID population’s passwords have not changed in the last 10-15 years.

3. Why change NetID password policy? Recent security incidents Over the last few years, dramatic increase in the number of systems/applications using NetID for authentication  NetID credentials are used to access everything from email to benefits enrollment  “lowest common denominator” password policy (a legacy from NetID’s U Cluster heritage) no longer feasible higher-risk applications (e.g., ERP) need increased levels of assurance auditor requirements Participation in identity federations

4. Objectives Define threat model Provide means of gauging password strength deterministically, using quantifiable data Tie password strength to password lifetime

5. Identifying the Threats Basic threat models:  offline attack against compromised password database brute-force (attempting all possible permutations of an n- character password)‏ dictionary-based attack  online (over-protocol) guessing attack against targeted username Attacks relying on compromise of the client (e.g., keylogging, trojans) or the communications channel (e.g., packet sniffing of unencrypted data) fall outside the purview of “password strength”.

6. Identifying the Threats (cont.)‏ Sophisticated tools (e.g., John the Ripper, Ophcrack) + computational ability of modern PCs make defense against offline brute-force/dictionary attacks infeasible.  Must make risk of password database compromise as small as possible We can model the probability of success for an online, targeted guessing attack, given certain assumptions.

7. NetID Password Policy Heavily influenced by NIST SP800-63 (“Electronic Authentication Guideline”)‏  Defines “password strength” as “the probability of success of a targeted on-line password guessing attack by an attacker who has no a priori knowledge of the password, but knows the username of the target.”  Defines this probability for different “levels of authentication (LoA).” For example, LoA 2 requires the probability not exceed 2 -14 (1 in 16,384 attempts) over the life of the password.

8. NetID Password Policy (cont.)‏ Constraining In-band Attacks NetID lockout occurs after 7th invalid authentication attempt NetID lockout duration is 15 minutes  Max guessing attempts per account, per day = (7*4*24) = 672 Min password entropy: 30 bits (per NIST algorithm)‏ Max probability of successful in-band guessing attack: 2 -15 (1 in 32,768 attempts)‏

9. NetID Password Policy (cont.)‏ Additional Rules and Constraints Composition  8 character minimum  minimum of 2 character classes passwdqc strength check Password history  last 7 passwords  minimum password age = 24 hours (prevent cycling through old passwords)‏

10. NetID Password Policy (cont.)‏ Entropy Password strength is typically expressed in bits of entropy—a measure of the uncertainty in the value of a password Derived from Claude Shannon’s seminal work in information theory Password Entropy Calculation (from NIST SP800-63)‏ the entropy of the first character is taken to be 4 bits; the entropy of the next 7 characters are 2 bits per character; this is roughly consistent with Shannon’s estimate that "when statistical effects extending over not more than 8 letters are considered the entropy is roughly 2.3 bits per character;“ for the 9th through the 20th character the entropy is taken to be 1.5 bits per character; for characters 21 and above the entropy is taken to be 1 bit per character; entropy “bonuses” for multiple character classes (e.g., digits, special characters, upper & lowercase) and dictionary/complexity checks

11. NetID Password Policy (cont.)‏ Tying it together Given our constants (max probability of successful attack, account lockout attempts/duration, etc), we can determine password lifetime using entropy as our variable: d = password lifetime (in days) l = # of bad password attempts before account is locked : 7 m = account lockout duration in mins : 15 n = bits of password entropy p = max guessing probability : 2 -15

12. This sounds too complicated! # of possible password lifetimes “quantized” to set of four:  45, 90, 180, and 360 days Improvements made to NetID self-service website to provide real- time user feedback regarding password strength  password “strength-o-meter”, a la Google, MSN, etc, based on calculated entropy  shows relationship between strength and password lifetime Advanced warning of password expiration  via WebAuth login page  via email Dealing with account lockout  duration is only 15 min.  NetID website will provide an “unlock my account” utility for the impatient.

13. NetID “Change Password” form

14. Global Password Reset In order to begin enforcing the new NetID password strength policy, all existing NetID passwords must be manually expired—forcing a password change. Expiration will be performed in phases, based on the relative “age” of users’ passwords. Users have been lumped into three major categories:  Category 1: Users whose passwords were “grandfathered” from the U Cluster  Category 2: Users whose passwords were created on the NetID system prior to Feb 2003, when we suffered a system error that resulted in the loss of “password last changed” timestamps  Category 3: Users who have created their NetIDs and/or changed their passwords since Feb 2003

15. Global Password Reset (cont.)‏ An analysis performed this summer on the then-current population of ~70K NetIDs provided the following distribution across the three aforementioned categories:  Category 1: 2,299  Category 2: 6,256  Category 3: 61,062 A frequency distribution (by age), decomposed the third category into 8 equal-sized buckets of ~7600 NetIDs each. Recommended implementation schedule would occur over a 10-week period. Categories 1 & 2 would be expired the first two weeks, category 3 over the remaining 8 weeks.