Implementing Multi-factor Auth (dotSecurity 2016)

Implementing   multi-factor authentication Jacob Kaplan-Moss jacob@jacobian.org Photo by Jordan
Wiseman - https://unsplash.com/photos/AsQs1AziQD4

@jacobian I MFA

@jacobian https://twofactorauth.org/

@jacobian

@jacobian “Oh , I need to add  multi-factor auth.”

@jacobian Why “multi-factor” instead of “two-factor”?

@jacobian Why “multi-factor” instead of “two-factor”? Password IP address User-Agent
User behavior User location “Challenges” ...

“Possession factors” Photo by #WOCinTech/#WOCinTech Chat - https://ﬂic.kr/p/EFQHok

@jacobian 1. Possession factor options 2. Implementation questions 3. Two
recommendations: a. MFA for public-facing services b. MFA for internal systems

@jacobian Possession factor options: 1. Out-of-band communications 2. Soft Tokens
3. Hard Tokens

@jacobian Out-of-band communication e.g. phone calls, emails, SMS, …

@jacobian Soft tokens e.g. Google Authenticator, Authy, SecureAuth, RSA...

https://www.ﬂickr.com/photos/digitalart/2836613675/ Hard tokens e.g. U2F, RSA keys, YubiKeys, PIV cards,
…

@jacobian Criteria for comparing possession factors: 1. Risks 2. User
Experience 3. Cost

@jacobian Risks Can codes be intercepted? Re-used? Brute-forced? Would a
token theft/re-use be noticed? How secure against malware is the factor?

@jacobian User Experience Multi-factor authentication is useless if your users
won’t use it!

@jacobian Cost What’s the implementation cost? What’s the per-user cost?

@jacobian Comparison:

@jacobian Out-of-band communication: Risks Communications can be intercepted Users will
set up forwarding schemes Can be compromised by device malware Delivery is usually to the same device being used UX users are familiar with with SMS easy setup for users re-uses devices users already have typing codes is error-prone, not suitable for frequent auths delays in delivery can cause timeouts, frustrating users Cost Typically free for users. Minimal delivery cost for providers (~ $0.01/message)

@jacobian Soft tokens Risks Can be compromised by device malware.
Typically based around a shared secret, which can be silently stolen. Time-based tokens are vulnerable to theft, brute-forcing, and re-use. Delivery is usually to the same device being used. UX re-uses devices users already have relatively familiar (to experienced users, at least) enrollment can be confusing (TOTP) time skew on devices can make implementation difﬁcult Cost Free to users. Provider costs range from free (e.g. TOTP) to several $/user.

@jacobian Hard tokens Risks “Master keys” can be stolen UX
“just press the button”; can be suitable for frequent auths some tokens can also be used for encryption, signing lost tokens can mean long lockouts no real standards mean token proliferation Cost At least $20 per user

@jacobian

@jacobian When should you require a   possession factor?

@jacobian When should you require a   possession factor? Good:
upon every login

upon every login Better: ... and when performing sensitive actions

upon every login Better: ... and when performing sensitive actions Best: ... and based on behavioral analysis

@jacobian How should we handle lost tokens?

@jacobian Backup codes? How should we handle lost tokens?

@jacobian Backup codes? (users don’t save them) How should we
handle lost tokens?

@jacobian Backup codes? (users don’t save them) Backup phone/emails? How
should we handle lost tokens?

@jacobian Backup codes? (users don’t save them) Backup phone/emails? (expands
attack surface) How should we handle lost tokens?

attack surface) “Contact support”? How should we handle lost tokens?

attack surface) “Contact support”? (vulnerable to social engineering) How should we handle lost tokens?

attack surface) “Contact support”? (vulnerable to social engineering) “sorry; deal with it ”? How should we handle lost tokens?

attack surface) “Contact support”? (vulnerable to social engineering) “sorry; deal with it ”? (not very user-friendly) How should we handle lost tokens?

@jacobian MFA for public-facing systems: Factor: Require MFA: Lost tokens:

Out-of-band communication, or good soft token implementation (Authy)

Out-of-band communication, or good soft token implementation (Authy) at login, and when performing sensitive actions

Out-of-band communication, or good soft token implementation (Authy) at login, and when performing sensitive actions backups codes & phone/email backup; don’t allow support to reset MFA

@jacobian MFA for internal systems: Factor: Require MFA: Lost tokens:

hard tokens (U2F or Yubikey)

hard tokens (U2F or Yubikey) based on behavior analysis

hard tokens (U2F or Yubikey) based on behavior analysis until real-life identity veriﬁcation

@jacobian “Oh , I need to add  multi-factor auth.”

@jacobian “, I get to add  multi-factor auth!”

Thank you! jacob@jacobian.org Photo by Hello Goodbye - https://unsplash.com/photos/uGtdjBMK28s

Credits: Slide deck based on a template by Alice Bartlett:
http://alicebartlett.co.uk/blog/how-to-do-ok-at-slides. Font: Roboto, by Christian Robertson https://www.fontsquirrel.com/fonts/roboto. Photos by: - Unsplash, https://unsplash.com/ - #WOCinTech/#WOCinTech Chat, http://www.wocintechchat.com/ (see slides for individual credits).

Implementing Multi-factor Auth (dotSecurity 2016)

Implementing Multi-factor Auth (dotSecurity 2016)

More Decks by Jacob Kaplan-Moss

Other Decks in Technology

Featured

Transcript