Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Toward Better Password Requirements

29,274 views

Published on

Video now available at end of presentation slides!

Presentation on the Passwords '16 track at BSides Las Vegas discussing the improvements in password requirements being proposed in the NIST SP 800-63-3 preview draft

Published in: Technology

Toward Better Password Requirements

  1. 1. Toward Better Password Requirements Jim Fenton @jimfenton 1
  2. 2. Disclaimer I’m a consultant for NIST, working on the SP 800-63-3 update Everything here is my own opinion; I don’t speak for NIST! I’m discussing a preview draft. Everything is subject to change in the review process 2
  3. 3. First, some context… 3
  4. 4. A little about SP 800-63 Electronic Digital Authentication Guideline Defines requirements to satisfy 4 “Levels of Assurance” (defined by OMB): Registration (especially Identity Proofing) Authentication Assertions Intended for Federal Gov applications,
 used by many others 4
  5. 5. The SP 800-63–3 update Major rethinking and rewrite Separates proofing from authentication 4 documents Public preview and comments on GitHub 5
  6. 6. Guiding principles Strong user experience emphasis. If it’s not user friendly, users cheat. Realistic security expectations. Many things need 2-factor authentication Put burdens on the verifier rather than user wherever possible Don’t ask the user to do things that don’t significantly improve security 6 “Guiding Principles” by Ford-Foundation is licensed under CC BY-ND 2.0
  7. 7. Standards language SHALL: Requirement to be followed strictly; no deviation allowed
 (cf. IETF “MUST”) SHOULD: Particularly suitable possibility, preferred but not necessarily required (cf. IETF “SHOULD”) MAY: A course of action permissible within the limits of the publication CAN: A possibility and capability, whether material, physical, or causal. 7
  8. 8. Memorized Secrets “Exercise Plays Vital Role Maintaining Brain Health” by A Health Blog is licensed under CC BY-SA 2.0 8
  9. 9. What’s in and out in 2016? In: 8 character min, >64 max Dictionary to disallow common passwords Allow all printing characters (Unicode optional) + spaces Out: Composition rules Hints Knowledge-based authn (KBA) Routine password expiration 9 “Can’t help loving that man o’mine” by darwin Bell is licensed under CC BY-NC 2.0
  10. 10. Minimum length OLD: 6 characters/4 random digit PIN (LOA 1), 8 characters/6 random digit PIN (LOA 2) NEW: SHALL be at least 8 characters or 6 random digits Rationale Defends against online attacks (w/throttling) Defense against offline attacks would require much longer minimums Consistent requirements at all AALs (LOAs), old LOA 1 requirements too weak 10
  11. 11. Maximum length OLD: No specification NEW: SHALL accept (and use) at least 64 characters. No truncation. Rationale: Give users maximum flexibility to choose a memorable pass phrase 64 characters fit on many screens “measuring tape” by areta ekarafi is licensed under CC BY-NC-ND 2.0 11
  12. 12. Space characters OLD: no specification NEW: SHALL accept space characters, but MAY canonicalize them out Rationale: Spaces are natural to type in passphrases UI concerns about inadvertently typing multiple spaces, and the space characters themselves don’t add much entropy “the burning of the midnight oil” by Robert S. Donovan is licensed under CC BY-NC 2.0 12
  13. 13. Character set OLD: Alphabet of 90 or more characters NEW: SHALL accept all printable ASCII characters SHOULD accept Unicode, including emojis (1 “character”/code point) 😺 Rationale: Site-specific constraints on special characters have been a UX nightmare Verifier SHALL hash the entry anyway, so SQL injection shouldn’t be a concern “Lead Type (melting in the oven of your mind)” by jm3 on Flickr is licensed under CC BY-SA 2.0 13
  14. 14. Hints and prompts OLD: No requirement NEW: SHALL NOT permit subscriber to store a hint that is accessible to unauthenticated claimant SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?) when choosing memorized secrets Rationale These greatly weaken the authentication 14 “whisper” by ElizaC3 is licensed under CC BY 2.0
  15. 15. Throttling OLD: SHALL limit failed authentication attempts to 100 in 30-day period per account MAY use CAPTCHAs, delays, or IP whitelists when approaching the limit Used for all authentication with ~20 bit authenticator output entropy (e.g., OTP) NEW: Substantially unchanged. Adds use of risk-based or adaptive techniques for throttling Rationale: Many other techniques (e.g., stronger use of IP address) can be easily circumvented by attackers. 15 “Revs Per Minute” by Michael Gil is licensed under CC BY 2.0
  16. 16. Composition OLD: Implement dictionary or composition rule to constrain user-generated secrets (LOA 2) NEW: SHOULD NOT impose composition rules SHOULD compare prospective secrets against dictionary of known commonly-used and/or compromised values. RATIONALE: Composition rules are a UX nightmare, and don’t provide as much value as originally thought Need to study how to ask users to pick something different 16 “Are you freaking INSANE????” by Paige Saez is licensed under CC BY-NC 2.0
  17. 17. Dictionaries: questions How big should the dictionary be? Too small: ineffective Too big: bad user experience (like composition rules, but less transparent) Will users act predictibly when asked to pick a different password? Users might just append something like 1 or ! If so, the dictionary is a great resource for offline cracking 17 “Dictionary” by Caleb Roenigk is licensed under CC BY 2.0
  18. 18. Dictionary investigation What would a good dictionary look like? How big? What’s in it? Started with Burnett’s list of 10M compromised passwords Limited to >=8 characters 4945022 entries, 3199670 distinct passwords 18 “The Worlds Smallest Dictionary” by Kit is licensed under CC SA-NC 2.0
  19. 19. 1" 10" 100" 1000" 10000" 100000" password" 15041988" 27041987" motdepasse" 11011994" 06101990" 03081974" welcome123" hellrais" travolta" bowhunter" 18091968" gjkrjdybr" galatasa" sebring1" 04112002" 5858855abc" 31011999" Vampire1" combined" 31423142" stryker1" greencard" 30031954" pointer1" actually" jackknife" asianpus" griffey2" pc7fddmh" yfcnz1994" Dic$onary*Distribu$on* 19
  20. 20. 1" 10" 100" 1000" 10000" 100000" 1" 10" 100" 1000" 10000" 100000" Rank (log scale) 20 Dictionary distribution (log-log scale)
  21. 21. 0" 50000" 100000" 150000" 200000" 250000" 300000" 350000" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10" 11" 12" 13" 14" 15" 16" 17" 18" 19" 20" Entries(with(>n(occurrences( Occurrences( Dic1onary(size(vs(number(of(occurrences( >=8(characters( 21
  22. 22. Dictionaries: takeaways It’s pretty simple to build a reasonable dictionary Dictionary with size of ~100,000 entries is probably good - but need to test But what do users do when asked to try another password? BadPassword -> BadPassword1 ??? 😰 22
  23. 23. Verifier storage OLD: SHALL NOT store plaintext (LOA 1); MAY salt and derive key or encrypt (LOA 2) NEW: SHALL be hashed with 32-bit random salt using approved key derivation function PBKDF2 with SHA-1, SHA-2 family, SHA-3 family
 (NIST SP 800-131A rev 1, Sec 9) SHOULD do 10,000 iterations SHOULD use keyed hash (e.g., HMAC) with key stored separately (e.g., HSM) RATIONALE: Need to require verifiers to protect password integrity 23
  24. 24. Displaying secrets OLD: No requirement NEW: SHOULD offer option to display the secret rather than dots or asterisks But rehide after some period of time RATIONALE: Displaying the password when not likely to be observed helps typing accuracy, and therefore improves user experience 24 “shoulder surfing” by Anne Petersen is licensed under CC BY-NC-ND 2.0
  25. 25. Memorized Secret expiration OLD: No requirement NEW: Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise RATIONALE: Expiration encourages choice of less complex and/or multiple use secrets. 25 “parking_meter.JPG” by Paul Vladuchick is licensed under CC BY-NC-ND 2.0
  26. 26. Some other authenticators 26
  27. 27. Pre-registered knowledge OLD: User chosen or personal knowledge questions NEW: Eliminated! RATIONALE: Knowledge-based authentication by another name, weak and likely to suffer from reuse on multiple sites 27 “Pip” by Helen Haden is licensed under CC BY-NC 2.0 First pet?
  28. 28. Out of Band authenticator OLD: Uniquely addressable, separate from primary authentication channel NEW: SMS deprecated (more on this to come) Response (only) may be over protected channel OOB device authenticates to verifier using approved crypto 28
  29. 29. SMS as OOB authenticator SMS is deprecated for OOB — may not be acceptable in next revision SMS SHALL NOT be to a VoIP number: that doesn’t establish possession of something you have Rationale: Many threats to SMS including smartphone malware, fraudulent reassignment of telephone number, SS7 attacks, forwarding Users’ phone numbers also change 29
  30. 30. Biometrics SHALL be bound tightly to specific device identified using approved crypto Therefore always part of a multifactor authenticator New performance metrics for false match and nonmatch rates and presentation attack resistance New hard limit (10) consecutive failed attempts Need backup activation factor, e.g., memorized secret MAY use central verifier if other requirements met 30
  31. 31. How to participate 31 “soccer” by ..Russ.. is licensed under CC BY-SA 2.0
  32. 32. Join the conversation Read the preview drafts: https://pages.nist.gov/800-63-3/ Note: continuous update model, expect frequent changes! Review issues on GitHub: https://github.com/usnistgov/800-63-3/issues More instructions: https://pages.nist.gov/800-63-3/comment_help.html Public preview period runs until ~September 17, 2016 “Formal” public comment period will follow 32 “Conversations” by Steve McClnahan is licensed under CC BY-NC 2.0
  33. 33. Questions? 33

×