1. Toward Better Password
Requirements
Jim Fenton
@jimfenton
1

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. First, some context…
3

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. The SP 800-63–3 update
Major rethinking and rewrite
Separates proofing from
authentication
4 documents
Public preview and comments on
GitHub
5

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. 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. Memorized Secrets “Exercise Plays Vital Role Maintaining Brain Health” by
A Health Blog is licensed under CC BY-SA 2.0 8

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 1"
10"
100"
1000"
10000"
100000"
1" 10" 100" 1000" 10000" 100000"
Rank (log scale)
20
Dictionary distribution (log-log scale)

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. 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. 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. 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. 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. Some other authenticators
26

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. 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. 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. 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. How to participate
31
“soccer” by ..Russ.. is licensed under CC BY-SA 2.0

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. Questions?
33