Implemented Password-less Login Using Web Authentication API (WebAuthn)

This suggestion has been implemented. Votes are no longer accepted.
To me this sounds a bit like reinventing the wheel ...

Secure, public key cryptography based client authentication exists since ages - TLS Client Certificates.

This is supported in almost every browser and webserver, the only problem is that apparently nobody uses them (for this usecase, they are being used in machine-machine communication though).
 
To me this sounds a bit like reinventing the wheel ...

Secure, public key cryptography based client authentication exists since ages - TLS Client Certificates.

This is supported in almost every browser and webserver, the only problem is that apparently nobody uses them (for this usecase, they are being used in machine-machine communication though).
No, I don't think there are any wheels reinvented here. Asymmetric key cryptography is an old technique which is being utilized with extra components to associate the identity of a user. Yes, TLS is being used in web communication all the time, but as you noted it is generally utilized in machine-to-machine communication context. Two important points to note here: 1) while clients (such as web browsers) verify the identity of the server to ensure they are being served from the intended place, the reverse is not the case (apart from usual password authentication-based sessions) and 2) clients generally do not associate themselves to users and often are not aware of who is using them. WebAuthn is aimed to solve these issues.
 
That's exactly what TLS client certificates are for, securely authenticating a user - it' just not being used widely.
I missed the point that you were specifically talking about the Client Certificate, and not the TLS framework in general. Yes, indeed it is possible, but there are some practical challenges in its adoption as summarized here.
 
Reinventing the wheel or not, you pretty well summed it up yourself...

the only problem is that apparently nobody uses them (for this usecase, they are being used in machine-machine communication though).

Regardless if TLS can or cannot be used for user authentication isn't so much a concern, as WebAuthn IS a new standard for doing just that, user authentication.

WebAuthn is now a web standard. It's now supported in a major browser (Firefox), with both Chrome and Edge support just around the corner VERY soon.

More info about WebAuthn here - https://developers.google.com/web/updates/2018/05/webauthn

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
"Google has not had any of its 85,000+ employees successfully phished on their work-related accounts since early 2017, when it began requiring all employees to use physical Security Keys in place of passwords and one-time codes, the company told KrebsOnSecurity...

With any luck, more sites soon will begin incorporating the Web Authentication API — also known as “WebAuthn” — a standard put forth by the World Wide Web Consortium in collaboration with the FIDO Alliance. The beauty of WebAuthn is that it eliminates the need for users to constantly type in their passwords, which negates the threat from common password-stealing methods like phishing and man-in-the-middle attacks."
https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/


It would be great to see Xenforo add support for this so , we forum owners can also help protect our users and our sites.
 
Giving this a bump now that WebAuthn is fairly ubiquitous. Apple announced support for Face ID and Touch ID with WebAuthn at WWDC2020, and it's been receiving a lot of attention.
To me this sounds a bit like reinventing the wheel ...

Secure, public key cryptography based client authentication exists since ages - TLS Client Certificates.

This is supported in almost every browser and webserver, the only problem is that apparently nobody uses them (for this usecase, they are being used in machine-machine communication though).
As someone who uses both extensively, I can assure you that they aren't similar at all. WebAuthn is meant to be easy for an average consumer to use--easier than a password. Client certificates can be easy in some circumstances, by they lack the flexibility of WebAuthn. It's better to think of WebAuthn as a generic API rather than a mandate for a specific security protocol. It doesn't really solve the same problems as client certificates.
 
Ran across how Cloudflare uses WebAuthn... rather than a password-less login, it's used as a two-factor authentication option as "Security Key Authentication".

1649617039902.png

...which allows you to use an Android phone, a hardware key (such as YubiKey) or simply the device you are on as your "Security Key".

1649616951437.png

This would be so nice to be used in XenForo... would allow you to not require two-factor auth app if you are physically on the same device/computer you set it up on. It's also really nice on Cloudflare because they require two-factor auth way more often than XenForo's 30 day window.

As a bonus, it also enables two-factor authentication via things that are common these days (Face ID, Touch ID, Apple Watch approval).

Can muck around with the underlying API here if anyone is bored: https://webauthn.io/
 
I went ahead and built a XF2 add-on the allows security keys to be used for two-step verification. My thought was to build that first (since that was more useful to me than the straight password-less login system) and then see about doing the password-less login system after the fact.

In building the two-step portion, I learned a whole lot about WebAuthn, and to be honest, I don't think it's a really good fit for password-less logins, and here's why...

Both the registration and authentication functions require that the end user pick a username before doing the trickery with the security key. For example, in order for an existing user to use it to log in, it's not as simple as just using the security key... you also need to manually enter your username (at minimum). The technical reason for this is because when you request a user to authenticate with the key, you have to tell the API which credentials you already have that you will accept. The allowCredentials option in the spec is technically optional, but for practical purposes with XenForo, it's not without major schema changes. I'm doing it by loading multiple security key credentials into a single xf_user_tfa.provider_data column. For two-step verification, I simply pull the record for that user, then look in the json array to see if the given credential matches. It's a lot more difficult going the other direction (where you might have a credentialId, and need to find which user it belongs to). Unless you created a whole new table to store security key credentials, it's not (realistically) a query you can do.

Registration would be a little kludgey, because you still need the user to pick a username (and probably an email address) when they register (but before they use their security key). You can't have a XF user without a username, so there's that (no way around them needing to pick a username). And at that point, you aren't saving a whole lot of time/energy for the registering user (they are needing to more or less do all the normal stuff at registration except pick a password, and instead of doing that, you are giving them something new to do [use the security key]).

You can kind of see what I mean with the demo here: https://webauthn.io/ ...you can't Register or Login without giving it your username first. It's not like you just come to the site and use your security key and are good to go. There's more to it.

Note about non-hardware security keys... you can use them, but it's really not that great for portability reasons because the security key is the physical device itself... like I can setup a security key based on Face ID of my phone, but that doesn't carry over to an iPad or macOS with the same Apple ID. This also means if my phone is replaced or lost, that security key is also lost. You can have multiple security keys, so if one wanted to go through the hassle of registering every possible device as a security key, I guess you could do that and unregister/reregister a new one if it's replaced. But that seems like a hassle to me... the YubiKey 5 NFC is the way to go for me... if I have a USB port or an NFC-enabled phone, it works with it all as a single security key that you can use with future devices.
1649905116798.png

1649905092946.png
 
Last edited:
Back
Top Bottom