Mobile authentication is moving towards a passwordless future. Push authentication uses device push notifications to securely authenticate users, providing an easy to use second factor that is more secure than passwords. FIDO authentication standards allow for pluggable local authentication on devices through public/private key pairs to securely authenticate users without passwords.

1. Mobile Authentication
Moving Towards a Passwordless Future
David Luna
david@luna.co.uk
2016

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

4. Outline
• Authentication (the ludicrous-speed version)
• Underlying Technical Components (in brief)
• OATH
• Push
• FIDO
• Summary

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

12. Demo

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

17. Push- How does it work?
Registration
Authentication

18. Demo

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/

24. Registration
Authentication
FIDO UAF- How does it work?
Images 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