Generic MFA Token Recovery – The good the bad and the ugly

Generic MFA Token Recovery: The Good, The Bad & The Ugly

Thursday 13H

Convener: Niels Van Dijk

Notes-taker(s): Nick Roy & Niels Van Dijk

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Notes from Nick Roy:

Currently implementing webauthn for a number of IdP products

Webauthn is easy

Key recovery is hard

In the old password reset scenario, you still had a database of email addresses.

For second factor recovery, or primary authn factor recovery, sending an email is a bad practice

Force people to register more than one second factor, use the spare for recovery

- Works well assuming the strenghth of both is comparable

- Could be expensive

- Crank up the pain until they do what you want - break SSO, etc.

- The recovery factor must be of the same type - something you have == something you have

Print out sufficiently high entropy recovery code (could encode this in the seed quest game)

- Must be single use

- Having too many recovery methods adds risk

Lock the user's account when they recover via email, so the "real" user has a chance to react if it's an attempted take-over

Dead-man's switch - account recovery keys kept by others (trusted third party/social key recovery) become active only after account inactivity

Key sharding - n of m

- Have to gamify it / make it fun

- Shard it / immediately distribute. Then if you need to use it, you have to recover a bunch of those

Use part of what the org knows about you to recover (basically KBA)

- Enterprise, send reset token to your manager

- Ask questions about things that are in your email, your social network, that that org knows

- You can't claim that it's two-factor if you're using KBA to recover the second factor

- Open to social engineering

- Incentivizes phishing

Use of a guardian to do key recovery

- Everyone who you pick as your "buddies" have to be enrolled in the second factor

Physically go to a place to get your identity re-proofed

- Or via video

- Doing this in southeast asia for Grab (prevent drivers sharing accounts)

Biometrics as one of the factors minimize the risk?

- Something you are is something that can be stolen from you

- Performance of the sensors isn't as good as other authentictors

Key scoping/beyondcorp/webauthn

- Protecting different things with different keys

- Separation of duties

- Not really recovery of keys

- Parallellized keys for every interaction?

- There should be no master key - you can regenerate from your other keys

Need to solve for the masses/for the cost

- Making bettter security posturing decisions to protect the 90% - "good enough"

- Student population - 10,000 people and up.

- Need a good/cheap/easy way to do this.

Managing a single private key doesn't fit into a normal consumer mindset

- Is having multiple keys really helpful?

- Technically yes, but people are lazy.

- Continously updated key material updated as you pair devices, all your devices have secure enclaves. Back to n of m.

Biometric

- Require pin and password

- Then need backup for pin and password

- Use email

- Lots of people, for example in SE asia, don't have email - use a fake email address

Writing a recovery secret on a piece of paper is airgapped, simple, pretty fool-proof

- Unfortunately it's not verifiable by the system that the person wrote it down, wrote it down correctly.

- Falls through to the helpdesk

Using a government or other authority as the guardian

- Could be used as part of the identity proofing process

- Assumes you could strongly proof everyone, which you can't/is a privacy problem

User-friendly scenarios?

- Gamification

- In Webauthn, experimenting with logging in with Android, have a platform authenticator, platform can offer to helpfully enroll another token (its enclave) for you. Be 'helpful' / offer to do nice things for the user.

Situational authentication/behavioral authentication

- Useful for adding extra facts to the session

- Great for triggering step-up, but not useful for recovery

In a multifactor situation, what happens when someone forgets their password?

- Can't have a backup password, they're more likely to have forgotten it

- Have to break the rule in that case

- You could require two physical authenticators and send a notice to the user, something like that

- Sometimes it boils down to a help-desk problem

No reason you couldn't design a recovery flow where you get a temporary password, use that, and have to use U2F as basically the primary factor and then you reset your password.

********************* **************** *********************** *****************

2. Notes From Session Board (Niels Van Dijk):