Presentation on user authentication given at Czech Technical University in Prague on 25 March 2019

1. User Authentication:
Passwords and Beyond
Jim Fenton
@jimfenton
1
Czech Technical University in Prague
25 March 2019

2. Just a little about me…
Consultant (2013-present)
Authentication standards: NIST SP 800-63-3
IETF: REQUIRETLS email security proposal
CSO at OneID (2011-2013)
Authentication startup
Distinguished Engineer at Cisco (-2011)
Various things including DKIM email signatures
2

3. Disclaimer
I’m a consultant for the US National Institute of Standards and Technology
Worked on the SP 800-63-3 update
Currently working on errata, guidance for US agencies
Everything here is my own (hopefully informed) opinion
I don’t speak for NIST!
Please contact NIST if you need an official answer
3

4. Guiding principles
Emphasize user experience
People cheat when things are not user-friendly
Have realistic security expectations
Many things need 2-factor authentication
Burden the verifier rather than user wherever possible
Don’t ask the user to do things that don’t significantly improve security
Remember that the goal is to help real users authenticate, not just stop bad actors
4
“Guiding Principles” by Ford-Foundation is licensed under CC BY-ND 2.0

5. Who are the Users?
Everybody:
Non-English speakers
Homeless people
Disabled veterans
Hospital patients
Physicians
Elderly
Students
Usability needs to consider all of these
5
Photo by Rob Curran on Unsplash

6. What’s a password?
6
Passphrase
Something you know
PIN
Memorized Secret
“Exercise Plays Vital Role Maintaining Brain Health” by
A Health Blog is licensed under CC BY-SA 2.0
Passcode

7. Attacks
Online
Various types of guessing
Offline
Attacks on the verifier
Side channel
Shoulder surfing and more sophisticated attacks
Both targeted (e.g., spearphishing) and bulk: very different goals
7
“Under attack!” by Noel Reynolds is licensed under CC BY 2.0

8. Online attacks
Guessing the password
Brute force attacks
Password stuffing (passwords this user
uses elsewhere)
Common defenses
Throttling (more on this later)
Password reuse avoidance (education
primarily)
Prohibition of very common passwords
8
“On the Air” by Thomas Hawk is licensed under CC BY-NC 2.0

9. Offline attacks
Reversing password hashes (cracking)
More efficient with time: Moore’s Law
Benefits from cryptocurrency mining
technology, GPUs, etc.
Defenses
Time- and memory-hard hash algorithms
Supplemental keyed hashing
Protecting hashes better!
Generally harder to defend against than online
9

10. Side channels
Obtaining the password through leakage
Shoulder surfing
Key loggers and other malware
Acoustic, key wear, and similar analysis
Electromagnetic (TEMPEST), timing, and power drain analysis
10
“shoulder surfing” by Anne Petersen is licensed under CC BY-NC-ND 2.0

11. Password length
Increasing length is the most reliable way of strengthening a password
So just require very long passwords?
No. Have a rationale for length requirements
Don’t drive users to Post-It® notes
11

12. What are you defending against?
~8 character passwords are
effective against online attacks
(with reasonable throttling)
But it takes more than twice as
many characters to provide
similar protection against offline
attacks
12
Florêncio, Dinei, Cormac Herley, and Paul C. van Oorschot. “An
Administrator’s Guide to Internet Password Research.” Usenix
LISA, November 2014.
http://research.microsoft.com/apps/pubs/default.aspx?id=227130.

13. Maximum length
Don’t limit users’ ability to use long (secure!)
passwords!
Suggest accepting 64 characters or more
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
13

14. Space characters
Spaces are natural to type in passphrases:
Allow them!
Consider normalizing multiple consecutive spaces to one
UI concern: inadvertent typing multiple spaces is hard to see
Space characters themselves don’t add much entropy
(This is controversial)
“the burning of the midnight oil” by Robert S. Donovan is licensed under CC BY-NC 2.0
14

15. Character set
Give users maximum flexibility to choose
passwords in their native language
Accept all printable ASCII characters
Accept Unicode, including emojis (1 “character”/code point) 😺
Rationale:
Site-specific constraints on special characters have been a UX nightmare
Verifier needs to 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
15

16. Hints and prompts
tl;dr: Don’t do it!
Hints (user-chosen)
Users sometimes choose hints like “Password is qwertyui”
Need to be stored in the clear or reversibly encrypted to be displayable to the user
Prompts (site-chosen)
Typically take the form of “security questions”
Answers often shared between different services (e.g., first pet)
16
“whisper” by ElizaC3 is licensed under CC BY 2.0

17. Composition rules
Rules specifying what character classes
must be in passwords
Avoid using them:
UX nightmare
Don’t provide as much value as originally thought
May not be applicable in other languages
Use a blocklist dictionary instead
17
“Are you freaking INSANE????” by Paige Saez is licensed under CC BY-NC 2.0

18. 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
18
“Dictionary” by Caleb Roenigk is licensed under CC BY 2.0

19. What if someone picks a bad
password?
If a user picks a password that’s in the dictionary, this is a teaching
opportunity 😀
CMU has done some research on this [Habib 2017]
Password strength meter might help user pick something stronger
19

20. 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 watch out for that second password pick
BadPassword -> BadPassword1 ??? 😰
20

21. Displaying passwords
Much of the time, users aren’t subject to
shoulder-surfing attacks
Consider offering option to display the password rather than dots or
asterisks
But rehide after some period of time
Displaying the password when not likely to be observed helps typing
accuracy, and therefore improves user experience
21

22. Password expiration
Don’t require users to change passwords arbitrarily
(e.g., periodically)
If users know their password will be only temporary:
They won’t invest the effort in choosing and learning a complex one
They’ll pick something similar to the old password
But do require change if there is evidence of compromise
Have a way to do this, if/when needed.
22
“parking_meter.JPG” by Paul Vladuchick is licensed under CC BY-NC-ND 2.0

23. Designing password verifiers
23

24. Hashing
Goal: Make it hard for someone who compromises the verifier to learn the
password(s)
Simplistic approach:
Store sha256(password)
But: Attacker could try lots of passwords and see what matches
But also: Attacker can easily see if two users have same password
24

25. Salting
Addresses uniqueness of hash for a given password
At password establishment, choose a random value (“salt”)
Store salt, sha256(password || salt)
Foils look-up tables (or makes them very big), duplicate searches
But: it’s still really fast. Attacker can just guess
25

26. Iterated hashing
Goal: make guessing more expensive for the attacker
Store salt, iteration count “n”, pbkdf2(password || salt, n). But:
pbkdf2 runs well in graphics processors, doesn’t require much memory
Benefits from technology developed for cryptocurrency mining
Example:
pbkdf2_sha256$30000$Da4AnjGEyPCK$WjRjDzeJTaFzLzDWXV0av0Z5jE7o8mDFEfP9cPvQ9
BQ=
Algorithm $ Iteration count $ salt (base64) $ hash (base64)
26

27. Time and memory hardening
Good algorithms for password hashing are:
Slow - requires processor resources (“time hard”)
Memory consumptive - requires memory resources (“memory hard”)
Attackers have access to great CPU resources, specialized hardware
Popular algorithm: bcrypt
27

28. Keyed hashing
Supplemental hash with key stored separately
Generally best to do hashing in separate processor
Could be a hardware device (HSM) for best security
If key doesn’t leak, hash can’t be cracked!
Simple example: GitHub jimfenton/rehash
28

29. Case study: Adobe®
Reported October, 2013
130,325,129 records containing:
Email address
Encrypted password (not salted)
Password hint (not encrypted)
56,044,956 distinct encrypted passwords (many duplicates)
29

30. Adobe
Problems:
Passwords used by multiple people have the same stored value
Correlation of hints is possible — this is actually a fun game!
Email address facilitates credential stuffing on other services
Successes:
Encryption key apparently not breached (but who can be sure?)
Cracking of hashes not possible because of key
30

31. The Adobe game
31
0agIJWqXa2Y= (697 records, 276 hints, 152 distinct hints)
chugalug
same
beverage
kitty
drink
uncle drunk -
chien
Glenlivet
drunk
booze
whiskey
horse
tape
sweet
andrews son
p
male cat
liqour
What's my dog's name?
cat
whos ur dawg
bunny
Border Collie
your favourite liquor
doggy
dog
tapes
reuse
mu dog
normal
sticky & plaid
black label
favorite drink
geknipst
my dog
puppy!
alcohol
aged 25 years
whisky
school
attaccare
friendf
ehhhhhhhh
dimple
dogs
scortcher
pets name
ura
Irish Setter
First Dog
fave horse
golden
normal one
carpetCleaner
favorite liquor
john's password
mon chien
hi priced liquor
gina
minou
tape?
my dogs name
what i drink
usual
its the same ol brand
boycatname
same as always
lijm
Better than Cats
plakband
Dog On Habbo
on the rocks
college
bant
Dewers
Name of Dog
drink and tape
Fav. Disney 1
?????????
Cutts nickname for me
scotland
tacataca
ZK
a good drink
favourite cat
publish
cat name
scotc
sc
SVR
cats first name
little one
montreal
????
drotch
liquor
cat's name
yellow snake
me
short
Dog's name?
mom's dog
lenrelax
partner
puppy
FPIS Favorite
favorite drink haha
loly
land
down in my belly
highland vid tape mfr
woof
first horse
estimac?o
c?o
speyside
malt
Pet
cats name
regular
dizzle
gatto
libation w/o number
johnny walker
persian
alex
name of school in
Hawthorn
Tony & Lou Drink
new dog
buro
favourite drink
college australia
pyranees
zelda
pet's name
first first
single malt
yummy beverage
nom du chien
nationality
the usual
Favorite Dog
DTH favorite beverage
favorite team
log in pass
trunek
albert minus wendy
Hund
Same drink
cinta magica
Horse name
Omi

32. Adobe — Lessons
Lack of salt causes one breached password to impact perhaps hundreds of
accounts
Password hints are evil
Often easier to protect one key stored separately than a large database
32

33. “Security” questions
Also known as Knowledge-Based Authentication (KBA)
Aren’t these just passwords with hints?
Something you know, so KBA+password isn’t 2-factor
Low entropy, likely to be reused on multiple sites
Can’t be hashed if fuzzy matching is needed
33
“Pip” by Helen Haden is licensed under CC BY-NC 2.0
First pet?

34. Case study: Ashley Madison
Data breach, July 2015
Included cleartext answers to KBA questions
Limited choice of questions, e.g., “What high school did you attend?"
Popular answer, Central High School, was represented in many ways:
central hi, Central HS, Central, etc.
34

35. Beyond Passwords:
2 Factor Authentication
35

36. Look-up secrets
Take many forms, often wallet cards or sheets of “recovery secrets”
What you have is the piece of paper, card, etc.
Advantage: inexpensive, easy to use for very occasional authentications
Disadvantage: Limited number of authentications possible
36

37. Out-of-band authenticators
Out-of-band communication to confirm possession and control of “something you have”
Can work in different ways:
Authentication secret sent through separate channel to user, entered on primary channel
Authentication secret sent on primary channel, sent by user on secondary
User compares secrets on primary and secondary channels, confirms on secondary
Requirements
Uniquely addressable, separate from primary authentication channel
Use good crypto (secondary channel isn’t necessarily TLS)
Authenticate the OOB device securely
37

38. SMS as OOB authenticator
Plaintext SMS is very popular for OOB authentication, but isn’t very good
Better than single-factor, but worse than most second factors
Easy for attackers to get a target’s phone number reassigned to a device they control
Need to accommodate users who change their phone numbers or phones
Also: SS7 attacks, forwarding, smartphone malware
Make sure the SMS doesn’t go to a VoIP number — wouldn’t establish possession of something
Encrypted SMS (using secret stored in SIM) is OK
Applies to PSTN voice as well
38

39. OTP devices and apps
Two types: time-based and usage-based
At least 6 decimal digits of output (~20 bits entropy)
Use throttling to foil guessing attacks
Disadvantage: Verifier has to store the user’s RNG seed, this could be
compromised (RSA Security breach, 2011)
39

40. Cryptographic devices and software
Take many forms:
Smart cards
USB devices
NFC or other wireless connected devices
Client certificate (software)
Always directly connected to endpoint
40

41. Cryptographic authenticators
Implement a challenge-response protocol with the verifier
Contain a secret, typically an asymmetric private key
May implement strong man-in-the-middle resistance, discussed later
41

42. Biometrics
Not nearly as good as they’re often portrayed
Zero-effort attacks: typically 1 in 1000 to 1 in 10,000 false accept rate
False reject rate too, especially under adverse conditions
They don’t work under all conditions
Fingerprint with dirty or wet hands
You leave biometrics everywhere
Hard to revoke
42
“Wine at Sunset” by David McLeish is licensed under CC BY-SA 2.0

43. Biometric modalities
Physical
Fingerprint
Iris pattern, retina
Face geometry
Voice
43
Behavioral
Typing cadence
Walking gait
For authentication, performance is the primary consideration

44. Biometrics and measurement noise
There is always measurement noise
(dust, etc.)
Threshold represents tradeoff between
false match and false no-match
Want low false match rate, but don’t
want frustrated users
Effort by impostor can move red graph
to right, increasing P(FM)
44
Threshold
P(false match)P(false no-match)
Match quality
Probabilitydensity
Correct userIncorrect user

45. Using biometrics effectively
Bind biometrics tightly to a specific authenticated device
Therefore always part of a multifactor authenticator
Mitigates revocation problem (revoke the associated device)
Impose a hard limit (10) consecutive failed attempts
Looser limit is OK if Presentation Attack Detection (PAD) used
Have a backup activation factor, e.g., memorized secret
This addresses attempt lockout, poor conditions
45

46. Common Considerations
46

47. Throttling
Primary defense mechanism for online attacks
Example: Limit failed authentication attempts to 100 in 30-day period per
account
Consider using CAPTCHAs, delays, or IP whitelists when approaching the
limit
Consider use of risk-based or adaptive techniques for throttling
Don’t over-throttle: can result in denial of service for legitimate user
47
“Revs Per Minute” by Michael Gil is licensed under CC BY 2.0

48. Verifier impersonation resistance
AKA “Phishing Resistance”, “Strong MITM Resistance”
Goal: make it impossible for a man-in-the-middle to authenticate their own session
Do not depend on the user to detect fraud
Establishes a binding between the authentication and the TLS session it uses
All VIR authenticators are cryptographic, but
not all cryptographic authenticators are VIR
Examples: client-authenticated TLS, FIDO
48

49. Attestation
If a user supplies their own authenticator, how do you know how strong it
is?
Attestation certificates describe the authenticator
Avoid identifying a specific authenticator, if possible (privacy issue)
Particularly important when user can access/manipulate information other
than their own
49

50. Verifier compromise resistance
Extent to which a compromise of the verifier gives the attacker the ability to
authenticate
Generally determined by the authenticator type
Public keys (most cryptographic authenticators) are considered VCR
Symmetric keys (OTP verification) not VCR
Passwords may or may not be, depending on how stored
50

51. Replay resistance
Extent to which authentication is immune to recording/replay attacks
Resistant:
Challenge/response protocols (with nonces), e.g. crypto authenticators
OTP devices, look-up secrets
Passwords are not replay resistant
51

52. Authentication intent
Goal: block access to directly-connected authenticators by malware
Approaches:
Hardware button (e.g., FIDO)
Re-entry of PIN
Reconnection of authenticator for each authentication
52

53. Two-factor authenticator or two
authenticators?
53
Two-factor authenticator Two authenticators
Fewer authenticators to manage
Easier to determine strength of BYO
authenticators
Less centralized storage of activation secret
Easier to throttle activation secret guesses
(at verifier)

54. Questions?
54

55. Bibliography
[Herley 2012] Herley, C., and P. Van Oorschot. 2012. “A Research Agenda Acknowledging the Persistence of
Passwords.” IEEE Security & Privacy Magazine 10 (1): 28–36. https://doi.org/10.1109/MSP.2011.150.
[Florencio 2014] Florêncio, Dinei, Cormac Herley, and Paul C. van Oorschot. 2014. “An Administrator’s Guide to Internet
Password Research.” Usenix LISA, November. http://research.microsoft.com/apps/pubs/default.aspx?id=227130.
[Grassi 2017] Grassi, Paul A, James L Fenton, Elaine M Newton, Ray A Perlner, Andrew R Regenscheid, William E Burr,
Justin P Richer, et al. 2017. “Digital Identity Guidelines: Authentication and Lifecycle Management.” NIST SP 800-63b.
Gaithersburg, MD: National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-63b.
[Habib 2017] Habib, Hana, Jessica Colnago, William Melicher, Blase Ur, Sean Segreti, Lujo Bauer, Nicolas Christin, and
Lorrie Cranor. 2017. “Password Creation in the Presence of Blacklists.” In Proceedings 2017 Workshop on Usable
Security. San Diego, CA: Internet Society. https://doi.org/10.14722/usec.2017.23043.
Apple, Inc. “Face ID Security”, November, 2017. https://www.apple.com/business/site/docs/
FaceID_Security_Guide.pdf.
55