[webauthn] Syncing Keys, Recoverability and Security levels (#1640)

akshayku has just created a new issue for https://github.com/w3c/webauthn:

== Syncing Keys, Recoverability and Security levels ==
There are various user combinations and RP security needs which makes it tricky to have a unified solution as well as solve recoverability. Sometimes, goals become contradictory. Like RP has a legitimate need for hardware bound keys but that conflicts with user's need to be able to login to the RP when that device is lost. It becomes easier when there is one other device that user has, but to support full device loss scenario, it becomes really difficult. 

- RP Scenarios which reflects their various levels of security needs:
  - Scenario 1: Enterprises, due to various regulatory, compliance needs, wants hardware bound keys for their users.
  - Scenario 2: Consumer RP, also wants hardware bound keys for their highly sensitive users. 
  - Scenario 3: Consumer RP is fed up with phishability and just want to get rid of passwords. They are OK with anything better than password.
- User Scenarios which reflects their usage patterns.
  - Scenario 1: User, who has multiple devices, lost one of the devices and wants to use a new device immediately after setting up that device. 
  - Scenario 2: User, who has one device only (let's say phone), lost the device and wants to get back the state immediately after setting up a new device.
  - Scenario 3: User has a backup security key along with platform devices and uses backup security keys whenever platform devices are lost. User keeps the security key in well kept place and only uses that occasionally to setup platform authenticators.
  - Scenario 4: User uses only security keys all the time. 

All the RP scenarios can be solved by hardware bound keys from both platform or security keys. 

User scenario 1 and 2, requires syncing which don't really match RP's needs for it's scenario 1 and 2. That is where the problem is. To address this conflict, a two key solution is proposed in #1546. Main idea behind that proposal is to have second key which is device bound and does not sync. So that when a user comes to a new device, a new device bound key is generated and RP will know that this assertion comes from a new device and then it can run it's risk analysis. This is a compromise and may not work for every RP. Especially for highly sensitive RPs like banks, governments etc. 

There are few important points to two key solution: 
- RP needs a guarantee that it needs a true new device signal.
  - Currently with hardware bound platform authenticators, like Windows Hello, RP's gets a true device signal. Which it uses to build up a trusted device list. For example, if an RP gets two different Windows Hello credentials (assuming that credentials are not overwritten and RP is passing the exclude list properly during registration), then RP can get a guarantee that user is using two devices. 
  - If that device bound key gets regenerated every time browser clears, then that second device bound key has no meaning. Then RP may incur hundreds of device public keys over time and such a data does not reflect the situation where user may only have 1 or 2 devices. Which may result in false fraud logic detections on RP's side. And RP will not adopt webauthn or use second key at all. It hurts webauthn adoption. 
  - If that device bound key is per-app instead of device wide, then above same logic applies where RP is again not sure of how many trusted devices user has. 

There is another problem with full device loss scenario. Platform specific recovery logic to recover an account in total device loss scenario scenario is mostly opaque for some good reasons. But in some cases it will fallback to the SMS which is against the unphishability goal of webauthn and RP's requirements. And RP has no say in this in current proposals. 

W.r.t security, I think there are various levels below in decreasing order. 
1. Hardware bound Security Keys/Platform authenticators
2. Syncable credential with true device bound keys with recovery only allowed if user has one of other devices with them. Full device lost scenario is not supported in this situation. 
3. Syncable credential with true device bound keys with full device lost scenario supported. 
4. Syncable credential without device bound keys
  - Syncable credential with per-app/per-context device bound key is same as syncable credential without device bound keys. As Rp cannot reliably infer anything from that per-context device bound key.

In this whole flow, one question arises. Why not give RP the choice to select what security they want at registration time. The problem with that proposal is that worry that every RP will think that they need highest security and user will suffer when they lost their own device in recovery scenario. Hence there is a current desire to pick up a reasonable middle ground without RP's choice. But things can change if enough people swing one way or another. 

For us(Microsoft) as an RP, we always wanted only hardware bound keys earlier. Now we are debating whether Option 2 and 3 can work or not. That alone with require a lot of explaining and persuation in enterprise use case and things are not settled yet. Option 4 will not probably work for us. 

I am interested in other RPs stance on this. Where do they stand and what are their **_real_** needs. 


Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1640 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 6 July 2021 13:50:40 UTC