Option to remove PIN - Githubissues

solokeys / solo1

Solo 1 firmware in C

https://solokeys.com/

Other

2.29k stars 273 forks source link

Option to remove PIN #383

Open riedel opened 4 years ago

riedel commented 4 years ago

It seems that one may only change but never remove a PIN. As some utils don't support PINs it would be quite useful (otherwise one would have to reset the whole key I guess)

Or did I miss something?

riedel commented 4 years ago

see also #349

jolo1581 commented 4 years ago

I think you can only clear pin by using solo key reset command. And this will remove also all stored keys.

nickray commented 4 years ago

I think the reasoning why such an operation is not part of FIDO2 here is that for a resident key (not used as 2FA) you'd always want a PIN, otherwise the RK would just be a single factor (something you have, the key). So implementing something like this would be a weakening of the security model.

riedel commented 4 years ago

Even with the PIN enabled I can actually generate assertions on a RK that do not need the PIN.

Removing the PIN would need a PIN. There seems no more risk than changing the PIN to eg. 0000.

Tumeez commented 4 years ago

In my opinion would be great if you can remove your PIN, but it needs to know old PIN then.

Example.

solo key removepin your pin Are you sure that you want remove PIN? (Y/N) Y PIN removed successful!

nickray commented 4 years ago

We have to be standards-compliant here I'm afraid. I'll double check this.

nickray commented 4 years ago

OK :) I think we can do this!

MC says: If pinAuth parameter is not present and clientPin been set on the authenticator, return CTAP2_ERR_PIN_REQUIRED error.
GA says: If pinAuth parameter is not present and clientPin has been set on the authenticator, set the "uv" bit to 0 in the response.
moreover, in the upcoming / non-public CTAP2.1 spec, there is the credProtect extension which allows the RP to demand UV to even generate the assertion

The only possible downside is that clients (OS/browser) don't expect removed PIN, which may lead to some confusion when you use a key where the RP expects user verification. But given remove PIN would only be possible via CLI, I think it's a better choice to enable "user freedom" here.

Thoughts?

aseigler commented 4 years ago

I am OK with it as long as:

The same anti-hammering technique is used in the remove pin operation as the pin challenge operation (cannot have bad actor physically acquiring token and easily clearing PIN and setting new instead of entering it correctly for UV). Someone might be have a better reasoning for this angle?
User is warned that this might cause weird "unknown errors" in the case of visiting a previously registered UV requiring relying party. AFAIK nobody else supports this kind of operation, adding PIN is expected to be one way path. Obviously, this could result in bad UX.