Toward Better Password RequirementsJim Fenton @jimfenton

1

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

First, some context…

3

A little about SP 800-63Electronic 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

The SP 800-63–3 update

Major rethinking and rewrite

Separates proofing from authentication

4 documents

Public preview and comments on GitHub

5

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

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

Memorized Secrets “Exercise Plays Vital Role Maintaining Brain Health” by A Health Blog is licensed under CC BY-SA 2.0 8

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

Minimum lengthOLD: 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

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

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

Character setOLD: 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

Hints and promptsOLD: 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

ThrottlingOLD:

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

CompositionOLD: 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

Dictionaries: questionsHow 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

Dictionary investigationWhat 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

1"

10"

100"

1000"

10000"

100000"

password"

15041988"

27041987"

motde

passe"

11011994"

06101990"

03081974"

welcome123"

hellrais"

travolta"

bowhu

nter"

18091968"

gjkrjdybr"

galatasa"

sebring1"

04112002"

5858855abc"

31011999"

Vampire1"

combine

d"31423142"

stryker1"

greencard"

30031954"

pointer1"

actually"

jackknife

"asianp

us"

griffey2"

pc7fdd

mh"

yfcnz1994"

Dic$onary*Distribu$on*

19

1"

10"

100"

1000"

10000"

100000"

1" 10" 100" 1000" 10000" 100000"

Rank (log scale)

20

Dictionary distribution (log-log scale)

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(w

ith(>n(occurren

ces(

Occurrences(

Dic1onary(size(vs(number(of(occurrences(>=8(characters(

21

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

Verifier storageOLD: 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

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

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

Some other authenticators

26

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?

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

SMS as OOB authenticatorSMS 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

BiometricsSHALL 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

How to participate

31

“soccer” by ..Russ.. is licensed under CC BY-SA 2.0

Join the conversationRead 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

Questions?

33