@jacobian 1. Possession factor options 2. Implementation questions 3. Two recommendations: a. MFA for public-facing services b. MFA for internal systems
@jacobian 1. Possession factor options 2. Implementation questions 3. Two recommendations: a. MFA for public-facing services b. MFA for internal systems
@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 difficult 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 1. Possession factor options 2. Implementation questions 3. Two recommendations: a. MFA for public-facing services b. MFA for internal systems
@jacobian When should you require a possession factor? Good: upon every login Better: ... and when performing sensitive actions Best: ... and based on behavioral analysis
@jacobian Backup codes? (users don’t save them) Backup phone/emails? (expands attack surface) “Contact support”? (vulnerable to social engineering) How should we handle lost tokens?
@jacobian Backup codes? (users don’t save them) Backup phone/emails? (expands attack surface) “Contact support”? (vulnerable to social engineering) “sorry; deal with it ”? How should we handle lost tokens?
@jacobian Backup codes? (users don’t save them) Backup phone/emails? (expands attack surface) “Contact support”? (vulnerable to social engineering) “sorry; deal with it ”? (not very user-friendly) How should we handle lost tokens?
@jacobian 1. Possession factor options 2. Implementation questions 3. Two recommendations: a. MFA for public-facing services b. MFA for internal systems
@jacobian MFA for public-facing systems: Factor: Require MFA: Lost tokens: Out-of-band communication, or good soft token implementation (Authy) at login, and when performing sensitive actions
@jacobian MFA for public-facing systems: Factor: Require MFA: Lost tokens: 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) based on behavior analysis until real-life identity verification
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).