Generic MFA Token Recovery – The good the bad and the ugly
Generic MFA Token Recovery: The Good, The Bad & The Ugly
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
- 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.
- 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
- 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):