NetID Password Strength Initiative

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 gt 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 1990s
• Replacement for GAS systemwere 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 populations
  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 NetIDs 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/dictionar
  y 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
  (7424) 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 entropya measure of the uncertainty in the
  value of a password
• Derived from Claude Shannons 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
  Shannons 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 expiredforcing 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.