WebAuthn is now a W3C recommendation, bringing us one step closer to not having to use passwords anymore. If you’re not familiar with WebAuthn, here’s a little demo (if you don’t own a security key, it’ll probably work best on an Android phone with a fingerprint reader).
That I needed to add a disclaimer for the demo indicates the state of WebAuthn authenticator support. It’s nice when it works, but it’s clearly still in progress, and that progress varies. WebAuthn also doesn’t cover how the authenticator device works, that falls under the proposed CTAP standard. They work together to form the FIDO2 Project. Currently, the most reliable option is to purchase a security key, but quality varies wildly, and needing to carry around an extra dongle just for logging in to sites is no fun.
What WordPress Needs
Anything that replaces passwords needs to provide some extra benefit, without losing the strengths of the password model:
- Passwords are universally understood as an authentication model.
- They’re portable: you don’t need a special app or token to use them anywhere.
- They’re extendable: strong passwords can be enforced as needed. Additional authentication (2FA codes, for example) can be added, too.
Magic login links are an interesting step in this direction. The WordPress mobile apps added magic login support for WordPress.com accounts a while ago, I’d love to see this working on all WordPress sites.
A WebAuthn-based model would be a wonderful future step, once the entire user experience is more polished.
The password-less future hasn’t quite arrived yet, but we’re getting closer.
How does this new model affect 2 factor?
2FA can be any two of:
In this model, the authenticator is the something you have, whether it be a security key, or your phone. The second factor is added by requiring a fingerprint scan, or by entering a PIN, before the authenticator will respond.
This will potentially make 2FA far more accessible for the average end user.
I’ve also been following WebAuthn, and it’s garnering more interest, but it still seems too complicated for widespread adoption, both for implementors and end-users.
It’s a classic monolith/modular problem. Either all of my passwords are unique to limit the attack vector, or all of my passwords are the same to increase my convenience.
Linking auth to a physical key introduces a single source of truth, that is also a single failure point. To combat that, we end up with multiple physical keys, and now we’ve reinvented the same problem on top of the old problem.
Magic links are pretty cool, but they’re just tokens, which are essentially a cryptographic nonce-word that self destructs after use. Is a “ponce” a thing – passwords only used once?
Probably unsurprisingly, I feel just fine with email & password pairs until a solution exists that allows all of us to completely own our identities everywhere.
I’ve always dreamt of a day where my WordPress site could act as my broker, and perform an auth-redirect back to any service. OpenID is as close as we’ve come, but just like RSS, it was almost too good too soon.
Folks with password managers are kind-of living in the passwordless future already, granted it’s a pretty duct-taped one full of clunky feeling dock services that pop-up like Clippy and try to intercept all password related work, but it’s still way better than almost every alternative right now.
All I want (and should probably just start building) is to be able to say that my website is me, prove it, and have it make whatever meta-data available to whatever service is requesting it; a version of Facebook where my site has everything instead.
I like the token idea to avoid the single key problem. Blizzard has been doing it for years now with their 2FA flow. Unfortunately, the average user is still going to complain about pulling out their phone or switching apps just to authenticate with a service (admittedly, I do it too after I’ve had to type in a bunch of 2FA codes throughout the day).
While typing this, I did have the idea of hashing the fingerprint key with another factor such as a device identifier. It’s still reliant on a single device, but recovery codes could handle that issue.
As more browsers improve their support for WebAuthn, it’ll become a no-brainer for developers to start building it in as an authentication method. Once it starts getting adopted by major sites, users will love it and it’ll all snowball from there.
I definitely feel like it’ll be coming soon.
I have a unique way of securing my website. I use a long life cookie (10 years) to prevent anyone else from accessing admin. The password login, for me, is entirely meaningless. Since I use HTTPS and a secure cookie, I can be reasonably sure that it won’t be intercepted and decrypted anytime soon.
Of course, I don’t use WordPress is the usual way either and I’m the only user/author.
This would ideally be aligned with the work around better authentication for the REST API.