FIDO2: WebAuthn, CTAP2, Public Key Authentication, U2F
FIDO2 related technology links
FIDO2 @ FIDO Alliance, FIDO2 project @ Wikipedia authentication using W3C WebAuthn @ Wikipedia & Client to Authenticator Protocol (CTAP / CTAP2) @ Wikipedia. Without forgetting Universal 2nd Factor (U2F) @ Wikipedia providing two-factor authentication (2FA) / Multi-Factor authentication (MFA) @ Wikipedia. In technical terms this provides separate Hardware Security Module (HSM) @ Wikipedia storing the secret keys, when not using a soft implementation.
I really like the concept of FIDO2. It's nothing new, using the classic public key authentication method, which has been around for several decades.
Securing login alone doesn't solve the MITM issue. Session keys are still vulnerable and all the regular attack vectors after you've logged in do work. If the system you're using is compromised, situation is still very bad.
I tested WebAuthn authentication with Android, Windows and Linux platforms using Chrome & Firefox browsers, using USB and Bluetooth U2F devices (authenticators) for get generation & private key storage. It would be nice if the sign this data part would be shown to user, so the user would know what they're actually signing. This could be useful in some cases, yet compromised system would make this useless as long as the data is shown on computer and the authentication device doesn't got a screen.
I'm eager see, if this technology got any official adoption. I would love to be able to use it as official identity. But currently authorities do no accept such solution(s). This starts to sound especially interesting when considering all the PSD2 user identification / authentication requirements.
It's good to remember that the device(s) can store only limited number of resident keys. I personally wish that the services and browser would make it bit more clear, if the key specific generic U2F key is used. Or if new resident keys are being created. Some of the devices do not provide any way to evict stored resident keys.
It's possible to allow Soft Tokens with Firefox by enabling security.webauth.webauthn_enable_softtoken option in about:config. In that case actual separate HSM or USB token key isn't required. This allows you to easily test and play with WebAuthn autentication. But don't get yourself locked out. If anyone happens to know where the data is saved, I would love to know. Google didn't seem to find anything relevant and I really didn't bother digging the source code. I've confirmed that the tokens aren't visible in logins & passwords, which would have been a logical storage place for such information.
Another thing I'm really wishing, would be wide standardization on web-server level. What would be more awesome than having something like HTTP Basic Access Authentication to work with WebAuthn. It would be just a more secure alternative. If it would be built in standard feature, it would be used a lot more. This would make it very easy to restrict access to specific resources only to key holders, etc.
With Windows - Microsoft Account as example Outlook (Web) login asks for PIN with FIDO2 key. But on Linux the site says that your operating system or browser doesn't support required feature? Does this mean that the PIN + security key feature doesn't work with Linux / Firefox / Chromium? Maybe the PIN entry feature is missing from Linux, because that's something which seems to be prompted by Windows, not by Firefox. I guess Outlook is using Resident Keys feature with PIN. At least Outlook providers password & account recovery codes and SMS recovery in case of TOTP 2FA fail. It's still lot better than LinkedIn, which 2FA authentication is really bad, it only allows single method being used at time, and the options are SMS or TOTP, no support for FIDO2 or recovery codes (when using SMS) nor ability to use more than one option at a time.
I seriously dislike the model where every service got it's own authenticator mobile app. That sucks, is inefficient and annoying. There's no need to reinvent the wheel every time as well as I'm pretty sure that some of those authenticator applications are really insecure in the way those are storing the shared master authentication secret. Doing rest of the authentication is of course easy, you can always just HMAC challenge / time or whatever with the shared secret. It's still probably much better than passwords.
It would be so wonderful to have a few kilobytes native binary to do this solo key rng feedkernel instead of having loads of bloat from the current solo tool. Also it could be interesting to see that to be mapped as hwrng. Yet modern CPUs already provide hwrng, I wonder why that's isn't available? - But I'd guess that's a completely different story.
Final comment, FIDO2 & WebAuthn are absolute joy to use. TOTP is nice, but it's so painful. First finding your phone, then disabling screen lock which is complex password and then opening the TOTP vault another long password. Finally finding service from long list and then entering the code. Sigh! I do understand why many people want to opt-out from all this tedious login work.
More reading and comments about related articles I've read
Excellent article about using WebAuthn with Linux including tasty technical details. I really liked the aspect of mentioning possibility of tracking certificates, which is of course obvious, unless service specific keys are being created. Yet, why I would anyone use a single authenticator for identities which I want to keep strongly separated. Sounds like a bad plan to begin with.
If you want to maintain separate identities, sure way is to use separate authenticator with it's own keys. Even better, have all identity related data strongly encrypted. This prevents them proving the fact that the identity is you, by you having a HSM with the private key. Which is probably about worse than DNA match. This is aspect is very closely related to the posts I've made about what "strong identification" even means. It can mean very different thing in different situations. Cryptographic strong identity, can be linked to real identity, or left pseudonymous on purpose. I've noticed that some service providers don't make clear separation.
Don't forget to check out the awesome WebAuthn guide site. Well said "While Web Authentication is an important tool, it is always important to remember that security is not a single technology; it is a way of thinking that should be incorporated into every step of how software is designed and developed." - I really wish this kind of technology would be more widely used.
I really don't know if that's better or worse. Because it's obvious where all this leads. It has always worked, now it's broken. And let's just create new account. Well that happens with passwords all the time, but with this approach it's even more likely to happen. Sign up, sure. Login, ok. And when the credentials are lost, user is totally baffled, it always works. Well, until now. Reminds me from people who have their Facebook login only on their computer, and they have no idea about account or password. It just works. After letting it sink for a while, this is really bad. Nobody got any clue where the keys are stored and well, waited disaster arrives sooner or later. Technologies like this make it totally norm that users want to reset login method for their accounts, and it becomes routine . Because it happens all the time, process needs to be easy, simple and without friction, which totally ruins security. Oh, token lost, yeah, that happens countless times every day. Answer is: "We've just removed token requirement for the account. Have a nice day." Nobody bothers for any extra questions or scrutiny. It's much better to make it clear that there's no way to recover the account. Then users store it safely. And if the credentials are lost, then you're out of luck, end of discussion. Because if there is, then it doesn't matter how secure the authentication is, because hacking it takes just one call or email.
Another very nice post about Webauthn API.
Passwordless authentication, challenge & response / shared secret is also passworless, in sense that no password is sent over internet when authenticating. Of course the real question is, how the shared secret is agreed / shared / stored securely, to allow this secure exchange to take on later. In this sense passwordless authentication is achievable, without using public keys.
kw: ECDAA, Electronic authentication (e-authentication), Using U2F for passwordless sudo, Fast Identity Online, Universal Second Factor, Replaying party, Client, Authenticator, Attestation, TUP, Resident Credentials, eIDAS, EU ID, RSA SecurID