2. Introduction
• David Luna, Software Engineer at ForgeRock
• Part of the team that develops OpenAM
• Worked on Push and OATH implementations
• Not a fan of passwords
3. Why Not Passwords?
• Knowledge-based authentication:
• password - weak
• password1 - weak
• p4sS:w0rD - weak
• k33p,a:littl3!b1rdHoU5eInURS0ul - not bad… but
try typing it on a phone
5. Authentication
• The act of confirming the identity of a person by validating their
identity documents
• Factors
• Knowledge-based: Something the user KNOWS (passwords…)
• Ownership-based: Something the user HAS (security tokens,
mobile phones…)
• Inherence-based: Something the user IS (biometrics…)
• “2FA” - Using first one, then a “second factor authentication”
• “multifactor” - Using many in tandem
6. Tech Components
• OTPs - One-Time Passwords
• Not re-usable
• Generally automatically generated by a machine and either:
• Told to the user
• Used machine-to-machine
• Can be emailed to people on request (e.g. Steam)
• Can be produced by a device on a dongle or the phone in
your pocket
7. Tech Components II
• HMAC - Keyed-Hash Message Authentication Codes
• Uses a secret key, and a cryptographic hashing function to produce a
message authentication code (MAC)
• Hashing just SHA1 / SHA256 on its own is vulnerable to attack (length
extension attack)
• Defined in RFC2104 - Pseudo-Code here is from Wikipedia
8. Tech Components III
• Public-key Cryptography
• Keys are produced in pairs:
• private
• public
• Keep the private one… well, private
• Share the public one without whomsoever you wish
• Messages encrypted by the public key can only be decrypted by the
private key’s holder
• Messages signed by the private key can be verified by holders of the
public key
also from Wikipedia
9. OATH- What is it?
• Initiative For Open AuTHentication (2005)
• Two defined standards:
• HOTP - HMAC One-Time Password
• TOTP - Time-based One-Time Password
• Hardware and software tokens (implementations) exist
• Both standards produce a 6-8 digit number
• User copies the code from their token to wherever it’s needed
• Server verifies that the code exists within an appropriate window of allowed
codes, success if so, failure otherwise
• We’ll use OpenAM’s implementation as our example
10. OATH- How does it work?
• Registration
• User is pre-authenticated using legacy auth, selects to register
for OATH
• Server generates sharedSecret for the user’s account
• Transfers this secret, along with OATH configuration
parameters to the token - or otherwise manually entered
• OpenAM uses QR codes to transmit
• Registration prompts for authentication using the new token
before committing the newly minted device to the user’s profile
11. OATH- How does it work?
• Authentication
• Uses a moving counter which must stay in sync between server and token
• HOTP(sharedSecret, counter) = truncate(HMAC-SHA1(sharedSecret,
counter))
• TOTP is HOTP where the counter is based on the number of time intervals
since an epoch
• Requires clocks to remain in sync
• Cannot move past the available window by repeated requesting of tokens
• The truncate function reduces the 160-bit output of the HMAC-SHA1 function
down to 4 bytes
• Finally we generate a 6-8 digit by using the HOTP output, mod 10^d, where d is
the number of digits we desire
13. OATH- Usability
• Hard to use, somewhat secure, prone to user error
• Hardware tokens run out of batteries/break
• Pure ownership factor - if you have the token, you have the auth
factor
• Only suitable as a second factor
• If server is compromised, user’s shared secret and counter
information is compromised
• The attacker can configure a token with the same parameters
as the user by reading data alone
14. Push- What is it?
• “Push” is not the name of the authentication method, but delivery mechanism
• Often used for chat programs - FaceBook Messenger, etc.
• Implemented by mobile OSes, Android, iOS, etc.
• Method of getting a message directly to a specific mobile device
• Can use notifications to draw attention to the message when received
• These notifications can work in tandem with an app on a phone to perform
authentication to a remote server
• Gaining traction at the moment, Google Prompt released last month
• We’ll use OpenAM’s implementation as our example
15. Push- How does it work?
• Registration
• User is pre-authenticated using legacy auth, selects to register for Push
• Server generates sharedSecret for the user’s account
• Transfers this secret, along with a challenge made up of random bytes to the
user
• OpenAM uses QR codes to transmit
• Server calculates the response to the challenge, by performing HMAC-
SHA256(sharedSecret, challenge)
• Phone performs the same calculation
• Phone requests a unique identifier for itself from its service provider (Google’s
GCM, or Apple’s APNS)
16. Push- How does it work?
• Registration (continued…)
• Phone transmits result of calculation to server along with its device identifier on
the network as well as the phone type, wrapped in a Signed JWT, over https
• Server verifies this result against its pre-calculated response
• If they match the server stores the credentials, returns HTTP 200 to the
phone and it does likewise
• Authentication
• Very similar to registration
• Challenge is sent via push this time
• Phone doesn’t need to talk to its service provider
19. Push- Usability
• Easy to use, secure, flexible… but no standard (…yet?)
• If device is stolen and there’s no additional security on the device itself
then the authentication factor is fully owned by the thief
• One-touch login can be offered - much less prone to error than
copying in a code from a screen manually
• If the server is compromised, shared secret can also be compromised
• Attacker can only take control of the token by writing a new device
location to send the authentication messages
• Easy for a user to comprehend
• At the mercy of mobile’s ability to receive a push notification
20. FIDO- What is it?
• Fast ID Online
• Unlike Push it’s a standard for online auth
• v.1.0 of the specification released in 2014
• Steady adoption, but devices need to be certified
• Allows for pluggable local authentication to a user-owner device
• Two protocols in the spec - UAF and U2F
• We’ll focus on UAF as it’s the passwordless flow, but U2F is very
similar
21. FIDO- How it works
• Registration
• User is pre-authenticated using legacy auth, selects to register for FIDO
• FIDO acts through extensions in client - app, browser or OS; to locate
FIDO Authenticators
• Authenticator decouples the authentication method on the local device
from the message sent to server
• Allowing for pluggable local authentication
• The UAF protocol allows the service to select which local authentication
mechanisms are presented to the user
• Secures communication to client vis TLS - server’s private key must be
kept secure & be trusted by client CA list
22. FIDO- How it works
• Registration
• Once locally authenticated, device mints a cryptographic key pair unique to:
• this user
• for this device
• on this service
• Stores the private key in secure memory
• Sends the public key to the service
• Sends the local authenticator’s attestation to the service
• Authentication
• Same process, but authenticator simply performs local auth
• Signs a challenge if local auth success
• Sends back to server
23. FIDO- How it works
Image from https://fidoalliance.org/
25. FIDO- Usability
• Easy to use, flexible, good security, standard
• Authenticators registered to central authority
(FIDO Alliance)
• FIDO authenticators can be revoked by FIDO
Alliance
• If server is compromised attacker can only
retrieve public key
26. Summary
• Passwordless authentication is a reality in 2016
• If you’re implementing today:
• Simple OTPs are a good place to start
• Best used as 2FA though, rather than passwordless
• Push is a good go-to right now
• Look at how FIDO could help you in future when support is
widespread
• Increased security
• Small administration overhead
