Seeing this more and more with Chrome, like Credit Card numbers used to just save and autocomplete in browser but then they had some popup that was worded in a weird way that tricked me into saying it into Google Pay. Then I had to like type in the CCV to retrieve the card but then it also charged my bank account 1c for the privilege of autocompleting the card each time. Took me good 20 minutes to delete my card, get it saved back in the free local auto completely and shut down my Google Pay account I never knew I had.
Additionally, passkeys are just a synced-via-cloud implementation of FIDO2, an open standard that has other implementations you may feel more comfortable using.
For someone who requires being able to sign in to, say, GitHub from multiple different operating systems or platforms, you have a few options.
1. Use a passkey on your primary device, say an iPhone. You can still sign in to GitHub on a Windows computer or Android phone but you must have your iPhone with you. During sign in, there is an option to show a QR code on the Windows/Android, which you will point your iPhone at, and the two devices will do a secure handshake to sign you in. This is probably the worst option from a UX standpoint if you sign in on lots of devices that are not your primary.
2. Use a physical security key to store a FIDO2 key instead of a passkey. These devices are inherently cross-platform. Remember, a passkey is just a type of FIDO2 key. No one is forcing you to store it in the cloud. You can buy something like the YubiKey 5C NFC to store your keys completely offline and under your own control. The tradeoff is you will need to have it with you and you will need to plug it in every time you create an account or sign in.
3. Add multiple passkeys to your GitHub account, one for each platform you want to be able to sign in on. Unlike passwords, where an account generally only has one password at a time, it’s normal and even recommended to have at least one backup FIDO2/passkey registered with an account.
And of course these aren’t mutually exclusive, you can mix and match these techniques, perhaps depending on how important the account is or how/where you typically access it. Maybe you only use a single passkey on your primary device for your bedtime social media scrolling, but use a passkey with a backup FIDO2 security key on GitHub.
That's not true. Passkeys actually require iCloud Keychain, which is obnoxious, because you can't use the OS passkey support without using iCloud. And you can't even manually export passkeys from iCloud Keychain, which is totally opaque.
So it is still platform lock-in, just not in the way you described.
I've not had a problem registering both this and my phone on any site.
If you read adtech docs, authenticated user sessions are the gold standard on enumerating user preferences for the sake of ads.
Un/pw friction is noted as a difficulty in achieving this. Cookies developed the way they did in response, +/- details.
If cookies go, then passkeys look a lot like a tangible and realistic solution to enumerating users via authn/z’d sessions, minus the friction of un/pw and a pw manager.
IMO, the impacts of passkeys will feed right into this solution, and while I’m not sure if you can safely argue passkeys are a nefarious plan to replace cookie tracking, I don’t think you can get a tech giant to support such a reimagining of user experience if it didn’t have ancillary benefits beyond solely security use cases. When has a company like Apple or Google ever done such an equivalently large amount of work solely in support of security?
On MacOS you cannot enable passkeys (or using TouchID with them?) without enabling iCloud Keychain.
I'm fine with iCloud Keychain. But to enable it, you have to enable "autofill form password" which enables it in Safari. Disabling it in Safari disables the global setting and disables iCloud Keychain.
WTF.
I feel bad for the author. They put a lot of their heart into something that could have been awesome.
The big tech companies (Google, Apple, MS) have all become evil.
You create one on your iPhone and another "backup" key from a desktop PC running some open source software. If your iPhone breaks you can always use the other.
Similar to a server configured to accept multiple different SSH keys.
- Apple's iCloud Keychain syncs across devices
- Apple has APIs that allow third party apps to create and offer passkeys, presented as a first-class option in Apple's authentication system. I use this to sync my passkeys between my Mac, Windows PC, and iPhone.
Your passkeys sync in iCloud they aren’t device bound, just platform bound. Passkey export import is being worked on.
As I understand it the workflow would be: * get a new passkey * enroll the new passkey with all existing services * unenroll the old passkey with all existing services
That is certainly onerous for the "can my mom do this?" test. Like, I'm not even sure I want to deal with this myself and I have a Solo key (in a box).
Further, seems any service I'd want to protect with a passkey, is also a service that would be very difficult to lose access to, should I lose the passkey (or it fails). Therefore I need to enroll two passkeys with each service, to have one as a backup.
Uhh, OK. So now if I were to change passkey vendors/services - it's enroll two replacements, unenroll two? I haven't ever done this so maybe it's not as onerous as it sounds?
But in general I haven't felt these are secure enough for the reason you say.
While my practical threat model today would make passkeys seem great, the theoretical future threat model in my head does not support it.
Most folks store passwords in password managers and don't use their brains to retrieve them.
sure they do if, unless you want to be held in contempt of court for not providing the information.
I use Firefox as my browser and 1Password as my password manager. On my iPhone, I use 1Password + Firefox.
I look at https://passkeys.directory/ every so often and switch my logins from passwords to passkeys. This has included a lot of my common logins like GitHub, Google, and Microsoft.
There is a lot of confusing terminology. For some reason sites will say "login with Touch ID" or "login with Windows Hello" instead of "login with Passkey".
Aside from that quirk, I love it. 1Password syncs my passkeys between devices. I can use them both on my laptop and my phone. It would be inconvenient if I needed to login to a shared computer e.g. at a library or friend's house, but I don't do that often enough to care (though of course some people do, which is totally valid).
- PayPal only allows one passkey and don't support logging in with it on Firefox on Windows. You still have to use your password.
- Twitter only offers it if you pay for a subscription.
- Playstation Network doesn't implement usernameless, and still asks for your email to log you in with a passkey.
It seems like we still have some way to go before we figure it all out.
I can believe it's easy. But just knowing this doesn't give you any understanding of potential downsides.
Years ago I lost access to various stack-exchange accounts when Yahoo stopped offering Oauth services. Thankfully not a biggie for me but it soured me on relying on third parties for access to a given account.
Ok, I'll bite. Anyone knows how this would be done in that setup?
"Can't" is a deal breaker, so is "use the password you had to generate and store in your manager anyway".
I don't think we should consider passkeys failed already. The widespread rollout just got started, and the ecosystem hasn't had a chance to catch up. Give it some time, and see if things get better.
I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not integrate well with password less so it’s best to stay where I am until things settle out better.
Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password.
By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain. They provide no way for you to copy and paste the passkey into a website, as you can with a password; there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy.
A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login to a website, but the website has no way of knowing/proving whether that happened; they just get the password.
You reset your passkey the same way you reset your password, because passkeys are just passwords that have to be managed with a password manager. Some sites make it easy to reset your password, some make it hard. You know the drill; there's nothing new or different there.
If you're happy with your password manager, there's no real need to switch, but even very "sophisticated" password users have been known to fall prey to social-engineered phishing attacks.
Are you sure you're never going to copy-and-paste your password into the wrong hands? I don't trust myself that much.
Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager. I think all the password managers kinda like that, and there's something good and bad about it.
I feel like most of the replies to your comment talk about the technical aspect of it.
What’s stopping me is that I don’t have a mental model of the management of the passkeys for the whole lifecycle of my account. Can I use it cross platform? Can I allow someone else to use the same account? What happens if I lose or don’t have access to my phone or laptop? What if I die, can my spouse log in my accounts?
With username/password, it’s very clear what I need. I could write it on paper and give it to someone and it’d work. I feel more at risk of losing access to my accounts if I were to switch to passkeys, because I don’t fully grasp their long term lifecycle.
OK, so the simplest way to understand is to first know about the previous generation.
U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes.
In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compromised machine. You get a separate public/private key pair for every account and website (so it can't be used to track you between websites) and that key pair can be used to authenticate with the website. A physical button has to be pressed to authenticate, keeping it secure even if an attacker has control over your keyboard and mouse. The browser integration takes care of letting the USB key know which website is asking to authenticate. U2F keys have to be used alongside a username and password.
For a variety of reasons U2F keys never really took off. Partly cost, partly the 'what if I lose it' issue, partly lack of uptake by websites, partly difficulty using them on mobile, partly competition from 'log in with google' type systems.
So the trade group behind U2F said "Hey, maybe we could just emulate the hardware secure element in the smartphone's OS? And while we're at it, we could save the username, and use fingerprint/faceid instead of a password, eliminate that tedious button press, and automatically back up the public/private keypairs to the cloud". They kept a USB option about for the sake of tradition, but it's on life support.
So that's the mental model of a Passkey: It's like an impossible-to-clone USB hardware secure element that does challenge-response authentication to websites. Except it's emulated in OS software, and is no longer impossible to clone.
Another way of thinking of it is: It's very similar to using the 'Log in with Google' / 'Log in with Apple ID' buttons you see on many websites, you're authenticating to a service by proving you have access to a cloud account. The implementation details in the background are very different, but the result is broadly the same.
It's possible this was a Mac OS problem, but I don't think it really matters. Either way, this stuff needs to be absolutely rock solid and frictionless if normal people are going to use it safely, and it obviously isn't.
https://1password.com/product/passkeys
The super simple explanation is: SSH keys for websites.
You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc).
The website only gets the public key, so unlike password auth your secret is never given to the website.
When accessing that website, the website can send a challenge which your browser answers using your private key associated with that specific domain.
(I'm not a passkey expert and there are a lot more technical details to this, but this is my 10,000ft mental model of what's going on)
Phishing resistance is improved over what a good password manager can provide (unique passwords per site, checking web origin before providing options). Since WebAuthn is a protocol, the origin of the requesting site is stamped into the authentication response; even if the user had the option to override a passkey to be sent to a different malicious domain, it is meant to be rejected if replayed on the legitimate website. WebAuthn really needs an attacker to compromise the legitimate site or to compromise DNS and TLS infrastructure for phishing to be successful.
The uniqueness is really two benefits in one - you don't need to think of multiple unique passwords (if doing manual password management), or suffer with password complexity rules (if doing either manual or automated password management). It is just a public key, usually a P-256 curve point. The security of the user authentication process is abstracted upstream, so it is secured with the local password/biometric or via an activation PIN (same as password managers).
The breach resistance means that if XSS gets onto the page, if a hacker gets read-only access to the password database, it is still infeasible for them to leverage anything they gain to answer future authentication challenges. If your passwords aren't unique, a breach is a big deal and can create a lot of lateral movement. Even if they are unique, attacker visibility of the password means account compromise. The private key in a passkey is separate from the website infrastructure, so that attacker is not going to be able to authenticate from anything they observe.
The basic logic here is pretty clear imo. Passwords are still symmetric factors, and they're also completely unstandardized. So you still have to do a significant amount of manual management crap that should not exist, deal with UI that should not exist, and you still have to do some stuff if the other side (service provider) gets hacked. If we used bog standard pub/priv keys instead, then everything could become universally better. There'd be no need to worry about password policies, whether there is a character limit or not, how well and consistently individuals handle it, or anything like that ever again. Nor care if a site is breached, literally no action required because the site would only have the public key, they could publish it in clear text and it still wouldn't help attackers authenticate a single iota. Plus things like phishing and so on go away, because same thing, if the user has their agent browser to a malicious link or the like, and then it presents their pubkey, it still wouldn't do anything and the agent can't be fooled by similar looking to humans domains or anything. The agent would expect the service to present the proper signed request and anything else wouldn't work. Conceptually everything could be automated and standard without any sort of silo, all software could speak the same standard simple key format and everyone could back that up and sync it any way they wanted.
Unfortunately as is so often the case these days there's a lot of perverse incentives and players who can't resist the urge to try to add extra functionality in on top rather then just going for the low hanging fruit in a solid way first. So we've seen a confusing muddle, of existing players with financial interests who make money by helping lower the pain of the garbage that is password based mutal auth, those who see new chances to try to silo, those who want to shove in attestation and differences in password backing for good and bad reasons, mixing in concepts of hardware backing that are unnecessary, etc. I'm still hopeful something will come out of it in the end but it's been a real bummer to see how it's played out.
Here’s the issue: when a site rejects my password, I understand the potential reasons—wrong site, wrong account, or forgotten password update. But what does it mean when a passkey fails? How can I resolve this? Is it even fixable?
My lone attempt to use a passkey for login involved an unrecognized fingerprint authentication, leading to repeated failures and ultimately, a return to traditional passwords due to the opaque nature of passkeys.
For now, I’ll stick with what I understand.
Currently, I view the entire paradigm as asking me to trust resources (software, hosting, etc.) that I am not ready to trust. Both from a knowledge standpoint, or lack thereof on my part, and out of experience. Re the latter, third party resources die, go bad -- technically or morally -- and... just observing the nature of "online" resources over years and now decades.
When your security feature is not as simple as - remember a name and a password and store it somewhere safe - it doesn't work.
Something about keys that are on devices. But what happens when I use a phone and a pc? How to get access then? Do I need a User/PW for the first time? Or do I need one of those keys I have to plug into the device first?
I think it's totally reasonable, and probably a good thing for users having to use their username at login. Especially as it reminds them what username they are using for that service.
I could totally see a situation where a user uses a Usernameless passkey for years to access a service and for some reason loses access to the Usernameless passkey, and then has also forgotten the username for the service, so cannot even start an account recovery process.
I think it depends on the service. But aside from the occasional forum or social site, usernames are just an extra step. I don’t want or need one for banking/administration/ordering a product. For better or worse, email is usually a better identifier, assuming you already need one for other reasons (like you say recovery is typically needed).
> Especially as it reminds them what username they are using for that service.
Like passwords, forced usernames are hard to remember, if you use different ones. If you use the same, then it leaks privacy across services. (Technically usernames can be private but the expectation from decades of social sites is they are public)
> […] loses access to the Usernameless passkey, and then has also forgotten the username for the service
Correct, no identifier at all can’t be recovered. Hence, email.
1. I can, if I choose, have a passkey in software (no hardware enclave, no captive key, no TPM) even if the security of that sucks:
=> Implication: I can backup and copy a passkey without restriction, e.g.
putting the key material in an airgapped password safe, and without that
being visible to a website.
=> Implication: Websites can't discriminate by whether I have a passkey in
software or have any part in deciding whether I get to backup, copy or
transfer a passkey.
I haven't looked into this yet, so: do, or can, passkeys, or the contemporary WebAuthn implementations in Firefox or Chrome on Linux, meet my requirements?
We were so very nearly there with U2F... I did extensive testing and you can have a U2F (Fido2/webauthn) device deriving it's private keys, never leaving the device's HSM, from a BIP-44/BIP-39 seed. You write 12, 18 or 24 words down (out of a dictionary of 2048 words) and with these words, you can always reinitialize another Ledger Nano (a cryptocurrency hardware wallet but I didn't care: I was after the U2F "nano app").
It just worked. It was beautiful. My seed were written on paper sheets which I'd store in a safe at the bank / at my parents' home, etc.
As a bonus the hardware device would display, on its little screen, if you were enrolling or login (a useful info) and, for known provides, it'd display the name. For example "login to google?" / "enroll to dropbox?".
Pure beauty.
Then sadly this trainwreck that passkeys are happened, greatly lowering not only the security of 2FA (someone is in control of all your keys and they can be "backed up": what a concept!) but also making you lose the ability to backup your own keys/seed.
I do really hope at some point we see a future "passkeys nano app" for hardware devices on which the user is in control of the master seed used to derive the keys. It worked for FIDO2/webauthn. I hope it'll work again at some point in the future for passkeys.
So yes, I believe your requirements are met in practice.
I'm not aware of any restrictions at this time on your second point. I also haven't seen any examples of attestation and Passkeys being used in practice.
Google tries to force use of passkey now that if you enroll a Yubikey it will now be a Passkey, instead of a second factor. With no option to disable it. I have to run the Yubikey Manager tool and then disable "FIDO2", so that I can force it only be used as a 2nd factor.
This will cause a fallback to FIDO/U2F where possible and your browser will appear to not support FIDO2. I've observed this with the default Keycloak flow for Security Tokens. May be a bug, too...
I don't know if this works with Google but if you try it, let me know :)
This needs no restart of Firefox, so you can use it to quickly disable it instead of fully disabling it on your Hardwaretoken.
I'm trying to follow the developments in the 2-factor-auth space and this was one thing that confused me a lot. I've read a lot of hype on Passkeys being the next big thing but it was really hard to find an actual explanation what they are and how they work. And once I found out that these are keys that are stored on the security key, I was rather disappointed, because I really like the idea of generating keys on the fly based on the domain name that I'm authenticating against. This way I can "store" an infinite number of keys. The upside of Passkeys is supposedly that you do not need to remember which username you have on a website, but I think that's a minor upside.
Related question: What is the official name for the (FIDO2-based?/WebAuthn-based?) technology that calculates and reconstructs keys on the fly based on the domain name of the service that I'm authenticating against? It is really difficult to learn the right terminology in the area.
Edit: I think I found the answer here: https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-tu...
A key that is reconstructed on the fly is called a "non-resident credential".
You could do it on a USB cryptoprocessor, and securely, too. https://tillitis.se/
Actually, I think it might be worse. The predators like Apple/Google have already pounced on passkeys as a consumer capture mechanism, so they'll ensure it doesn't fail.
I was sceptical about something-you-own auth vs. something-you-know auth from the beginning and recieved backlash from my tech peers for it. I hate to be able to go "told you so" on this one. Lets hope im wrong about the government involvement, but i dont think i will.
Just about every website which implemented Passkeys removed the option to use hardware tokens with "non-resident" credentials. This means you're stuck using your Yubikey as either an insecure TOTP token, or as a practically-useless Passkey.
We had the perfect 2FA method with U2F hardware tokens, why did they have to take that away?!
It deeply saddens me too.
But I think we shouldn't discard one of the obvious reason: the U2F system was too secure.
Let's not forget this: the original U2F system even had a way for the user to know if its device had been cloned, for they'd be using a counter. And they silently removed this.
When Apple+Google+MSFT team up to lower security, I'm pretty sure three-letters agencies and their backdoors aren't very far.
The whole concept of passkeys that can be copied around is honestly hilarious. FFS: we had the perfect solution...
I don't think it's only incompetence at work here: there has to be mischief or at least mischief shouldn't be discarded.
Which ones? AFAIK they support passkeys in addition to password+U2F 2FA
I don't get the passkey hate -- moving to public key challenge for authentication is a strong step forward for web security. Each browser / OS safeguards & backs up the private key (and even if that's lost, you can still reset your auth credentials using a normal "forgot password" flow).
The linked article does a quite good job explaining why hating passkeys make sense.
Here's a key quote, but I do recommend reading the whole article.
> Since then Passkeys are now seen as a way to capture users and audiences into a platform. What better way to encourage long term entrapment of users then by locking all their credentials into your platform, and even better, credentials that can't be extracted or exported in any capacity.
Unfortunately, the big players are trying to force this (really excellent!) idea into platform dependency. They want to store the keys on physical devices, which (a) eliminated portability and (b) restricts the number of keys you can have. If your device fails, you will also be faced with account-recovery problems.
Great idea, but the implementations are looking...not great.
To get a new passkey on another device, the provider needs to allow you to prove you have possession of your other device first. They can do that by sending you a one-time code, for example, when you authenticate using your existing device, which you can then type in the new device, and that lets you associate your new device-generated key with your existing account.
With iCloud, you don't need event that because Apple can, and does, sync your keychain across all your Apple devices. So as long as you use the same Apple ID on different devices, all passkeys are automatically sync'd.
If you lose ALL your passkeys, you may be in trouble and for that reason, it's common that when you register your first passkey, you should also be given a long recovery code which you must keep privately in a very secure physical location (as that will allow anyone who can get it to reset your account). You could say that IS a password, and perhaps you're right, but there's a difference in my mind that's pretty big: you're never supposed to use that "password", nor keep it easily accessible or even anywhere in digital form.
Finally, a lot of people in this thread are missing that passkeys prevent phishing, and are basically the only way we know to prevent phishing. And phishing is extremely high in the ranking of security issues we currently have to try to solve.
If you know a better solution to phishing than passkeys, please let us know (Passwordd Managers are not that if they allow the clueless user to extract the password and manually enter it anywhere)!
> how do you get a passkey on a new device when you only have passkey auth on some other device enabled?
You'd use a sync service like a password manager.
If you're enrolling a new device (say you buy a new android phone) you can scan a QR code from your previous phone go log in.
Well, not as secure as a commercial key, because the Pico doesn't have encrypted storage, but still much more secure than login/password.
Use a passkey on https://www.passkeys.io and it works great! On google too. But use it on PayPal, it does not anymore. Who’s to blame?
How can it be that the website decides which password manager I should use to store the passkeys? That's crazy and goes against all intuition.
If you want your passkey to “just work” you have to turn off TOTP. But thats a bad idea because passkeys are an alternate method of auth with paypal, not a replacement for passwords. So then you are left with the option of a password only sign in (no TOTP) or a passkey.
If you’re going to push a replacement for passwords and want it to be universal, it should be EASY to implement. Even if the backing cryptography is complex, the actual handshake / implementation shouldn’t be. TOTP as an example is insanely easy to implement. Password auth of course is as well, despite needing to know what you are doing to get it right. Both can easily be handled entirely without JS.
I should quite frankly be able to just <input type=“passkey-public-key”> in a standard POST form for registration and be able to call it a day. It doesn’t justify how complex it is to set up.
A fitting password replacement should just be as smooth and easy as ssh. I give a website a public key, I use my private key. I manage my private keys however I see fit. I don’t need a third party involved holding my private keys hostage.
I too find it hard to imagine how someone can lose all their passkeys three times, and I guess they may be doing something funky given their profession, but I think many of these events just happen too easily in the Apple ecosystem and my trust in them managing things like that is relatively low - hence my use of 1Password instead of iCloud keychain. The Music thing in particular really stung as I never got a good handle on what was missing - I'd just occasionally come across a "this file is missing" error when I tried to play a song, and I'm left with this kind of cloud of unknowing when it comes to my Music library.
I wonder if it means that the author will stop working on the library after their next release, and more importantly, if the UX is going to be horrible with people unable to log in and other issues they mention.
On a tangent, I share their discomforts about travelling to the US. The last time I was there, I felt uncomfortable being out on the streets alone. Maybe the portrayal of police brutality towards POC is a factor (for me).
Just FYI it seems the library will still be maintained: https://infosec.exchange/@firstyear/112337225055591544
Using bitwarden, it adds them in just fine. But, if you go and try to log into a Google account with Brave, it tries to use the Brave system builtin instead of the Bitwarden one. Presenting a dialog too.
As an end user, I don't know if it is bitwarden, brave or google screwing this up and I can't be bothered to figure it out, so it is back to just using passwords and 2FA...
I understand that, in principle it’s your device, and not your account, but it feels like the fingers are too deep to hand over one more thing.
Adjacent to this, I really liked Steve Gibson’s SQRL. I wish that had taken off.
That is my main reason for avoiding Passkeys;
I will only use Passkeys, when i can export/backup them easily and store an offline backup, without depending on some Big Tech company or whatever. (KeepassXC can export them, but not sure if it's released and fully functional in the stable build yet.)
What also worries me however, is that apparently if i read correctly, each server/service/website can decide/restrict "which password managers/apps" are allowed to be used for the Passkeys they offer...
With both of these I have little sense of what is going to happen if I lose my phone or switch to a new one. So typical passkey problems.
I recalled I had what I thought was a spare USB key... plugged it in only to discover it wasn't a USB disk. Wasted some time trying to figure out what it was only to discover it was some form of electronic key. Not sure how exactly it works... but, of course, Linux had no drivers for it, so it couldn't even recognize the device.
I tried to think about any possible uses I could want from it and whether it's worth the effort of trying to find an out-of-kernel driver for it... and after some time pondering this idea, I realized I have no use for this thing. There's no scenario in which I would like to have a device to perform this function. So, bundled it with the broken pieces of my old laptop and together they went to the garbage dump.
Passkey would be virtually the same thing. I cannot imagine what problem does it solve, no matter how it works. Everything about this idea seems like a bad idea. So, I'm kind of happy it's a shattered dream now. Better late then never, I guess.
If there will be a way to backup and restore between competitors, for example from bitwarden to 1password or vice versa, im fine to go with bitwarden now. Backup and import passkeys from Bitwarden to Bitwarden already supported.
So please FIDO'S contributers, find away to standardize backup&restore passkeys.
As long as you are satisfied with passkeys being "usernameless" (i.e. discoverable), you can offer a nice login flow with a "Sign in with a passkey" button and Passkey Autofill.
For 2FA use cases, you should provide a second WebAuthn configuration that does not require discoverable credentials, for example, and does not necessarily require user verification.
This allows a user to have both fully-fledged passkeys and, for example, security keys as a second factor to secure username/password-based login. Users can choose what they want to do (create a passkey on e.g. iCloud or add security keys as 2FA without using precious key storage resources on the hardware tokens).
GitHub has done a very solid implementation of that model, and we are working on adopting it to our services and it's looking very good so far.
But the more I wanted to use Passkeys are more scary it got, basically the gut feeling of losing control.
If we could use something akin of derived, reproduceable-ish (???) Passkeys maybe then.
As of right now it feels wrong.
As an exercise from a developer's perspective, try creating a chart of every device type (mobile, desktop etc), browser, and Passkeys platform provider (Apple, Microsoft etc). Then fill out how each behaves across each combination, it is a nightmare!
I'm hopeful that we'll see more cooperation across Passkey providers to align both the devx and UX to increase adoption where it makes sense. Not holding my breath too much though.
My conclusion so far is that it's a promising technology, but no way as mature as I'd like it to be. Unfortunately we are stuck with emails and passwords for the foreseeable future, at least as a back-up mechanism for credentials recovery, which, funnily, makes the whole thing pretty much pointless.
That you can always just copy them out, put them in a different password manager, or write them on a post-it.
That said, I think this is a byproduct of the design space being complex (as you suggest) and not, as the author seems to feel, "thought leaders" or malice.
With passwords it's fairly obvious. Even if you don't know about password hashing, semantically it is the same as how you would obviously expect. Same with password managers. It's obvious what they're doing.
So I think this would fail even if it didn't have all the problems the author mentioned - it's simply too complicated for normal people to understand and trust.
What's most disappointing is, password managers have already solved the problem of syncing credentials securely between multiple devices across different form factors and ecosystems, and they're perfectly usable for providing software passkey support. So of course.. there's no standard API for them to implement it. Instead, vendors are patching the WebAuthn APIs using WebExtensions.
This is sabotage.
This is the same Credential Provider API they already have to integrate with to show the password autofill in iOS so there is already _some_ code for this.
1Password _could_ just integrate with the native UI. But they chose not to. This however means shipping a native app which is a lot more heavy-weight than shipping a web extension.
I opened an issue in the webauthn repo about giving an API for WebExtensions to hook into the passkey autocomplete but there hasn't been any traction or appetite for it unfortunately :(
The other day I noticed that for some reason GitHub couldn't seem to find my Android passkey. Weird. So I logged in using my Yubikey and recreated it.
But this would be a lot worse if it were your only way of logging in. Always have multiple authentication methods for important accounts.
Just use PKI / X.509 with hybrid smartcards for enterprise use cases. Sure, it’s “legacy” and you need an PKI expert to set it up, but it actually works and is genuinely platform-, vendor- and protocol-agnostic. FIDO is smelly poo poo in comparison.
Also, smartcards had usernameless for 30 years.
Edit: actually we’ve been here before. Remember the <keygen> tag? Platforms (browsers) could generate a key pair for you, store the private key in their key store (I think <keygen> actually supported smartcards as well), and forward the public key to the server for enrollment. The server then sent the signed certificate back. That’s pretty much exactly passkeys. This was somewhat widely used for “high security” applications at its peak, circa 2007.
Similar problems like passkeys caused issues, it was difficult for users to get their keys and back them up, most people were just one hard drive crash away from loosing access.
'something i have' means carrying something around and also the possibility of it being forgotten/stolen/broken/taken by authorities (legally even!) and the repercussions of that. i'm fine with this, only if i am allowed to access/export/copy/store the keys myself. I can do that with totp auth and i do. people say this "breaks" security. but the point is: i control what i own; i control me (not you).
'something i am' has the worst drawback. you can't change it! the other issue is you are not the unique snowflake you think you are. Also, side note of a personal experience: India has mass fingerprinted everyone, yet in trying to do some bank transactions in India the fingerprint read/auth kept failing for an acquaintance.
Instead, if "the industry" wants to solve "the problem", they need to write down all the use cases. Then we can argue about how to do that, and the result will probably be a couple different things that solve a couple different groups of use cases.
But what will always suck is letting "the industry" dictate to us "tech peons" how that should happen. They always come up with bloated standards that are a pain in the balls. So rather than let "the industry" solve the problem, I think we need a loose confederation of open source contributors and corporate goons to meet on some forum somewhere and hash it out. Let the solutions (plural) come organically without a single player controlling the conversation.
I can understand the frustration from the author’s point of view, but I live with the other side of 2FA through weak SMS every day. My users can easily be tricked into giving up their 2FA code while being social engineered, and passkeys offer me as a developer a way to give them a more secure solution that I don’t have to worry about them reading aloud to someone calling and pretending to be CS. This is a weakness in the core of 2FA via SMS, and the author seems to be just hand waving away from that. No one SIM swaps their way to compromising a passkey, and no user can share their passkey with a scammer as far as I know.
The most obvious explanations seem to me to be:
a) Apple loses data (presumably not just Passkeys, but also photos, passwords, and other highly noticeable stuff) all the time, and I've been lucky for the last ten years. Hundreds of millions of Apple users just learn to live with this.
b) The author is doing something weird.
c) This is hyperbole.
I'm probably picking nits, but it's like an article raising a bunch of legitimate criticisms of the internal combustion engine mentioning that the author's car has, while sitting in the parking lot, simply exploded on three separate occasions. Like, maybe?
The author is the main dev of an identity management platform and called kanidm, so yeah I'd wager their usage is fairly non-standard. That said, it should be almost impossible for it to happen anyway.
Also, that doesn't apply to his partner.
So what happens if you want to migrate away from iCloud for the storage of passkeys?
Firstly I spent weeks chasing down what I thought was a data loss bug in iCloud. After much effort I managed to reproduce it. Turned out it was an issue with TeXshop rather than iCloud.
Secondly, the one time I had a photo lost, it wasn't lost. I just couldn't find it in the 12000 photos I had. It wasn't where I'd left it.
The third one was a data loss bug, was reproducible, was reported to Apple and was fixed. This was due to how Numbers handles three devices and how it decides the winner of a conflicting change and was an edge case as number 1 awkward customer.
YMMV but user testimony may be as reliable as eyewitness reports.
i have been using passkeys on apple since they launched it. i have also converted all of my 2fa’s to passkeys (where supported) or enabled them as password alternatives. a lot of website support passkeys nowadays. i never encountered what the author encountered and it seems like something seriously wrong happened.
did anyone encounter this issue? is it logged somewhere?
i seriously considered dropping passwords completely for future projects, but it looks like there are still issues…
I haven’t had a single issue yet, and while I accept that it would be annoying if iOS suddenly wiped my keys, I really feel like it shouldn’t matter: ideally you shouldn’t have only one passkey to begin with, but even if you lose it, all services I use still allow “normal” logins as long as you can 2FA with a phone number or email.
> For devices like your iPhone or Android, you would do similar - just use your Touch ID and you're in.
The fingerprint scanner on my phone is so finicky this would've been a dealbreaker from the get-go. I regularly have to just enter my PIN because it refuses to recognize my fingerprint.
I work in cybersecurity and need to think hard and draw diagrams to understand how modern authentication systems work (modern = something more than passwords). The implementation part is hidden from users but they only understand "password". Sometimes "fingerprint". Anything above that is really tough.
While Passkeys are an interesting development, it will take time before they are part of the authentication routine of standard users.
[1] - https://arstechnica.com/tech-policy/2024/04/cops-can-force-s...
- credit card sized
- completely airgapped
- standardized
- controlled by a non-profit association
- hard- and software open sourced
- built-in camera to scan data
- built-in display to show data
- configuration mode: scan human-readable configuration
- data is QR code or something like Base58 to copy by hand
- backup by supporting applications: scan and print out data
- browser integration by an extension using a webcam
https://en.wikipedia.org/wiki/OpenPGP_card
In fact the Estonian Id-Card is one of these if I'm not mistaken
within a business where we have policy around what devices may be acceptable the ability to filter devices does matter.
Is a solution to this on desktop to use GPO policy to add a mandatory "attesting" extension (that you build yourself which just verifies the device is what it says it is), and on mobile to use a webview inside an app with similar attesting info injected into the page context??
Hmm...
"As of Q3 2021, 37.0% of internet users worldwide use ad blockers, according to GWI data cited by Hootsuite." https://www.emarketer.com/insights/ad-blocking/ "
1. Most relying parties support resident keys only. This makes a bad user experience because users are surprised when they run out of space, and may have to wipe their device to get more.
2. Most authenticators do not allow you to export your keys. If a relying party only allows a single credential per account, this creates authenticator lock-in, which is a bad user experience.
3. Chrome is uncooperative about the Authenticator Selection Extension, and that can make a bad user experience if the relying party rejects the device attestation after enrollment.
Yes, these are all bad user experiences, but they don't indict the technology. It sounds to me like the relying party can mitigate all of these issues:
1. Support non-resident keys. Seems like it really doesn't have to be a bad user experience. Usernames are easy to remember. Just use their email address.
2. Support multiple keys per account. Most users will have multiple authenticators. Let them enroll several and they're not locked into any one in particular. Most users won't care about this, but for important services it's an option.
3. As a relying party with strict authenticator requirements, just explain those requirements on the passkey registration page. People can read. They don't have to be that confused when their unsupported key doesn't work.
I get that there's nothing users can do when the relying party creates a bad experience, but if a relying party has all the power to create a good experience, is it really worth being this gloomy about the technology?
But even if on balance the tech is worth implementing, it’s clearly not easy and your suggestions to “just” do several things that aren’t happening ring a little hollow.
1. SSH keys, as they're normally used, let you be tracked between hosts. That's fine for SSH, because nobody's trying to SSH into their Grindr account. But for web login stuff you want a different key pair for every site.
2. Adds a bunch of 'attestation' features that corporate types think they need.
3. Tries to make it so an attacker who gets access to your machine can't make a copy of the credential. The success of this is implementation-dependent.
4. With barely any setup, Google/Microsoft/Apple will keep a backup copy, in case you lose your phone. This is useful for non-technical people.
So, yeah, useless technology for now. Passwords and TOTPs are the way.
Personally I love the convenience of passkeys (coupled with 1Password pw manager), however, for whatever reason it doesn’t “feel” like Passkeys replace passwords but rather they complement them. I treat Passkeys as ephemeral—it is lovely when they work, but sometimes I still need to fallback to trusty ol’ password login.
As long as the server supports the device/protocol/options you want, and doesn't enforce attestation against a small list of enterprise vendors.
For instance Microsoft Azure AD's Entra ID authentication service, the one that keeps changing name, has a hardcoded list which you can consult here: https://learn.microsoft.com/en-us/entra/identity/authenticat...
In theory there's no vendor lock-in. As long as Azure adds your vendor to the Azure-approved list, and as long as every other provider refrains from making their own list.
For the Apple/Google ecosystems specifically, it's also important to keep the compatibility matrix for each service in mind. For instance with Azure again: https://learn.microsoft.com/en-us/entra/identity/authenticat...
In theory any FIDO2 implementation could work with any service that accepts passkeys. In practice, compatibility matrices and allowlists are the reality.
No, TOTP and passkeys had different motivational concepts:
- TOTP Time-Based-Onetime-Password of a "rolling numeric code" is conceptually similar to "trusted hardware" such as RSA SecurID tokens: https://www.google.com/search?q=securid&tbm=isch
- passkeys are conceptually similar to "trusted hardware" such as biometric USB vault from Yubikey that cost $50: https://www.yubico.com/product/yubikey-5-series/yubikey-5-nf... ... or Nitrokey: https://shop.nitrokey.com/shop?&search=nitrokey%203
In both cases, you can put secrets into the hardware but can't extract them back out. You can _use_ the secrets stored in the hardware via your fingerprint to facilitate logins but you can't extract/copy the digital data from one Yubikey to another Nitrokey. This restriction for USB vaults is deliberately designed for security but typically isn't disparaged as "vendor lock-in"
However, increasing website security via "trusted hardware" by making everybody spend an extra $50 for a USB vault is not ideal. Instead, a bunch of security experts noticed that billions of people are already carrying smartphones that have built-in biometric security such as face-id and fingerprint readers. Ok, let's just piggyback on existing smartphones and make them "act like the $50 Yubikey/Nitrokey" -- which means mobile passkeys managers like Google not allowing simple export/copying of passkeys.
Yeah but desktop managers like 1Password, Bitwarden, KeePassXC allow export of passkeys! True, but there's controversy and disagreement about that because they're not restricted like the Yubikey hardware is. Will some websites that are very strict reject some clients that allow passkeys export? It's a wait & see.
If the "ideal" passkeys ("ideal" from the RP Relying Parties point-of-view) are for them not to exportable/transferrable to another device, how do they expect people migrate from Apple to Android or whatever? By generating new passkeys for that new device and adding it the list of approved passkeys the website accepts. Instead of transferring the secrets, you re-generate new secrets.
This feels like the best advice, imo.
What's wrong with these Aussie technocrats?
"I'm Australian so I wont be attending either (I am not comfortable to enter the US due to a preexisting medical issue)."
That's the "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance" part of the text.
I do not know if travel health insurance generally covers complications from a pre-existing condition, and as other mentioned, getting travel insurance which covers the US is already a special case.
As an Australian, seeing it on the news the next mornings made me very, very uncomfortable.
I understand that these shootings are unlikely to ever involve me, and I’m not discomforted to the point that I won’t go back to the US, but it is worth understanding that gun crime in the US is seen as uncomfortable and concerning to many. That my US friends who were at the same venues with me were completely blasé about it left me a little nonplussed.
What is not is walking 30km in the middle of nowhere in Central Asia because you didn't have enough cash to pay the driver's bribe. Stuff like that is a far more realistic concern than the security border paranoia stuff that goes on. Know where you are going, plan ahead and stay out of obvious trouble. That applies everywhere. The US is not special.
(Incidentally when I got to the first town, the guy in the shop laughed at me and invited me in for tea and dinner on him and his wife and I got to learn all about their history under Russia - it's not all bad)
I like passkeys as idea for stonger security, but author somehow thinks that discrimination against devices is a good idea.
Sorry, no. Just no. I dont want my bank or paypal require me to use iPhone in order to login to my account.
The problem is that browsers are infamous for randomly losing things like localstorage, settings and saved passwords. It's way too volatile software to do authentication with besides a "stay logged in" checkmark. In both of the main desktop browsers, a corrupt profile is often only "fixable" by just nuking it and having the browser recreate it.
That's what killed Passkeys; people you want as early adopters (technical folks) don't use it because browsers aren't a trustworthy storage and the implementations all severely stalled in providing alternative methods that are tied to more reliable storage mechanisms. The hyper aggressive vendor lock-in is also not helping much (to the point where KeePassXC got yelled at for providing an export mechanism).
Please.
only passkeys is a problem
Enshittification in a nutshell. The victory of greed over utility.
I get the capitalist inclination and desire to make things easier for people (and often infantilize them) but this just ain't it.
There is no easy solution here. Security is difficult and there are no shortcuts that involve "make things easier for the general public" that don't ALSO involve "make things MUCH HARDER (either in complexity or LIABILITY for getting it wrong) for the company providing the security."
Sometimes you just know when a thing isn't practically feasible.
There is nothing wrong is passwords.
There is everything wrong with biometrics.
Wake up!