OpenSSH's Support for U2F/Fido Security

Re:OpenSSH's Support for U2F/Fido Security by waste_monk on Wednesday November 06, 2019 @12:09AM (#21459885)

There was a good reason for creating key material external to the token though, even though it's objectively more secure to let the token generate it. In the past(and possibly this is still the case) most sites had flawed U2F implementations, in the sense that you could only register one U2F key to an account (or rather, you could normally only pick one instance of any supported 2FA method e.g. SMS).

If your U2F token was lost or damaged it would thus permenantly render your accounts inaccessible (depending on whether or not account recovery bypasses U2F), and the best practice to avoid that was to have two tokens initialised with the same key material and to keep one in a safe place at home / bank safe-deposit box / other secure location. Then, if you needed to regain control you still had a valid U2F token.

As U2F gains traction more sites are implementing it properly with multi token support, which renders this method obsolete, but that's the historical reasoning.

[ Parent | on HN ]

Re:OpenSSH's Support for U2F/Fido Security by akerl_ on Wednesday November 06, 2019 @07:42AM (#21461894)

I’m not sure I understand the case you’re making. The fact that many sites have horrible implementations of MFA, where you can only enroll a single U2F device, couldn’t possibly have been the “good reason for creating key material external to the token”, because creating key material external to the token isn’t a feature of mainstream U2F tokens, it’s something that has been historically supported by GPG hardware devices.

Yes, those sites should implement U2F support better, but the question was about why U2F is more secure than GPG, and ~“because it’s harder to mishandle the private key during setup” is pretty solidly an accurate answer.

[ Parent | on HN ]