WebAuthn Is Great and It Sucks (2020)
sec.okta.com
sec.okta.com
Having the keys in your PW manager of choice is worthless if your browser/OS won't play ball. Keeping all those logins locked inside Apple/Google/MS's garden is just too juicy of a 'sticky' platform lock-in to ignore. Besides, only nerds care about integration of other key storage platforms; 98% of users will just keep them in iCloud/Hello/Google, so maintaining the APIs to enable that integration will be on the chopping block of every Product Manager.
e.g. look at Google's Authenticator app. Once you add a TOTP secret, you can't get it back out. Only recently did they add the ability to sync, but only to other Android devices you own. Those keys are hidden forever, for your protection.
I always did & do save a copy of the QR code or, if provided, the BASE64ed key in my PW manager. I know I'm never locked in with TOTP: I can use anything (I've written the 10 lines of code, even) to generate the code, and it can be entered manually on any device that can display the site's login page by hitting 6 digit-keys. WebAuthn needs, at minimum, the browser to remain open to integration.
I've very hastily made sure that all my backup keys are up to date afterwards...
Login with Facebook has existed for years now, but not everybody with a Facebook account uses it, even if they can. Why? Because that vendor lock in means that people are discouraged from using it in all cases. Banks don’t want to use it. Other large websites don’t want to use it. Businesses don’t want to use it internally.
I think that there will be significant enough demand for 3rd party, open solutions that passkeys will succeed. If there isn’t that demand, then it will fail overall.
The major browsers and OSes already support WebAuthn, so it may be compelling for all 'Website Xs' to implement it, though the linked article presents a (dated) concern that they won't.
That's not the part I'm worried about: WebAuthn as a standard may work almost everywhere, but as a user, your ability to bounce around between browsers/OSes with your secrets coming with you may be restricted.
webauthn, as designed, can't be used to lock anybody into any authentication method, because the apps that use it should support adding as many different webauthn methods as you want. it only has the possibility to be a lock-in if you are restricted in the number of authentication methods you can add for a third-party service you want to authenticate to. and FWIW, apple and google both recommend supporting infinite passkeys, and have implemented that in their own webapps. any fearmongering about webauthn/fido/passkeys being a vendor lock-in is not backed up by current facts.
Maybe they'll always support cross-platform USB/NFC keys (they probably will), but I don't want an external device(s), especially if I have to remember to set up multiple devices for every site to have redundancy.
Yes. Good thing there's an open standard called webauthn, supported by all the major vendors, that defines an interoperable way to get the result of those crypto functions back to the websites that need them.
Be better.
It only supports HTTP as I understand it, and won't work for other protocols like SMTP or IMAP.
What does work, regardless of application level protocol is using TLS certifications on both the client and server side in combination with a username and password for authentication.
If you want to see an outside of the box use of the attestation feature, take a look at Cloudflare’s “Cryptographic Attestation of Personhood” [1]. Basically they use the attestation key to tie the WebAuthn challenge to a real vendor, so if spammers make their own fake WebAuthn keys they can block them wholesale. I’m sure some Cloudflare skeptics will jump in and point out all the ways that could be abused.
[1]: https://developers.cloudflare.com/support/about-cloudflare/b....
Plus the idea is predicated on the idea you can't just register another device. Passkeys, as a user auth model, pretty much require the ability for multiple devices to be tied to one account. Google has your passkey for site X? Log in, register a new passkey with 1Password, delete your old passkey. Done.
Multiple devices/key stores that don't sync are dead before they even get started. Almost no users are going to be willing to do that, and thus most websites won't bother to support it. How many websites today offer the ability to have multiple OTP options concurrently and/or allow you to only enable TOTP and disable email/SMS?
This will start out open and flexible to gain adoption, and then either through malice, laziness, or low adoption, the options that avoid lock in will be phased out.
Pass managers have totp authenticators as well. I mean really, you can just sit back and have Apple do everything for you (built in totp) or the same with Google or you get 10+ pass managers to choose from, some are open source... This whole thing is rather paranoia as of now.
We must be crictical and watch out but the law is on our side:
https://www.whitehouse.gov/briefing-room/presidential-action...
c-gpt free version:
It is theoretically possible for a dominant company to support a third-party technology or standard initially and then abandon it, which could potentially harm competition. This practice is known as "embrace, extend, extinguish" or "embrace, extend, and extinguish" (EEE). The term was coined during the Microsoft antitrust case in the late 1990s, where Microsoft was accused of using its market power to undermine competing technologies.
In the case of passkey technology or any other standard, if a dominant company were to initially support it, attract third-party developers and users, and then suddenly abandon or change the technology in a way that hampers compatibility or competition, it could potentially limit the options available to users and stifle innovation from other companies.
However, it's important to note that such practices can be subject to scrutiny and legal action under competition laws. Antitrust authorities, such as the DOJ and FTC, are responsible for investigating and addressing anti-competitive behavior. If there are indications that a company's actions are harming competition or violating antitrust laws, regulatory authorities may step in to assess the situation and take appropriate measures.
Free pass management is really a basic human right (or democracies can make them to be). I personally do not hate Apple, Google, Microsoft but they own 99% of OS I guess so if passkeys take off, they have to remain open.
I mean at least Europe and California (and the rest of the World that is not US) and even US citizens would back competition in pass management sector. What we really needed is a good Linux phone. Now I use Google stuff but I would change to full Linux+Proton I guess. They just announced their open source pass manager!
I am not saaying we should not be vigilant but I guess we are stronger than you might think (I mean we vs. a heterogenous not-really-oligopoly-us-os-providers).
Since then, both Apple and Google have implemented WebAuthn for passwordless account signin. Best Buy does too.
edit: eBay does too, I remembered right according to the list posted below. Some notable ones are DocuSign, PayPal, Shopify, Adobe, and CVS.
https://old.reddit.com/r/apple/comments/xk6hiq/bestbuycom_am...
Tracking: https://passkeys.directory/
They don't support non-biometric authenticators, so one can't use e.g. Yubikey.
Edit: oops, sibling comment mentioned this too.
IMO, folks who write standards need to write them with the best interests of the developers who will be integrating it, not the service providers.
> Passkeys can only be created on locked mobile devices from Chrome (Android or Apple devices) and Safari (Apple devices only) browsers.
to be a proper implementation.
https://www.paypal.com/us/cshelp/article/what-are-paypal-pas...
Oh right, the benevolent overlords, in their wisdom, discerned that mere mortals can't be trusted with private key material.
Nevermind, move along.
The server has to have some way of verifying your certificate. The workflow I would like to see is that the server runs its own CA that it uses to sign client certificate signing requests and then uses that CA to verify any client side certificate presented. If combined with a username and password, it would effectively be 2FA without a shared secret (outside of TLS connection negotiation).
To put it another way, the benefit I get by having my computer verify that I'm connecting to news.ycombinator.com and not some fraudulent website is so that I don't inadvertently transmit my account credentials to a scammer.
The benefit news.ycombinator.com gets by verifying a client certificate I send them is that they can verify that the user u801e is establishing a connection to them and not some scammer who happens to have my account credentials.
Those benefits are lost if either the server or client sends a self signed certificate, because there's no one who we can use to verify the authenticity of the certificate. The reason using an external CA is not needed on the server side is, in my opinion, because the server is the one who's handling the account creation, so it doesn't need an external authority other than itself to verify whether the certificate is valid. If the server just accepted a self-signed certificate, then how does it verify that the certificate is valid?
My mental model is basically like SSH-ing into a box. All the client does is pin the server's public key fingerprint and moan if it changes. The only additional element is an affordance where the box would essentially allow all comers to create a user account and a corresponding `~/ssh/authorized_keys` with their pubkey in it.
In the web-app, of course it's not making unix user accounts, but it's associating the self-signed cert with a user account (how ever that might be implemented) the first time it sees a new cert. Whoever shows up with that cert in the future is automatically 'logged in' as the corresponding user account.
So, genuine question, what does it mean for the client cert to be potentially invalid? What could lead to that case in the system you're imagining? Under what cases would you either a) not grant a CSR in the first place or b) revoke a cert your CA signed?
How can the server verify it's the same client signing the crypto challenge with the same private key?
> what does it mean for the client cert to be potentially invalid?
The certificate's signature cannot be verified. Assume a client decides to create a certificate and send it as part of the TLS connection negotiation. The server would reject it because the signature on that certificate isn't valid since the server CA did not sign it.
> What could lead to that case in the system you're imagining?
Someone who's trying to access my account (assuming news.ycombinator.com requires a client side TLS certificate as part of the authentication process) tries to forge the client side certificate. If the certificate is self signed, how will the server know it's from me versus someone else? How do we maintain the association between a particular client and a key pair?
> Under what cases would you either a) not grant a CSR in the first place
For someone creating an account, there would be no reason to reject the CSR. For someone trying to add another device with a different key pair under the same account, not being able to show they have access to the first device would be a reason to reject it.
If we're talking about an account at a bank, a CSR could be rejected if the person is unable to establish that they're the actual account holder (through some form of out of band authentication like a bank official checking my drivers license and passport).
> or revoke a cert your CA signed?
If someone decides to delete their account, then revoking the certificate used as part of the authentication process would be the appropriate course of action.
I could be deeply erroneous in my understanding of X.509 but I am pretty dang sure that a self-signed cert would in fact provide that guarantee.
All certificates (self-signed or otherwise) have an associated private key. In the case of a CA-signed cert, the CA never sees the private key of the cert it's signing. So in your scenario, the server can know it's you and not someone else (assuming you kept your private key secret…) because in establishing the connection, the client signed a challenge that only the holder of the certificate's private key could correctly sign. Whether the cert is signed by a CA or self-signed doesn't change this property.
The CA-signing doesn't provide the property of unique identity—public key crypto does that already. CA-signing just provides a "chain of blessings" that gives the peers on the connection a heuristic for determining how much they should trust the identity on the other end of the line.
Unless I'm wildly mistaken!
mTLS for most cases is not a good idea. For the masses, it's certainly not a good idea.
Maybe it’s that all this stuff is still new but whenever something offers PassKey support I now add 3:
- one on android
- one on iOS
- one in 1Password
Even more fun when it’s mixed with yubikeys, add primary key and secondary key to that list
I now have a spreadsheet to write down which website has which keys added to keep track. Hopefully something like 1Password will handle that soon, but I don’t want to risk losing access to my iCloud or Google and getting locked out. Even more confusing when browsers like chrome offer to save a passkey into the browser which is synced only within that browser (I think, exception being Safari)
How are you all handling that?
We’ll soon be able to sync these across platforms using password managers, though. Android already has an API available for them to integrate, I believe; iOS will follow in autumn.
Also, I think the browser thing with Chrome is a matter of extension support; in Edge with 1Password Beta Extension, 1Password definitely takes over Passkey flows instead of using the (absolutely insanely confusing) Windows Hello UX. Just like it takes over password saving (there's an option in settings that shows password sync settings are controlled by the 1Pass extension.) So you may just need to use the Beta extension in your Chrome for now, and I think 1Password will take over from there.
Basically we're moving towards a setup where you trust your password manager to hold onto your passkeys and then the OS will allow that integration. I don't know what the status of these features are on Android.
It’s a bit of a mess right now and even me as an IT person, I sometimes think I have a PassKey saved for something just for it to not work, either because I used the wrong device or because I didn’t actually save one and forgot.
Or once I had accepted the prompt to store the PassKey in Arc (or some other Chromium browser) which then didn’t work in another browser when I tried to login
The Home Depot mobile app does something similar already. Passkeys/biometrics for a persisting an iOS session, and to re-up a session, you get emailed a six digit code to your email. Why have the password?
If email as identity as insufficient for your use case, ask the user for a government credential using Stripe Identity or ID.me, or doing a token amount charge on a financial account the user has access to (offloading the identity proofing to their bank) to bring their account back up to a higher assurance level (“IAL”) during an access reset.
I recommend recovery contacts if you’re in the Apple ecosystem. Tangentially, setup legacy contacts as well.
https://support.apple.com/en-us/HT212513
https://support.apple.com/en-us/HT212515
https://support.apple.com/en-us/HT212360
(customer and corp IAM is a component of my work at a FinTech)
I can tell you to sort your redundancy now, it’s much easier than later.
I can also tell you to avoid google tooling, they seem completely disinterested in support and more interested in market share.
Google can go to hell for the time / account access I lost, fuck them.
It's been the case for ages. They show absolute disregard for the unique users. All they care about is their pseudo monopolized aggregates.
You may need to pay more attention to what you read, the context and the users before writing.
For passkeys I haven't seen a full open source implementation that actually works. Some parties like bitwarden promise it but aren't finished afaik.
However it lacks the ability to GPG export using OpenKeyChain which is why I went back to AndOTP.
KeePassDX (also on F-Droid) also supports TOTP, as does KeePass 2.0 on desktop, if you're comfortable keeping it with your password manager.
PyOTP contains plenty of information about how to implement an authenticator app.
I used KeePassXC but it didn't sync like I wanted using syncthing. Other synch stories probably work better, like Dropbox.
Kee is the browser extension I use and it's pretty good. They also have a sync service you can buy, but it's free to use with KeePass 2. I liked it better than the extension that's compatible with KeePassXC.
KeePassDX is pretty great. It's working well with my setup, especially using Brave as I avoid Chrome. Incidentally, I think recent Chrome updates have complicated things for password managers on Android but alternative browsers work great. I use it with a longer timeout to lock the database than the default.
I think KeePassX is superceded by KeePassXC.
So, if you ignore most of the other forks, you don't need much analysis paralysis, and everything works well.
For iOS, it's hard to find FLOS solutions but there are paid apps that are supposed to work well to integrate with KeePass 2 databases.
Communication was poor, mobile OS’s should probably account for this (if for nothing else to prevent major functionality pivots / spam ware) etc. parents displeasure and me losing all my mfa tokes feels like a total rug pull by google, a pattern they are known for (sure, fool me twice, shame on me - but I never expected their mfa Token app to delete all my tokens).
i can really not imagine those fuckups you always write about with google
somewhat irritating... is it true, is it not, are you google hater bot, are you not? :D
the 2fa codes are backed up in google account now, no way you lose them
before, it is basic to have them on 2 different devices at least...
i dont understand how it is possible to lose them
I migrated to Authy because it at least has syncing and backup functionality. Sure, it’s less secure, and I should probably self-host somehow for the best security/stability assurances, but Authy seems to work pretty well for what I need it for.
I have a printed sheet with all those strings and their account names in my own memorized encoded form (like rot13). Plus my main phone, my backup phone, my tablet, all of them have same app & codes (all devices have fingerprint & pattern locks).
You can decode these application-specific QR codes for backup or transfer purposes using a third-party tool: https://github.com/scito/extract_otp_secrets
Users understand passwords. They even understand entering a 6-digit number that was texted to their phone. That's about it. It has to be that easy, or it will fail. If you have to start talking about public key cryptography, you're doomed.
What is a passkey? Most material I've read just defines them as a "credential" that is "used as an authentication method." That's it. It's a credential. What kind? Who knows. Only when you arrive at the Apple developer page you finally learn that they are "cryptographic key pairs". And then you start digging into WebAuthn, get a throbbing headache, close your laptop, and do something else productive instead.
I worry much more about the account recovery UX and issues. If you lose your phone, how to replace it? Is that replacement path a prime target for attackers? I’d argue key distribution (issuing, rotating, revoking, multi-device) is where almost all the subtle pitfalls are.
Passkeys have a lot of questions in that regard. A password is simple: "keep this secret and only give it to the person it's for". You can read it, you can write it down, the rules of how it is distributed are obvious if not secure.
Passkeys on the other hand are already not being explained: "keep this secret. Then, your device will magically use it somewhere else. But actually we keep it in the secure element, Also sometimes you can't move it to other devices. Also sometimes the part we send won't work if we send it to the wrong person, or if it's intercepted..."
Of these, the part I really worry about is the synchronization one: everything about passkeys is being structured for corporate lock in. Because the ability to manage them like passwords is not front and center, it's being treated as an after thought. "We'll handle synchronization eventually or "oh, well it'll be on your other iCloud-connected devices..."
If I want to take an offline backup? If I want to write something down or print something out to cram that passkey onto another device, can I? Or is there an additional factor there which is empowering the service to decide if I'm allowed to do that?
Too strong of a statement imo. The password happy path is still a lot of friction every time you sign in, which is why everyone except banks sets their refresh cookie expiry to months or years. Not great, cookies don’t even live in the secure element. But if you torture people with typing passwords every day they won’t come back unless they have to.
> A password is simple: "keep this secret and only give it to the person it's for".
You’re missing the recovery path. That’s not obvious at all - usually a password reset through a side channel like email. In those cases, the email is your de-facto identity, and the password is like a refresh token that is stored in your brain.
Now, I’m not saying this is better with passkeys, just that there is more to password auth than meets the eye.
> Of these, the part I really worry about is the synchronization one: everything about passkeys is being structured for corporate lock in.
Me too. I think it depends a lot on the interop story. In the best future, we get something like a password manager standard, which interops with browsers and apps. Current password managers are well positioned to use passwordless auth. As a user, I could then use say Bitwarden on all my devices, and use passwordless as it comes available to more services.
But a lot of questions are still unresolved: what if I need to sign in from a public computer? Will account recovery still use email as last resort?
An "Insert the dongle" popup is instantly understandable, and we never had any problem with employees learning how to use them. Windows, Linux, Macs all eat GIDS smartcards without an issue, no extra drivers needed. Works across well web access, ssh, SASL, kerberos.
And now those people want us to move to FIDO keys, which come with each new version, one more problem, and don't work with anything, but Google stack.
You can even setup your office access control on the same smartcards.
Do they though? Sure they can use them, but that's a far cry from understanding.
We can keep telling people to use long passwords, to use different passwords for different webpages, to stop storing them in unencrypted on their phone or desktop.
So far this has had limited success and even with a better than average understanding users usually just end complain they can't remember all that.
At which point you try to teach them how to use password vaults. Which increases the layers of indirection by 1. Which is never a good thing when you need to explain stuff.
And then you've got webauthn, which in theory solves quite a few of these problems by simply giving people two buttons 'Give me an account' and 'Log in using my account'. Unfortunately it does this by increasing the levels of indirection another time by effectively being built on top of a password vault (but not the normal kind of password vaults because that would be too easy).
If users understood passwords they would know how and why to use a password vault. If they understood password vaults they'd understand how webauthn could help eliminate passwords.
Previous attempts at replacing passwords were all nonsense. They were all about replacing symmetric keys with asymmetric keys, which to anyone who doesn’t understand the difference, it makes no sense. I mean even if you understand the difference it hardly makes any difference in usability. I still have to manage my private key and secure it myself. the only usability difference is that I don’t have to transmit it, which is not even something that I do, it’s something that whatever software I’m using does.
With a hardware key, it makes intuitive sense. Sure, maybe the distinction between a TPM, Secure Enclave, Knox, Titan or a YubiKey is hard for non-technical people to understand or reason about, but luckily for WebAuthn simple external hardware keys are becoming a norm. I have seen many completely non-tech companies adopt YubiKeys which I was delighted to see .
Hardware keys are all about asymmetric cryptography, and are just basically another way to store keys. You still have to manage those keys. It's just way harder, because now it's a physical thing that's much harder to backup/copy by design.
Do we? My password manager has 1031 entries. I know maybe 3 of my passwords. For the rest, the fact that it's technically a password is mostly irrelevant to me. And there are a number of things I use that are magic link logins, where the "password" is a one-time key that gets emailed to me and used immediately.
So from my perspective, the notion of "password" is wildly obsolete; most of what passes for that these days is machine-generated strings that don't know and almost never see. I'd be perfectly happy to go one step further and have a proper protocol such that BitWarden and the site talk directly, leaving me out of things.
Another way things like linking a TV to an account happens is not with a fixed string that we in theory invent and memorize, but with a dynamically generated one-time code. For me that's obviously better than a password, in that the code will be shorter and time-limited, while the time window to misuse a password is infinite.
I want to share passwords of some sites and not share for all sites. If I share a password, I don't want to bugged whenever they try to log in.
Most sites also support some kind of fallback method, like magic link or a password.
some of them do, but a large portion of users do not understand why they need a password, do not understand how it keeps their account secure, or do not remember any password beyond a single use. there's a high proportion of people who do a "reset my password" every single time they log in to a service, and a smaller but still significant portion who are simply unable to sign in to any service that requires a password. they need a "computer-savvy" tech person to help them, or they just don't use it. the password is not some paragon of excellent UX that we're struggling to replicate.
Users see passwords as a barrier they need to defeat to access the thing they want, and will use any means available to them to defeat that barrier, security be damned. passwords are terrible.
Exactly right. My mum has an iPad, secured by a PIN. This in itself is already an annoyance, but fine. Next, several services on the device have their own authentication. Say, the Apple ID. Email. Spotify.
The thing tech people fail to understand is that many people, including my mum, are not able to conceptualize these services, they lack in tech skills but also in abstract thinking in general.
She sees the device as a single physical device. She owns it and it should stop bothering her about access. She has it in her hands, what access?
The bigger issue is that you are currently locked to a device (or, in some cases to a set of devices). This makes it tedious, because:
* you have to have an account recovery mechanism beyond the scope of WebAuthn
* you have to add each device you want to login with
We'll see if these issues get resolved, but I think that the working group is, well, working on it.
What if my phone dies with all my keys?
Do I need to maintain backups on 3 devices? I assume manually to be secure. This is so much time, esp for throwaway nonsense accounts I use yearly.
What if my phone died during a trip and backups are at home in another country. How do I email someone now?
My mom forgets a password each time she has to retype it. What if she breaks her phone with all the keys and no backups.
How do I log in on a computer without usb access that is not connected to the same network as my phone with the keys? - this workflow is already broken with gmail 2FA process with approving in gmail/youtube app.
If I even reset a passkey, how to use a friends device if mine is broken currently?
This is all solved with a password reset email.
Platform authenticators are built around the synchronization concept so it’s easy to keep multiple devices active. Unfortunately, Apple, Google, and Microsoft have committed to but not yet enabled cross-platform sync so until later this year you’d need to register both, say, your iCloud Keychain and Google Chrome keys separately.
Because each one is implemented separately you’d need to check your synchronization service of choice but note that e.g. iCloud explicitly supports recovery when you’ve lost all of your devices permanently:
https://support.apple.com/en-us/HT213305
> How do I log in on a computer without usb access that is not connected to the same network as my phone with the keys? - this workflow is already broken with gmail 2FA process with approving in gmail/youtube app.
Your computer doesn’t need to be on the same network (it uses Bluetooth). This is also a contrived situation: if you work on a computer which has been locked down that much, you don’t want to use personal accounts there anyway.
There is a solution to that, however, along with every other one of these edge cases: you type in one of the one-time recovery code the service made you setup up when enrolling. Unlike the password reset email, that isn’t commonly exploited by attackers, too.
Security people are literally delusional.
Or what 2FA means, or OTP, or how this type of authentication method is device-bound unless you sync. Or how the same service approached from different devices creates different keys.
So now we'll have classic password logins, social logins, and password-less inconsistently implemented across the internet. Normies will be even more confused now.
Where do I see what permissions I just granted from my (naturally, dummy) gmail account? What happens next time I want to login?
the only thing shared with passkeys.guru is the pubic key of your device (which was generated specifically for passkeys.guru and cannot be used to identify you or your device on other websites)
no biometrics or any other PII was shared with passkeys.guru in the process.
technically, you can use any identifier you want with passkeys, even just a dummy username - we chose to use email as it allows pairing with other authentication methods (oauth, magiclink, etc.) that are email based
Just use the latest & greatest open-source library, no?
AKA: We do Auth, you do you.
Other minor things to note: (1) You will be directly exposed to interest rates, and they can and do change quickly when nothing is locked in. This is usually in your favor (no more plummeting down instantly and climbing up very very slowly...), but it's worth recognizing. (2) As money market funds are security-like, it is usually slow to move money in and out of them. Securities trades do not settle instantly in the US, and this is intentional. Again, no issue if you know this is the case. Your broker may also hide some of this latency for you, depending on what you're buying from who.
[1] https://time.com/6248246/bank-of-america-zelle-missing-money...
We (FusionAuth, my employer) implemented it last year and things have improved a lot, though there are still issues.
We put together a vendor neutral site discussing all things WebAuthn here: https://webauthn.wtf/
If it doesn't work for you, that's your fault for not being part of the standards body when this was being proposed. Or, even if you were part of the standards body, if you don't agree to whatever the giant incumbents want, they'll go implement their own thing, defeating the purpose of the standard; so you have to agree anyway