The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials but if Apple decides to delete your key or you want to leave your iPhone behind, what are you supposed to do?
The platform lock in attempt is wild, my initial experiences with Passkeys were great on iOS and Safari, either getting pushed to touch-id or scanning a QR with my phone. But then in Chrome I couldn't get into GitHub because chrome would only push me to use their manager and wouldn't offer a QR code.
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.
I tried. The power-grabbing garbage was immediately apparent and sent me straight for "heck no, I'll just use passwords until they figure this out, at least that can't control my password manager".
In principle I should be very in favor of them, but the wild variety of lack of support for basics, and the built-in-the-spec ability for site X to control how I store and sync stuff is utterly bonkers. It's feeling like the OpenID promise -> OAuth platform lock-in cycle all over again, but compressed into v1.
1Password is a closed-source, cloud-hosted service. At any time, for any reason, they can close and delete your account, leaving you high and dry. Self-hosted, multi-device password managers are the only real solution. Thankfully, Vaultwarden and KeePassXC fill this role perfectly.
Now if we could just get the other providers that require insecure email/SMS 2FA to follow suit, that would be great...
Same thing with google app on ios. My wife saved a password to a site on her phone and we were trying to find it to log in again. Since she had navigated to the site through the Google app, the password ended up in her google account instead of the iPhone keychain - unlike in every other app on the iPhone.
> and shut down my Google Pay account I never knew I had
Google loves that nonsense, don't they? It's as though they think so highly of themselves that they cannot imagine they might not be strictly doing us all a favor by signing us up for their services.
Fifteen years later, I still have friends occasionally sending messages to a GMail address I never asked for, never used, and didn't even know about for most of a year while it was virally spreading through people's address books, silently diverting mail away from my actual address. The only time I used this account, after I discovered that it existed, was to delete it - but GMail apparently still suggests it when people type my name, because I get an "oops, sent this to the wrong address" forward every few months.
No I will not be knowingly using any Google passkey service, but perhaps I will someday find that they have signed me up for it anyway.
As shitified as the world wide web has gotten over the last few years, that's almost a feature these days.
Now you have lots of chaff / ablative / imposter emails to divert away all the robo-mailers, spear fishers, destitute princes, and the like. Even the tiniest little mistake and the email goes to one of a million diversion accounts.
Side Not-a-joke: On this topic, I also really hate two-factor authentication you don't sign up for, don't want, yet are forced to add to your account, because Google Play is too much of SCIF to just let you log in. Even more security theater for the most basic activities. Now I need two-factor every time I try to use GitHub. Ugg.
My wife has the opposite side of this problem coin. Her gmail address (which she does use) has virally spread through a family and circle of friends who all believe it relates to a person in the US who we are entirely unconnected with in any way. Attempts to get them to sort this out always fail because inevitably the address gets re-added to some thread or other and starts spreading again.
Never surrender any email address that a random berk can then claim.
I had my Facebook taken over because I had all notifications disabled and forgot that the email address was associated to it. Some criminal behind an Egyptian IP address took my old email and was in my Facebook within two days of me surrendering it.
The issue is not forwarding the email. The issue is people sending email to the Google address in the first place. As someone who just set up email on his own domain, I'm starting to wish I could search every database and contacts list for my old Google address and replace it with the new one which is actually mine.
That seems like an invitation for long-term pain if Google changes their policies, requiring someone to log in every X months or have their gmail account locked, for example, or some AI enforcement tool locks the account for inscrutable reasons.
Odd! I've been able to sign into desktops running Chrome both on Windows and Mac. Both times Chrome will show a QR code that my iPhone scans. The actual passkey is stored in 1Password.
The dark pattern about signing up for google pay is absolutely inexcusable though. Sorry you're going through that.
I think they changed it recently to offer a QR code because checking now it's offering it. But I absolutely had the issue for the first few months of the year.
> Then 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.
I believe those transactions are never confirmed and are reverted after 7 days or something like that
You are able to share an Apple passkey to any nearby Apple device at any time using AirDrop. Passkeys can also be used cross-platform during sign in via an NFC/Bluetooth handshake initiated by QR code.
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.
Number 2 is not true. I have a Yubikey and it can't be used on Android without a Google made app or account. It's always the same story, give a plausible option to seem open or neutral, but make sure there are "details" that establishes chain of consequences preventing it that is weird enough to allow denying intention. Even though I'm not that young I thought I just need to wait for Firefox to implement it, but as time went by I got curious and found out why it actually can't be done.
I was able to log in to GitHub using a Yubikey on my Pixel without a special app.
Check whether your Yubikey supports resident keys (aka discoverable credentials) and whether the FIDO key for your account was created with residentKey: true, otherwise it’s a completely different (older) flow under the hood, where the private key actually gets sent to the server, and it wouldn’t surprise me if that’s the underlying cause of what’s happening to you.
Thanks for trying to help but I really meant it can't be done, not that it doesn't work for me. This is the starting point for understanding why https://bugzilla.mozilla.org/show_bug.cgi?id=1678045 but that rabbit hole is pretty deep if you want to understand the whole web of consequences.
Wow. I just bought a couple of new YubiKeys for the OpenPGP Curve25519 support. I was looking forward to using the NFC feature with my Android phone. Is it just a Chrome problem? I downloaded some OpenPGP app from fdroid and it says it supports NFC keys.
I'm not sure about your exact situation, lot of the scenarios are OK, just the one without Google services which are dependent on Google account doesn't work. That is actually irrelevant for "normal" phone users that are logged to Google all the time anyway.
I consider myself technically savvy, but I end up with countless different passkeys for different devices, and then multiplied again by all of the different services out there.
I have so many keys scattered everywhere that I would need an excel sheet to keep track of them. I regret not doing that already .. or perhaps I regret using passkeys at all. I am still trying to figure that out.
No, you add a new passkey from Android and then remove the passkey from iPhone.
1. Login with the passkey from your iPhone.
2. In your account, add a new passkey from your new Android. Now both passkeys are active.
3. Login with your new Android passkey.
4. In your account, deactivate the passkey that is stored on your iPhone.
Passkeys aren’t passwords. You can have more than one active at the same time. So instead of moving a single passkey around, you add or remove them to change devices or service providers.
> If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this.
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.
So use a password manager still (1P). You can have multiple passkeys for different devices or keychains but no entering passwords or credentials. Still an improvement and far less vulnerable.
1Password is a platform, one that has gotten worse over the years. They've taken a bunch of venture capital, switched to rental pricing, and apparently now demand that everything be in the "cloud". No thanks. I prefer to be my own password manager.
If you've already got a password manager, what benefit do you get from passkeys?
Avoiding the risks of short, weak passwords? The risks of reusing passwords across sites? The inconvenience of remembering loads of passwords? The frustration of having to type passwords manually? The risk of getting phished or typing one site's password into a different site? Remembering and typing usernames? The password manager takes care of all that for you already.
And if your objective is to have a second factor just in case your password manager gets compromised? A physical button just in case someone takes over your mouse and keyboard? Or a credential stored in a secure element that's (somewhat) protected even if you use it on a compromised machine? Putting it in a password manager (or OS keyring) removes those advantages.
Passkeys can’t be phished, or shoulder peeped, or entered on a malicious domain. And for the layman, it means they can’t forget their password.
Technically the place where you store your passkeys can be hacked into, but there is no technology that protects against that. You could give a tech layman 5FA and he’ll give all 5 factors to the nice man on the phone call.
Password managers should be the default authentication method, and the current hack of having it type text into a password field is both unwieldy and completely avoidable.
The risk of your password getting stolen in between your browser and whatever hash algorithm the service you're authenticating with puts your password through before storing/verifying it.
That's the benefit you get from passkeys that no password manager will otherwise be able to give you.
The actual implementation of password managers is really messy. Browser extensions that try to guess which field may or may not contain your username, copy the 2FA code to the clipboard in the hopes that you’ll easily be able to paste it on the next page… passkeys offering a standardized API to provide this information makes it worth considering alone IMO, even without considering the extra security compared to plaintext password.
I've found the Bitwarden to be hit and miss. Some sites work fine with it, others don't work. I haven't debugged it enough to work out whether the problem is on the Bitwarden end or the website end or something else altogether. Given I'm wary of the benefits (or lack of) of passkeys I haven't really looked into it in depth as I have other 2FAs I can use instead.
I think it’s about platform lock-in as well, tightly correlated to pivoting away from cookies due to regs and user pushback.
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?
Big problem with this is that enrolling the secondary passkey requires the authenticator to be present. This is super inconvenient and risky as it always requires both authenticators to be present at the same machine/physical location, exposing both to local, physical threats (faulty USB ports on your machine frying anything you plug in? Congrats, you've now fried your main and any backup authenticators before you realized what was happening).
Ideally, you should be able to get an authenticator's public key and be able to enroll one without presenting the authenticator itself, allowing you to keep it in a safe/etc.
This would enable an easy workflow - enroll main authenticator as normal, then enroll your safely-stored backup by pasting its public key. If you lose your main, go to your safe, get your backup and "promote" it to primary and enroll a new backup one which goes in the safe.
It always struck me that 2FA is a corporate suicide pact. Some percentage of users are going to lose their keys per year so your user base is going to decay like a radioactive element.
This is why you need to enrol the secondary passkey at the same time you enrol the first one, not later when you might not have the authenticator present.
In reality websites should not allow setting up a single passkey.
Do they typically not? My only contact with passkeys has been the 2FA service (Duo) at my place of work, and I've got a passkey on my phone and laptop, as well as OTP push notifications, OTP SMS, or recovery code from IT. It's particularly handy with the Chromeboxes hooked into the big presentation displays since I can scan a QR code with my phone to use the passkey stashed inside it.
Slightly poor wording from me maybe. There have been cases where for example only one hardware key could be set up but other methods were available at the same time.
I remember AWS having some weird choices at some point too, not sure how they are currently.
But yeah, typically I think most services have had multiple choises available at the same time.
The trouble is if it is on the service to do the support, they can revoke support at any time. They could use start tightening the screws on device attestation tomorrow for business reasons and drop support for your browser or phone.
> The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in.
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.
I agree. So far I think KeePassXC is the only one that allows you to export your Passkeys. I believe Bitwarden are working on it as well. That said, it's unclear whether this will provide any portability of passkeys between providers.
I assume each provider will have the ability to import as well as export. The question is whether you can do that across providers. That's not too different from the status quo for passwords and other fields though.
And I haven't seen any announcements in the opposite direction.
————
Edit: so I just checked and I can confirm that it's not possible to export passkeys from 1Password. Neither of the two available export options include passkeys.
> • 1PUX A 1Password Unencrypted Export (1pux) file will export all your data, except your passkeys. You'll need to create new passkeys with your next password manager
> • CSV (Export only certain fields) A comma-separated values file (.csv) will export only certain fields. It won't export data such as custom fields or file attachments.
This is why I’m not interested in passkeys unless I can use it with my password manager (which I probably can at this point). It would also be nice to see the spec for these specifically address lock-in and provide anti-lock-in measures.
KeePassXC has support for passkeys now. However I've only managed to make it work with GitHub. Bitwarden does not work for now (although their passkey implementation for log-in is reportedly in beta).
The idea of a passkey is that it's bound to a device, and you can have more than one passkey. Think of a YubiKey, just that you can use your Phone or your PC instead.
You basically have designated hardware that is always allowed to just login to your account...
Because there is no way to do that at scale. If I've tied 200 services to my Windows-managed passkeys and now I want to switch to Linux, I have to manually go to each of the 200 services and ask them nicely to allow me to enroll a second key. This is simply unacceptable - and it's not like I could have done this ahead of time when I first signed up.
I've had a link to OnlyKey's user guide bookmarked for about a year[1]. They're an open hardware company that offers a key. Despite that I still can't be bothered to go through with it. The article we're talking about includes many of the reasons.
I feel bad for the author. They put a lot of their heart into something that could have been awesome.
Honestly platform-locking has so frequently and consistently been the intent of security-washing rhetoric and major breaches have become so commonplace that I now view "security" in the press to be a euphemism for lock-in first and foremost, with other usages being anachronistic or niche
KeepassXC says that it is adding (has added) passkey support. I haven't tested this yet, but if it works, that would avoid platform lock-in. Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job.
The big tech companies (Google, Apple, MS) have all become evil.
> Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job.
My understanding is the ability to do that is built directly into the spec with the attestation feature. The only thing that might slow it down is Apple choosing to not implement it and zero out their device string. Others can piggy back on that to protect themselves behind Apple's skirt, at least until Apple changes their stance anyway.
Platforms of course could just not allow Apple passkeys and only allow Apple users to use other 2FA options as well. Rest assured that small players like KeepassXC will be the first ones to have their passkeys blocked or not supported.
I've tried it and it works on GitHub. Sites seem to be hit-or-miss for now. Tip if you want to use it with the browser add-on, it needs to be manually enabled and you also need to remove any YubiKeys from the system because it will prioritize them over KeePassXC
This isn't a viable option in practice, because Passkeys use "Resident Keys". This means the credential needs to be stored on the Yubikey - which has a limited number of key slots. Need to log in to more than 25 (I believe) websites? Tough luck!
I'm curious as to why the number of slots is so small. Surely this is not some kind of fundamental limitation on what's possible (or cheap) with hardware?
Use a better token. YubiKey is the most popular one, not the best one by a long shot. My (cheaper) alternative supports 300 resident keys per each hardware key.
Webauthn, FIDO, etc. is run by a consortium of corporations whose goal is to be your sole identity provider and own your digital life. Nobody should have been hyped about this crap from day one.
Wouldn't this be solved by just having multiple passkeys for each account?
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.
There is a way around this. Password managers. I use 1Passwords and it acts as the vault for all my Passkeys. Can access them on all devices. Super happy with it.
Is there a way to export a passkey from 1P to use in a different manager? (Legitimately asking, I haven't tried passkeys yet due to portability concerns, and this would be good to know)
There’s some hope for interoperability between password managers someday. There doesn’t seem to be agreement on how you can securely export, transfer and import today however.
nope, and that's (currently) by design! from a user perspective, passkeys are supposed to be impossible to duplicate. here are some workarounds:
- you can log into your 1password on multiple devices
- you can sign in by QR code, with the help of whichever phone has the passkey on it
- you can add multiple per-device passkeys to your accounts of interest (for example, log into github on desktop and then add a passkey for your desktop device for that github)
- you can keep all your passkeys on a hardware dongle
- you can set up and keep all your passkeys inside an open-source manager (e.g. KeePassXC)
For first-party systems, passkeys are supposed to be stored in hardware storage (TPM chips, secure enclave, etc). Once it's in the chip, the secret key's never coming out of those pins again (unless you're a nation state with a tunneling electron microscope and a very steady hand).
(The huge exception is iCloud Keychain and whatever Google's doing for passkey sync, but that's importing from account data into hardware storage, not exporting existing credentials from a user's existing device)
Create a new passkey on the device? Or on the new device? I don't see why this is a big issue. Sure, it's slightly inconvenient to go through the 'create passkey' flow on a new device, but as long as the account you are using (let's say, GitHub) supports storing multiple passkeys per account and managing them online, there's no reason you can't.
For every single one of your 100+ accounts? What if you forget an account when doing so, then it's lost forever? If one of the 100+ websites is momentarily down I simply have to keep the old passkey provider around until it comes back up and then remember to switch just that one later?
Are you using every single one of the 100+ accounts constantly? No? Then you can do the passkey flow on demand as needed. It can be comparably simple as an email login or 'we emailed you an OTP' login confirmation flow. If you never get around to using the account ever again in your life, I suppose you never needed it?
If the website is momentarily down how are you going to access it with a password at that moment? You'd have to wait until it came back up. And then you could just as well set up the passkey.
I think it is true that you can's export passkeys stored in Apple Keychain. However, the statement is false in two ways:
- 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.
Ah, yes, poor choice of words on my part. They are in iCloud Keychain (I think this is required?). But if you only have one device it's basically the same thing, or if you're trying to leave the ecosystem.
Are they not private keys that shouldn't be synced across devices? I thought icloud facilitated automatic creation of passkeys for each device, not actually sharing the same passkey across devices?
That's the crux of one of the debates... members of the FIDO Consortium threatening KeePassXC and other open source tools with blocking for sharing "roaming keys", meanwhile "Oh, Apple wants to share keys via AirDrop? No problem", which is one of the concerns, that it's yet another "push users to Apple and Google's tool of choice".
As I understood it, that's exactly the purpose and not an issue. You are supposed to create a new passkey on each device you have. The fact that they can roam around within e.g. the Apple ecosystem is just some added function that Apple offers.
If I first signup for a service on my iPhone, then want to login on a Linux desktop, for example, how would I login if the passkey is not on my system, and I can’t login on the desktop to say I’m me?
Maybe they sorted all this out so it “just works”, but there seems to be so many potential pitfalls, that I feel like I’d need to spend weeks researching stuff and testing edge cases before I could feel safe using it. No one is going to do that.
With a password, I know it works now, and it will work in 40 years. I don’t have that same kind of confidence with a passkey. Even if it’s great, if people don’t adopt it in mass, it will fade away and be removed, so how deep do I want to go? This isn’t something I want to be an early adopter on, at least not for anything I care about.
> If I first signup for a service on my iPhone, then want to login on a Linux desktop, for example, how would I login if the passkey is not on my system, and I can’t login on the desktop to say I’m me?
What's supposed to happen is when you tell the site you want to use a passkey and one is not available to your Linux desktop's browser you are shown a QR code that you can scan on your phone. The login will then take place via the phone using your passkey that is on the phone for that site.
If you want to test to see if your browser handles this right you can do so at <https://www.passkeys.io/>.
Once you are logged in with your passkey from you phone you should be able to go to your account settings on the site and somewhere in there find an option to add another passkey. You can then add a passkey generated by your Linux browser or your Linux password manager if you use a password manager that supports passkeys.
Some will object that this is not good enough because they might want to login to some desktop they have never logged in from before when they do not have their phone handy.
That's probably not as big a problem as they expect though because unless you are using passwords you have memorized the same problem applies to passwords. I've got over 400 accounts in my password manager, almost all with long random unique passwords. That means I'm not going to be logging in somewhere new to any of those sites unless I've got access to my password manager, which in practice means unless I've got my phone or tablet with me.
You get a link (or more commonly a QR code) that you open from the device on which you already have the passkey to grant access to the new device. Then you add the passkey for the new device.
FWIW I don't think that this makes passwords redundant in general, but with passkeys, password becomes a last-ditch safety valve to regain access to the account. Meaning that it can be generated, very long, and stored in a way that is optimized for safety and security over ease of access (like, say, an encrypted text file on multiple USB sticks stored in different physical locations).
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?
I use 1Password to manage passkeys. It’s pretty nice. They sync across my devices, I can erase one if I need to, and generally with the exception of something odd with Firefox and one website they just work.
Because if you don't want to, it'll get in your way every time you try to use your actual passkey. Oh right, I forgot they added an option - now it just gets in your way every time you try to use your actual passkey on a new device.
Every time I see a long inscrutable discussion about Passkeys, I see a weird avoidance of the "something you know" part of security. Here in the US, courts and law enforcement have every right to get your username, fingerprint, retina scan, face ID, whatever. But they don't have the right to extract something from your brain. Unless I'm missing something basic (which at this point, I don't think is my fault since this whole thing appears incredibly difficult to explain), Passkeys skips past that whole thing in favor of making it a heck of a lot easier to replace "something you know" with "something you have". Which is a security nightmare.
PINs and passwords on HSM keys like this are typically very secure as they will wipe themselves or at least lock themselves after a small number of failed attempts. For example if you only allow 5 failed attempts a 4 digit random PIN has a 0.05% chance of being guessed and a 6 digit PIN is 0.0005%.
So the only real risk is key extraction, hardware key extraction is always possible but likely incredibly expensive, so for most threat models it is not an issue. (Software key extraction or side channels is a different problem which may be easier but in theory is not possible.)
PIN+limit is still a much worse user experience than a password:
- a PIN is hard to memorize, so people are more likely to use personally-relevant or common numbers, whereas a password can be easily be both complex and memorable
- it's easy to burn through even 10 login attempts through any combination of temporary/permanent disability, stress, being drunk, damaged device...
- a wipe-after-failed-attempts system is trivial to abuse, be it by a prankster or a real adversary
- it's much easier to see someone's PIN over their shoulder or film them entering it
Which is exactly where your passkeys can be stored too. Put them in a password manager like 1Password, disable biometrics, and law enforcement would have to enter a password to access them
password managers are growing, but I'm not sure that 'most' people use them. Maybe 'most' software engineers or techies, but the average person probably has no idea what a password manager is.
>”the average person probably has no idea what a password manager is.”
In my experience, that’s a notebook or piece of scrap paper next to the PC with all their usernames and passwords scribbled on it.
That being said, all of the friends and extended family members that I have helped with computer issues have chosen to save several passwords in their browser’s autofill. Yet, none of them knew that they could view and edit these passwords.
Which is a bad idea. Right? That counterpoint defends a bad idea. We should be against the practice of permanently-unlocked password managers, and password managers that are only locked by "something you have". People also create ssh keys with null passwords, but it's also a bad idea and we should be opposed to that.
The State of Utah instructed the jury in State vs. Valdez to infer that a suspect was guilty because he refused to provide his password to the police. On appeal, the Utah Supreme Court ruled that he had the right to withhold his password according to the 5th Amendment, and he shouldn't face negative consequences for doing so. The state appealed that ruling to the U.S. Supreme Court, citing various other state and Federal courts which have made conflicting rulings on this same issue.
Sixteen states (Indiana, Alabama, Alaska, Delaware, Iowa, Kansas, Louisiana, Maine, Michigan, Mississippi, Nebraska, North Dakota, Ohio, Oregon, South Carolina, South Dakota, and Texas) just filed a motion asking the Court to hear the case: https://www.supremecourt.gov/DocketPDF/23/23-1020/307804/202...
Quoting that brief:
"[C]ourts have issued orders requiring persons to unlock devices or provide passcodes. But courts across the country are divided as to whether the Fifth Amendment bars such orders. [...] The Court should grant certiorari to provide guidance on how the Fifth Amendment’s guarantee against self-incrimination applies in the modern context of electronic devices."
Historically, US courts have declared that giving a password is proof that you control the given asset and that this can be incriminating.
In practice, juries will take a refusal to divulge a password as evidence of guilt, the cops will use it as an excuse for even greater brutality, the FBI is perfectly willing to hold you without trial for years on end, and in most cases they don't need it anyway because everything lives on someone else's computer and they're perfectly willing to hand your data over if they haven't already. Furthermore, because the defense is founded on the principle that the password serves as evidence that you owned the encrypted data, if the prosecution is able to prove that you owned the encrypted data in any other way, that protection goes away.
> In Boucher, production of the unencrypted
> drive was deemed not to be a self-incriminating
> act, as the government already had
> sufficient evidence to tie the encrypted
> data to the defendant
I am, of course, not a lawyer. I'm just summarizing easily available information, i.e. wikipedia.
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).
> It seems like we still have some way to go before we figure it all out.
You're 100% right, though I'm actually surprised that so many sites already support passkeys.
If passkeys is a good idea and consumers use them, then gradually sites will shift over. Changing how everyone in the world does auth is not going to happen overnight, or even in a year.
If your only argument is "wow, it's easy", you're not arguing from the perspective of any kind of security.
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.
Honest question, not a critique: what's the point of passkeys if you already use 1password? It unlocks with touch ID both on computers and phones, it autofills and autogenerates username and password. Plus you've got the option to fall back to manual input if you don't have 1password available in a particular device, and credential sharing (outside of 1p) becomes feasible. What's better about passkeys with 1p?
I wish there was a "fast API" for password managers. You can help them autocomplete by using `type` and `autocomplete` attributes in your login form, and there is a "well-known" URL to find the password change form, but I wish there was a way to bypass the HTML page entirely. This would get us 99% of the features of Passkeys I think, where the user only interacts with the password manager's UI.
Also a 1Password passkey user. It is the most portable implementation of passkeys I've used. Still, if you want portability with passkeys you have to trust some company to sync them. I don't want to need to rely on Google, Apple, or Microsoft to sync my keys because those platforms all have some lock-in. Guess 1Password is a form of vendor lock-in too, but it is one I don't mind.
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’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.
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.
People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-)
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'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - instead it's used in a challenge/response protocol (like SSH keys). Which requires software, either the browser or an external password manager, to run.
I think that's what you're getting at in paragraph 3?
There's no reason you couldn't have an open source passkey manager that allows you to backup and view the key if you really want to. SSH works just fine that way.
It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves.
The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
> 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.
This part right here is what I fear the most about Passkeys. I've read too many horror stories of people getting banned from Google (often for no valid reason) and losing access to all of their data. It is absolutely insane to hand over all your passwords to a company like this.
I have been using passkeys for a while in the form of yubikeys
Best practice is to register two keys to every website. Keep one physically in a safe.
With password managers I would say the same basic practice applies. Make sure you have a working offline backup of whatever secrets you hold dear.
There are some sites that only allow you to register a single passkey for an account (AWS Console last I checked) but these should be getting fixed as it becomes more popular
> 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.
There are so many apps that don't get this right. Make a login on the website, store it in 1password, and then try to login in their mobile app and it doesn't show up as a password because the associated URL is mismatched on the mobile app. Like mybank.com and auth.mybankmobileapi.com
1password has a URL field. All you have to do it add the extra URLs
Better yet, while on mobile, search for the entry of the desktop site and have it fill. 1password will ask if you want to update the entry for this site
I have been using 1Password for over 15 years and it has the ability to only show/fill passwords when on the correct site. The issue is, over time, companies shift their strategies on the web. URLs change, while the accounts stay the same. I have had to update these details many times. I've also run into situations where the browser plugin isn't functioning, for whatever reason, and the only way in is to copy/paste. There are also times where I'm not on my computer. For example, I usually piggyback on my dad's copy of TurboTax each year. When I'm over there, I will often need to pull up a password on my phone and type it into TurboTax as it logs into my bank to download the tax forms. Passkeys don't sound like they can solve that problem. I'd question if the Passkeys would work in TurboTax even if I was running it on my own computer.
With passwords and logins, it seems like there are far too many edge cases to draw a hard line to say they are locked in the password manager forever. Having a way to copy it out, or export, is also a way to ensure portability, if the password manager being used ever becomes bad and a different option is needed.
Password managers put users in a vulnerable position, as once a user is invested, they've got you by the short hairs. The thing that keeps this from being a big problem, is that there is always a way out. Eliminating this way out, or raising the barrier to exit, can temp these password managers to extort their users, which is not good.
This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in.
You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey.
It’s a different mental model and the key is in the name. Passkeys are like keys. You can have more than one.
It's not a problem of mental model, it's a problem of scale. If I'm switching phone, the last thing I want to do is to go to every website I have an account on and essentially do a second sign up. This is simply a non-starter, and is a big part of why companies like Apple and Google are pushing for this spec: it nicely ties you in to their ecosystem and gives you a huge reason not to move to a different ecosystem.
I use selfhosted vaultwarden [0] instance (its a rust implementation of the bitwarden server), and the bitwarden apps (i point the apps to use my server instead of bitwarden).
Vaultwarden + bitwarden client apps (for desktop/browsers) have passkey support, and i've been using them for a month or two without any issues.
That being said, bitwarden client apps for android and ios are going through a rewrite (from xamarin to native iirc), and are yet to support passkeys. However, the bitwarden folk said passkeys are the next feature coming to these apps.
Bitwarden, which you can self-host (I do this) seems to have at least partial support now, and I know they're working on improving it. However, I'm not sure if their client and server are both fully FOSS.
... with some of the functionality of SSH keys removed, like being able to use one key for many accounts, or many keys (on many machines) all for the same account.
> there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy
This is a deep, fundamental flaw in passkeys. It's just another example of enshittification disguised as denying end-user control "for their own good." There is no for-profit organization anywhere that I trust more than I trust myself, and there's no threat model where it's more likely I'll be socially engineered into giving up my long random password than that I'll suffer data loss.
Good for you; I'm ashamed to say that I've hurt my data sanctity far more than any criminal has, with 2am tinkering with my systems.
I have vaultwarden at home but I don't use it because I just know I'll fuck up my tunnel while I'm travelling or something.
This is my threat model: "hi mum. I need you to drive to my house and fish a keyboard out of the cupboard. Plug it into the big black box and type exactly what I tell you..."
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.
> 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.
It's my understanding that you can't switch password managers without generating a new passkey for each individual service you use (I'm not an expert here, so someone feel free to correct me). That's already enough for me to not switch.
This is why, for me, the problem is not the passkey model per se as much as it is the inability to export/backup/convert my iCloud Keychain database to another account or platform. Apple could arbitrarily delete my data or lock me out of my own account. Or it could just randomly break with no solution besides deleting the database and starting fresh. And according to the author, this has already been occurring!
>Externally there are other issues. Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.
That’s my problem with TOTP second factor authentication. I’ve used Authy for years because it works on Windows and mobile, but now they’ve decided they aren’t going to work on Windows anymore (but they still force update a perfectly working Windows app and there’s no way to opt out). I have no way to export my 30+ TOTP accounts to a new system. I often don’t want to have my phone around when I’m trying to focus and get work done, but now I have no choice. It’s infuriating. Is there any cross-platform TOTP system that has the ability to export your keys? Is that even a thing that’s technically feasible?
> I’ve avoided passkeys so far because I just don’t have a good mental model of them.
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.
> "and use fingerprint/faceid instead of a password"
This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now?
Security guru Bruce Schneier has written about this w/ much more eloquence and authority.
The fingerprint/faceid is just a local proof to unlock the actual asymmetric encryption key. It is not your actual identifier to the remote server. So if you need to redo your auth, you just rekey and stash the new key in your authenticator (or have your authenticator originate the key material and never expose it to main memory at all).
Think an SSH key protected by a passphrase. Your passphrase isn't the thing that actually logs you into the server, its just what you use to unlock your actual key material you use in your SSH handshake. Your fingerprint/face identity is just your local unlock of the actual key material stored in some other secure enclave.
The biometric stuff is simply allowing access to the keys. It’s not being used for anything else.
Your face or fingerprint being out there isn’t a concern because that’s not, ultimately, the thing being used to generate the keys or anything.
It’s an ease of use function.
On iOS for instance, as I understand it, these are being stored in iCloud Keychain. Which has a password. The derived key for iCloud Keychain is stored in such a way that the system has access if you allow biometrics to be used.
Biometrics then simply allow access, in essence, not part of the encryption process. The password for iCloud Keychain is necessary to add those items on a new device. Your biometrics aren’t stored by Apple anywhere other than in the device.
Honestly I am blown away how few people on this site understand how this stuff works. It’s fascinating and I’m surprised more people aren’t interested in understanding it. But so many people assume the biometrics are being used in the encryption process and that if your face is somehow stolen your whole life is doomed. These features have been on Apple devices for what.. a decade almost at this point? More? The process for Face ID is the same as Touch ID. Developers make zero distinction between the two in code, as that whole process is passed off to the system and effectively results in a bool value (or access to the secure item requested). At no point does a developer ever get your biometrics data.
I don’t know how Android or Windows do it but it is similar enough I suspect.
The FUD around passkeys feels like some sort of propaganda campaign to discredit it.
This is the part where you have people dismissing a security from a simple assumption and reverting back to another assumption of their current state. Is still dangerous
Your fingerprint/faceid/whatever is used to access the passkey. It is not the passkey. To that end, yes, if you are worried about clandestine access to your phone (if that is your passkey), then you probably don't want to allow access using fingerprint/faceid. And if someone can copy your passkey off of your phone, you are again compromised.
Your faith in humanity seem low, because this would never be pushed worldwide by security experts who eats and sleeps it, if it was so easily broken where you just figures it out during a comment
This sounds, to me, like a really bad and convoluted way of storing pub/priv in a password manager, and hoping the software implementation gets it right when it's trying to manage these things for me because I'm too dumb to manage passwords and too hobbled by bad IT policies that want to change my passwords every 4 weeks.
Eh, somewhat. The lost key account recovery story is much better in large organisations, where you have a 24/7 helpdesk that can check your ID badge in person, a HR department with a photocopy of your passport, and suchlike.
But for example if you're using Azure/AD? No U2F + Password allowed, gotta go straight to "passwordless" [1].
So they never took off far enough for Microsoft to support them.
The big question I have is are the keys device/browser specific?
Seems to me I need to be able to log in with a password from any place (my phone, my machine, my office, my wifes phone, her laptop, my friends laptop, etc.).
I mean, who knows when I'll want or need to get into Something.
Also, my wife and I share accounts (such as Amazon). So, it needs to work seamlessly across all of her devices.
Then there's always the "F-with it factor" that I loathe. At least I understand passwords. Can (mostly) always recover a password (I recall trying to recover my Apple ID password -- they bluntly said "ok, but you have to come back in 2 weeks", so I was locked out for 2 weeks).
And, of course the level of patience my wife has with Technology is less than zero.
I rely on my Safari auto fill, when I use another browser, I just copy the pw from Safari.
And I don't use any of the cloud services. I have an iPhone, but don't use iCloud.
A few weeks ago, I was unable to log in to Google on a new device with my 2FA token (Yubikey) because Google insisted on authenticating with a passkey/resident key, but the token had only been set up with non-resident TOTP or whatever it's called (and had been working properly in this mode for over a year). I was able to log in on another device and register the Yubikey with a passkey/resident key, but it was really scary! There is so much complexity here, and so little visibility and control afforded to users, that I feel very uncomfortable trusting it as my only login method for any moderately important service.
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.
It's a Google sign-in workflow problem. I've seen the same issue more than once - for whatever reason it decides that this one way of signing in is the one that you want to use right now, and it can be impossible to back out until some timeout kicks in.
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)
It's still not a great multi-platform/multi-device story. I use multiple machines regularly (and I've migrated away from 1Password to the KeePass ecosystem, by the way) so syncing passkeys from my Mac(s) to my iPad, to my Fedora machines and my Windows working environment is simply not happening any way I look at it.
Passkeys are great for consumers who use one or two devices (or browsers - I also switch browsers frequently). For anyone with more than one platform or one device in their lives they suddenly become added complexity, because even though you _can_ have more than one passkey per account per service, in practice there are all sorts of weird edge cases.
You shouldn't ~~necessarily~~ need to "sync" your passkeys across all your devices; each device should have its own passkey. Then if you lose a device (or that one device gets compromised), you revoke the one key and everything else is fine.
Similar to SSH keys. No reason to use the same key on all your machines, use a different key from different places.
The passkeys on my laptop are different from the passkeys on my desktop which are different from the passkeys on my phone which are different from the passkeys on my main yubikey which are different from the passkeys on my backup yubikey.
Edited due to acknowledging people may choose a variety of alternative workflows.
I've installed KeePassXC on my Mac and Linux machines and it stores Passkeys. Low-tech syncing is by Signal Notes to Self. If there were an audited app for iPhones I'd still be using that method; there isn't, so I've moved to Bitwarden. Passkeys seems to work fine on Bitwarden.
I currently use the 1Password passkeys, and when they work, it's pretty good. I get all the fun of showing up on a website, and with three clicks, I'm in. But I've used them on just a few websites (email and GitHub), and they work correctly maybe 10% of the time.
First, I had to figure out how to get the website to request the passkey. Then I had to figure out that I didn't want to use the browser's passkey but 1Password's, which is different on different browsers and platforms. And good luck if I'm on mobile, I don't think it's ever worked.
At this point I'm taking a break from signing up new passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).
PS: Why is it that no financial institution lets you use anything more than a SMS U2F?
How do you back up the private key? With ssh I know to back up .ssh with the rest of my home folder. With a passkey I'd have no idea where it was, and get the feeling the "modern" software won't tell me on purpose, so that it can manage/sync it for me. Which leads to a lack of a mental model.
Nice phrasing, I lack that mental model as well. Anyone here willing to distill down the whole thing to a few sentences? Who stores what kind of secret, and is there some kind of challenge/response at auth time?
A physical device which is not your computer stores some secret information which can authenticate you. This can be passwords, passkeys, GPG keys, your retina etc.
The physical device can be password protected. So you have two step authentication:
1. your physical device
2. your password to that device
Phones are currently being promoted for various reasons, but I believe something like Yubikeys or other FIDO2 fobs will be a better device. You can have multiple of them, you can store one of them in your bank safe. Someone stealing it of you is proper theft which can be traced in a usual manner by police. Stealing is not enough because you still need the password. The difficulty of asking you for password remains equal to difficulty of hitting you with a wrench. You don't need to remember stuff anymore, because you can just use your physical keys. You will need to travel with those keys, but its just same as your house keys. It is probably an extra key in your key fob.
To add to it, the U2F/FIDO2 standard will make it vendor independent, and so no lock-in.
What I find rather confusing is what happens on each device. There appear to be multiple places where passkeys can get stored (iCloud Keychain, Google account, Chrome profile, Bitwarden, ...?) and depending on where it's stored it may or may not get synced to various other devices, browsers and apps.
So my problem is that I keep forgetting which device, browser or app I used when I created a particular passkey. I'm never asked where I want to store a particular passkey and where I want it to be available. This is all an implicit function of a combination of factors apparently.
It's like misplacing my keys has been taken to a whole new level of abstraction :-)
Safari on macOS uses passkeys without phone. So unless you consider security chip inside macbook a separate device, that's not true, that's just one of modes.
Thanks! A bit late to the party, but if you still see this, I presume the authentication exchange between the web server and the device is some kind of challenge response? And if so, does the challenge/response depend on the type of credential that's in the device?
Back when I implemented webauthn for the first time I remember the interactive tutorial webauthn.me provided by Auth0 was very helpful in wrapping my head around the process.
Most important feature imo: The effective "password" being sent over the wire is essentially some hash(secret, uri). Think about the consequences for phishing!
Nice to hear I'm not the only one. Part of the problem is that it's always presented post-login when I'm already in the middle of doing something. And my password manager works well, so I don't see a clear benefit and I'm not really motivated to investigate vague claims.
I agree, plus the added abrasion from passkeys being implemented inconsistently and seemingly in a way that promotes vendor lock-in. Do I need a different passkey for my iPhone and an android tablet? Do I need a different passkey between iOS devices? Why does this service allow me to use a passkey in Bitwarden, but that service doesn't? These are all questions I've never had to ask about a complex password in a password manager.
The primary advantages of passkeys are phishing resistance, uniqueness per site, and breach resistance.
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.
>All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.
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.
Yes but what I'm still confused about is that:
1) Is one/some of your public key reused on different services
2) Or is there a different public key for each service
1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password
2) In the second case when one service is breached you'd still have to manage rotation of public key somehow, how trivially is that done with current implementation ?
>2) In the second case when one service is breached you'd still have to manage rotation of public key somehow
Why would you need to rotate your keys? If they're storing passwords/hashes it makes sense to rotate because they might be able to brute force the hashes on a GPU cluster, but you're not going to be able to brute force a randomly generated public key.
The whole point of a public key is that it is not secret. A breach where a service leaks the public keys of its users does not harm your security posture at all.
The problem Passkeys (and FIDO2 and WebAuthn and U2F) solve is phishing. The core concept is mutual authentication: not just you to the service, but the service to your authenticator.
Totally agree. I have used fido2 and webauthn before and I liked it. Particularly with a hardware key the mental model is quite straightforward. Now with that Microsoft, Google and syncing business I am left totally confused. Why the hell should alI store a private key in some cloud?? What happens if that provider decides to terminate my account, if it gets pressured to release the key? Also how does this all work with Windows Hello and other things in between??? I know a bit of crypto and security protocola but the passkey concept and possible attack vectors totally escape me.
I agree, framing it as a mental model makes sense.
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.
What the parent says. I'm hoping this HN thread will help clarify this.
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.
They’re basically an advanced username/password that’s automatically generated by your device. I believe one of the benefits is they require an encryption component that is known only by the devices that you own. This is better than a password that’s stored on a server and can be lost.
It is a different technology with some different edge cases so I wouldn't call it a rebranding but in the broad scope yes. The problem with this stuff was always the integration, not the tech.
The mental model is very simple. If you use things like Yubikey, it is exactly like a key you use to start your car. A single password protected key maybe. In essence, it is your password manager but something that everyone can use. And something that doesn't need to be on the cloud.
It is like a key to start your car, except you can register it with multiple cars. And it has 25 or so "slots" for car registrations. If you lose the key, you cannot order a copy from the car manufacturer. You also cannot make a copy yourself. But you can (usually) register multiple keys with the same car. You do this by plugging two keys into the same car, and the car learns both keys belong to the same owner. You just have to be careful and keep track of which car is registered with which key, and vice-versa. Sometimes the key will not work with a particular car. Also, after you plug in the key, the car will not start right away. It will first ask you to select which key to use. If you use Bitwarden, it may hijack the key insertion interaction and will offer to use its soft-key instead. So, some small differences ;-)
Well that doesn't help understand: How passkeys can be backed up? Where/how they are stored? What if I loose my phone, computer? How can I login to some app using pc/mobile?
I haven't been into passkeys as you see, but some easy login like that leaves me with a lot of questions.
The TL;DR version in my opinion is that passkeys are quite similar to a SSH key pair, like one you'd use on GitHub. Basically you generate a key pair, the server stores the public key, and the client stores the private key. When you want to authenticate, the server sends a challenge, you sign it with your private key, and send it back. The main debate is over how to manage those keys after generation.
- Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.
- Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up. So the passkeys are stored encrypted on disk, and the decryption key is stored in the keychain/keystore. Other options include passkeys actually stored in hardware (eg. Yubikeys, but then you can't back them up) or 3rd party password managers.
- Login: It's pretty seamless, just click "login with passkey". The browser handles finding the right passkey, and part of the signed challenge includes the domain the passkey is for, preventing MITM-style attacks. There's also a whole separate thing for authenticating a session on a different device via scanning a QR code or Bluetooth.
I reread your analogy a few times, and while I think it's probably accurate, there is absolutely nothing simple in it. It reminds me of the "It's like Uber, but for mortgage insurances" kind of startup pitch. It perfectly encapsulates the concept, but the concept itself is just crazy niche.
To note: the key to start a car is provided with the car with no specific operation, is locked to no other device, doesn't care about who's handling it, can be duplicated and passed around. It would be closer to the traditional password system in all of its aspects IMHO.
I think I'm a tech guy and know my fields. I still have no real clue how passkeys work, how it is better, what it really is.
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?
SSH is nice because you don't have to think about it. Your private key sits in your .ssh folder, and then everything is transparent. You _can_ put an SSH key in a smartcard if you want, but you have to opt-in to this kind of pain. And even if you do, almost all SSH servers will support that login method without issue.
Passkeys don't sit in your .passkey folder. Your browser doesn't look for passkeys in a standard folder at all. You don't just do passkey-keygen like you would ssh-keygen and forget about it.
Websites might support various combinations of FIDO/U2F/TOTP security keys, your USB security key might support various combination of FIDO2/CTAP/WebAuthn, and the user will be left confused what any of this mess means, why there are so many competing standards, and why they're asked to scan a QR code when they plug in their dongle, and it doesn't just work at all.
Passkeys ought to be exactly like SSH keys. Unfortunately, they are not.
The attempts to restrict when and how they are stored, and how you can access them - those are going to cause a lot of pain and confusion.
I have all of my SSH keys stored in KeepassXC, which (imho) is a lot more secure than having them hang around in my .ssh directory. Open KeepassXC, and the keys are available. Close it, and they're gone. Synchronizing the KeepassXC-file across devices means that I have access to the keys on all of my devices.
The big companies pushing passkeys are trying very hard to prevent this kind of convenience.
For me that means having multiple keys in `authorized_keys` for the same user and never transferring private keys between devices. From what I gathered from the discussion here, this is not a given.
Why would you want to? Just create a new passkey on the other machine. If you're saving them in a password manager, just create a new entry, "Another Machine's Passkey."
Usernameless always seemed like an optimization too far to me.
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.
> Usernameless always seemed like an optimization too far to me.
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.
No, your person is your identity. Passkey don't pay for services, people do. So there is always a recovery process, at least for any business that actually values you as a customer.
No, that's like having only one key to your house.
If you have two passkeys from different providers, they serve as backups for each other. And there are other alternatives, like a printout of recovery codes.
I've never tried to use passkeys, but determined a while ago my hard, non-negotiable, a priori requirements which would have to be met for me to be willing to use them:
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.
2. I can disable any attestation functionality to do my part to prevent
any online service from making it mandatory.
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?
> I can backup and copy a passkey without restriction ...
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.
I wish Yubikey allowed users to import their own FIDO2/webauthn seed and overwrite the factory generated one, and then also allow the resident passkey functionality to be disabled.
It should be up to the user if they want to have multiple duplicate hardware authenticators and be able to backup their seed however they wish.
Firefox and Chrome display a permission dialog when a website requests attestation, and you can deny it. If you deny it, the website has no idea how your passkey is stored, allowing you to use a pure-software solution if you so desire. The website could discriminate against you for denying attestation, but note that Apple always denies attestation for passkeys, so websites intended for the general public are unlikely to discriminate against users who deny attestation.
So yes, I believe your requirements are met in practice.
1Password includes Passkeys in archive/exports of the 1Password database. Safari developers have stated that it is a planned feature to support Passkey exporting (but not currently supported) including between apps.
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.
As someone who happily uses Yubikeys, I really don't want to use a Passkey. I want to still use a username/password and the Yubikey. Not just username and Yubikey.
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.
You can open your Firefox about:config and set security.webauthn.ctap2 to false.
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.
Because of the whole "multi-factor" thing, and not making account recovery impossible?
Passkeys are always going to be less secure than username + password + Webauthn, why would you intentionally make your account less secure and give yourself a massive failure mode in the process?
Password and other factors are not going anywhere. You can set password, TOTP, email, phone and passkey at the same time. And use passkey because it's convenient. But use other combination of factors, if you need to access website without passkey. At least if website owner allows it. But I think that most websites will allow it.
Account recovery is a separate issue. There's nothing about a pass key that makes account recovery any harder or easier than if someone loses their MFA TOTP device or forgets their password.
You can (and are generally required to unless you purposefully use a "non-compliant" implementation that ignores it) set a PIN on your passkey.
> Passkeys are always going to be less secure than username + password + Webauthn
It's less secure in the same way that a door is less secure if you put a single strip of duct tape across that same door. Technically yes, but not in any meaningful sense.
If you use Google Workspace you can set 2FA directly from the admin console, so you don't need to disable FIDO2 on the key. Does not help with gmail, though.
Not in my experience. In the Admin console I said do not use Passkey and it still created it as a Passkey :( This was about a month ago, so maybe they fixed it. Turning off FIDO2 made things work.
If you add a FIDO2 key as a security key in the admin console, it will show as a "passkey" in Google account settings, but it will actually be a non-resident key used only for 2FA and won't be able to be used for anything more than that.
Keys that do not support resident keys (or when you turn FIDO2 off) show differently in Google account settings which makes it all very confusing. The UX is inexcusable, really.
As a side note, turning on Advanced Protection also turns off passkeys.
> But of course, thought leaders exist, and Apple hadn't defined what a Passkey was. One of those thought leaders took to the FIDO conference stage and announced "Passkeys are resident keys", at the same time as the unleashed a passkeys dev website (I won't link to it out of principal).
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.
> At this point I think that Passkeys will fail in the hands of the general consumer population.
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.
They're a consumer capture mechanism insofar as password management tools are, and we want users to use those because they make security tolerable. The problem is that it turns out the OS vendor was in the best place to win the password management game.
The lock-in situation with passkeys seems far worse than with password managers, though. There is no "export" option for iCloud passkeys - despite being cloud-synced across your Apple devices.
If you decide to switch from an iPhone to an Android phone, you're looking at an arduous process of enrolling a new passkey for every single site.
Just you wait for governments to require platforms to only accept gov-signed keys.
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.
not to diminish your point, but since at decade or so I'm a more worried about corporate surveillance capitalism than I'm about government surveillance.
Why? Governments can do so much harm by incarcerating, fining or even killing you.
Don't get me wrong - corporate surveillance can be very annoying, especially in insurance / credit scoring / price discrimination etc, but it seems a comparatively lesser danger.
I mean, same, but only because I realized a new undesirable thing was becoming a tacit reality that we'd have to accept on top of already undesirable thing
The part I hate most about Passkeys is that it essentially killed the FIDO1/U2F ecosystem.
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?!
> 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.
Passkeys are a godsend when compared to weak passwords and SMS 2FA. Try to think through how to protect a bank account or retirement account for the average consumer, some banks send you a OTP and have you read it back to prove who you are when you call CS, some think the OTP is sacrosanct and will never be read back.
I 100% agree with you but there has to be something for regular consumers to safely log into a website that may have 10s or 100s of thousands of dollars on the other side of it, and be secure.
For folks who don't know how passkeys work at a technical level, take a look at this implementation guide: https://webauthn.guide/
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.
I don't believe this is necessarily true, as far as intent goes. I think Apple and Google focused on a core use case, shipped it, and subsequently lost interest or fired everyone involved.
Unfortunately, this scenario is indistinguishable from one in which they deliberately mishandled the specs in order to lock in users.
Thanks for your faith. I work on the team shipping passkeys at Google. We are very much hard at work to realize the full potential of passkeys. Platform lockin serves no one. That is no one's intent - independent password managers storing passkeys is already a thing today. More interop will come once relevant standards are blessed.
You can absolutely do public key challenge authentication with passwords. You can use argon2 to derive the secret key for your account from your password and use that to encrypt a challenge message
Passkeys can't actually replace passwords, right? I will always need a username and password with a website, then can generate a passkey as a separate auth mechanism, which if I lose, I will recover by setting up again using my username and password? I don't get how we can get to a place where passkeys are all, how do you get a passkey on a new device when you only have passkey auth on some other device enabled?
That's not the idea, no. The idea is that - instead of a password - you have a cryptographic key. Like an SSH key. This key is managed for you, so you never have to see it or type it. You ought to be able to either have just a few keys, or else a different key for every service you use.
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.
Both iOS and Android sync to other devices in the same ecosystem, so there is at least a limited form of device portability.
If you have both, register two passkeys with each account and that's even better, since they back up each other if the vendor somehow deletes your account.
Wouldn't transferring the keys around just massively increase the attack surface? There's a security reason why we want them stored on-device and never moved, right?
Think of all of the password leaks you've heard of. How many were due to syncing password vs password reuse, poor site security (e.g. storing in plaintext, weak encryption, etc.)
I'm not saying syncing is 100% secure (nothing is), but for most people it's not the main attack surface to be concerned about.
The KeepassXC file is encrypted (granted, only with a password). Sure, that file is now on multiple devices, so somewhat more vulnerable.
The problem with storing on-device comes when you use multiple devices. I have three devices (PC, laptop and phone) that I use regularly and interchangeably. What am I supposed to do, if the keys are tied to a single device? Worse, what do I do if that device dies, or is stolen?
This is how I'm using them. Still have a username/password, with a passkey as an additional factor. I use 1Password for passkeys rather than Apple's solution, which enables me to use them wherever I have 1Password.
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)!
A long recovery code that both you and the provider need to know in order to authenticate you IS a goddamn password no matter how infrequently you expect to use it. It just changes what knowledge a hacker looks for either in your digital storage or in a company's databases.
If you get rid of all knowledge-based authentication in order to increase account security, then you necessarily increase the chances of permanent lockout. You can't square a circle.
As for phishing, maybe google should put its AI capabilities to good use, and if the text of an email matches enough patterns of examples it's seen before, there should be a banner at the top of the email warning "this looks like a phishing attempt: common tactics include X, Y, and Z. Confirm authenticity before reacting to this email."
I don't think you know what phishing means. By "dropping malware on endpoints" I think you mean having a website serving malware? That's not phishing. For an attack to be "phishing", the website needs to be pretending to be some other website that the user trusts. Passkeys completely prevent the user from logging in to another website than the one they've created an account with.
Your attack only works on people who basically "trust any website" at all. For those, yeah there's no salvation.
Platform as in "ecosystem". iCloud Keychain, Google Password Manager, Bitwarden, 1Password, your Yubikey. Anything that can store passkeys.
If you want to use both you simply enroll both your PC and your iPhone. There's nothing stopping you from doing this. You can register multiple passkeys from different providers to the same account.
You can also log in to your PC with your iPhone by scanning a QR code. And then afterwards enroll your PC as a secondary passkey.
Did you know that you can turn every $2 Raspberry Pi Pico clone board into a FIDO2 stick, and even make it Yubikey compatible?
https://www.picokeys.com/
Well, not as secure as a commercial key, because the Pico doesn't have encrypted storage, but still much more secure than login/password.
I still use Keepass (well MacPass) and naively "cache" what I use regularly in Keychain because I completely distrust anyone else handling the keys to my castle. Whenever I get a Passkeys notification it's an irritation as I don't actually see what the supposed benefits of this are and I'm not really interested in changing how I work. Just feels like I'm being dragged into something complex I will never be able to escape.
If you’re asking in earnest: For the majority of users, Passkeys offer a pragmatic alternative to passwords that is far superior in terms of security.
For you, based on what I’ve read in your comments, I would say that Passkeys are the first workable alternative to passwords. They are built on WebAuthn which (roughly summarized) was the standard developed by Google and Yubico in direct response to the Operation Auora attack.
While the Apple/Microsoft/Google implementations of Passkeys likely won’t meet your personal standards, they’re built on a proven and well designed open standard. Which means you can benefit from the technology without buying into a corporate ecosystem.
I've added a few passkeys to 1Password. It works pretty well on github.com, and sometimes on google.com. But apparently, passkeys.io bypasses 1Password and asks the OS for passkeys? So passkeys.io doesn't actually work for me, unless I want to store the passkey in the OS keychain. Which I don't, because I don't want to be locked into that.
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.
Hey, founder of Hanko.io here, we run passkeys.io. That behaviour is not intended. We've recently changed the demo to require authenticator attestation on passkey creation, that may have an impact on authenticator selection. But a quick test on my system (macOS, Chrome) resulted in the 1Password UI intercepting the "Create a passkey" flow - as expected. It would be awesome if you could help us understand why your experience is different.
With that being said, we are not happy with how password managers have implemented passkey intercepts, but ultimately that's a decision the user can make, as it can be disabled in the browser extension settings.
My assumption is that there's no proper browser API for third-party passkeys, so this extension probably monkey-patches website JavaScript which is not reliable.
Paypal has a really obnoxious failed implementation of passkeys where if you have totp configured, their login flow takes you to TOTP after your passkey auth.
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.
The problem with passkeys, beyond the painful UX that will scare any casual users away and the fact that they are being wielded as an extreme vendor lock-in mechanism is just that the design and implementation is so over complicated with second system syndrome.
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've had Apple silently delete music from Music when I had iTunes Match, and I've stayed paying for Dropbox despite wanting to use iCloud, which would be no extra cost for me, because their mechanisms for dealing with conflicts are different - Dropbox saves a version with "Name's conflicted version 2024-04-26" in the filename, whereas AFAIK iCloud silently decides what to keep and drop so you can't manually decide how to merge a conflict.
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.
Passkeys only encourage the need for a password management tool, which is funny because if everyone had password management tools to begin with then we wouldn't need passkeys.
Passkeys still protect you from additional things that password managers don't protect you against:
1. Your credential can't be phished as it's cryptographically bound to the domain. You could stil be tricked into entering your password and TOTP into a malicious website.
2. Your credential can't be leaked by sloppy servers as it's public key crypto. This makes your security not depend on believing the website your logging into does proper password hashing and doesn't accidentally log password in plaintext.
Most password managers tie credentials to domains. In fact, this is a good indicator of possible phishing attempts when your password manager doesn’t offer to auto-fill your expected credentials.
True, the technical aspect of passkeys does that. But in practical Apple and others want to heavily push for the smartphone as that tool, because it locks people further into that system.
> Passkeys only encourage the need for a password management tool
The dependency on a password management tool.
Be it Yubikey or Apple secure enclave or whatever, it's a shit piece of hardware that will eventually break. Have fun replacing all your credentials at the same time when your phone dies.
This is quite concerning, because I've recently started a project that uses webauthn-rs. I want to minimise spam on the project while I don't want to collect PII like emails for login.
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).
I just went through the dance of logging out of all my google accounts and then logging back into them. While I was doing that, I added passkeys as a security layer.
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...
It's Brave, the browser is responsible for handling the WebAuthn (or alternatively, the Bitwarden extension for Brave, assuming that Brave exposes some API to extensions which Bitwarden has not implemented correctly)
No, I don't want to be tied to a single browser for my passkey, what happens if I want to log into a site on my phone using safari or chrome? I also don't want it tied to my apple keychain. What if I want to share my passkey with my partner?
lol it’s a passkey… why would you want 1 that can be shared and… lost you just register another one
Being like “I don’t want to add another passkey” is really a semantic issue what exactly is the difference to you or adding a passkeys to an account vs copying a passkey to another device except the fact that if you can copy it/share it… it’d be far less secure with more ways to leak
I like the idea of Passkeys, but the implementation of them being exclusively tied to my super account of Apple or Google makes me very cautious. I’ve read too many stories about automated systems killing someone’s account and the resulting havoc.
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.
> "If you really want passkeys, put them in a password manager you control. But don't use a platform controlled passkey store"
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...
Honestly, I think a big part of the problem is that passkeys have been tied to hardware devices and they don't have to be. A passkey is just a public key credential, and it can easily be provided by software as well as by hardware. You would still get many of the benefits (better UX, automatically secure, prevents phishing) and the overall customer experience could be a lot better. Imagine if passkeys could be saved, transferred, and imported as easily as a PDF. Instead, we get a bunch of walled gardens where Apple/Google/Microsoft/etc are trying to be the only provider you use.
I gave up on passkeys after running Google's passkey demo and getting started example. They impement session expiration client side only. I reported it, but they said it had been reported already and they didn't intend to fix it. Seems a little careless for a tool promising improved security.
I've noticed a few websites I frequent have quietly started using passkeys (or something very similar) outside of the normal channels. My bank now asks me to go through a second factor on my phone app that seems very similar to how passkeys work and Outlook has a similar login flow but with an additional 2 digit challenge code for some reason.
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.
Somewhat related: last New Year the company I work for gave us, the employees, presents. Something I assumed to be a USB disk. Couple weeks ago I had to migrate from my old personal laptop to the desktop I finally put together and needed a USB key to put an OS on the new computer.
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.
Bitwarden now official released passkey support on mobile app on iOS/Iphone in Version 2024.4.2.
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.
The solution to most of the author's criticisms lies in not forcibly mixing Passkeys and WebAuthn-based 2FA.
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.
Oof, the Passkeys ecosystem is incredibly complex. Even as someone that deals with it day in and day out at $CURRENT_CO, it can be a headache.
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.
I am exploring this now, actually got 2 students doing their thesis on this. It's very complicated and unnecessarily so.
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.
Definitely this. I think the worst aspect of Passkeys is that the noble goals (public key crypto! unphisability!) seem to somewhat unavoidably wipe out one of the--in hindsight--really valuable aspects of passwords-in-a-password-manager:
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.
I've been using Passkeys saved in 1Password, I thought that gave me the power to transfer them, but I just looked and apparently the export feature of 1P doesn't allow exporting the Passkeys, it just tells you you need to create new ones in your new password manager, so that's pretty crappy...
Yeah I agree. I am familiar with crypto and public key authentication and password hashing and so on, and I cannot follow all of the terms and use modes. To the average user it's going to be a complete black box. They won't have a clue what's going on.
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.
Yeah, unfortunately passkeys are confusing and the UX is generally fucking awful. I hesitate to just blame the tech companies for being greedy, as a result of my experience with passkeys I'm starting to wonder if maybe they've legitimately just lost the skills and knowledge necessary to actually make usable software.
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.
FWIW: MacOS and iOS allow third party password managers to ingrate directly into AuthenticationServices and list passkeys in the native passkey UI through a "Credential Provider" extension. And it's documented how: https://developer.apple.com/documentation/authenticationserv...
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 :(
> 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 mean, I kind of understand this; they're going to have to do the WebExtension either way, since there's no standard API across platforms.
On the other hand. They already integrate with this API for their iOS app as it's the only way to do password autocomplete on iOS. Why not extend that use to MacOS?
You can have multiple passkeys (using different devices or passkey providers) for a single site too. You don't need to fall back to another login mechanism.
> Within enterprise there still is a place for attested security keys where you can control the whole experience to avoid the vendor lockin parts. It still has rough edges though.
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.
Just wanting to get rid of "passwords" means getting rid of "something i know" as an authentication factor. That should not be the goal. The issue is that the other authentication factors have real drawbacks. It's tradeoffs all around.
'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.
There is no auth panacea. There's too many different use cases, too many players involved. You cannot create one "thing" that solves all the problems for all the people. It was hubris.
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 am fully invested in the Apple keychain ecosystem, I’ve got multiple Apple devices (laptops and a phone) and passkeys have been incredible. Haven’t seen any of these issues.
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.
How about we stop reinventing the fricken wheel every 3 years and let users adopt something? U2F keys were pretty danged good and they were easy to explain to my 70 year old parents "This is like your front door key to your house, it's a physical key to your Google account".
I use iCloud's Passkeys extensively and have never had saved Passkeys "wiped out". I am not disputing that data loss bugs can happen, but three times for one user sounds pretty weird given the maturity of the ecosystem.
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?
It's not hyperbole. I recently (few weeks ago) got locked out of my GitHub account after iCloud Keychain thrashed my passkey and after analyzing the root cause it turned out to be a bug in webkit (that is now fixed in Safari technology preview after me raising it with the Webkit team)
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.
One thing that comes to mind is with the earlier WebAuthn implementations in iOS, before they were stored in iCloud and called passkeys, there was no management interface for stored passkeys and 'clear website data' (to delete cookies etc.) would actually erase all credentials permanently. It was useless this way.
I do not mean passkeys in general but early iOS implementation was useless since it deleted passkeys along with your cookies and other website data. The passkey iOS implementation is useful in its current form.
You generally enroll a passkey for a single device or connected group of devices. My icloud-syncing devices has a passkey. My windows laptop has another. My desktop has yet another. I have also enrolled my yubikey.
I could stop using my idevices tomorrow and not be negatively influenced.
I can't speak for OP, but for every service that I use passkeys with I enrolled both iCloud Passkeys (for convenience) and several YubiKeys (for portability and backup).
This is not different at all from a SSH public/private key combo. You are not supposed to duplicate SSH keys!
Your answer is totally reasonable, but I admit I don't have time for that in most cases.
1. Most services are not Passkey-only--most people are using it as a password alternative (e.g. eBay) or a second-factor alternative. So losing it won't lock me out.
2. A very small number (e.g. Google) let you configure Passkey as your sole second factor. For those, I am indeed careful to do what you do and have duplicates.
I do think this is kind of bad? So the grandparent totally has a point here: services find it hard to do only Passkeys (and thus realize the security benefits).
But, as a user, it's not something I worry about a lot, to be honest.
I was about to type something similar to this as well! I use passkeys pretty heavily, with iCloud sync. Never had an issue.
The only similar issue I can think of is sometimes my Macbook will loose the contents of the on device wallet, including in one case an ssh key stored there. That was somewhat annoying!
Agreed. I'm not so sure that some of the iCloud data loss bugs people talk about are actual data loss bugs. I've had a few issues over the years.
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.
To be clear, I don't work for Apple. :) And I'm not discounting that there are usage patterns that might lead to persistent bad experiences (like your example with Numbers).
But the implication that Keychain just kind of forgets saved Passkeys once in a while seems alarmist and probably unfounded.
Yeah exactly. It is possible that some expiry or provider specific bug may lead to revocation? I am not sure how it works entirely.
I will say that there are some very well known backup and restore issues with keychain however so I keep anything critical in MacPass as the primary copy.
> Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.
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 always set up two passkeys, one in iOS and one in bitwarden. I use the former on my phone (obviously) and the latter on desktop, in addition to “normal” logins with 2FA.
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.
> This library ended up with Kanidm being (to my knowledge) the very first OpenSource IDM to implement passwordless (now passkeys). The experience was wonderful. You went to Kanidm, typed in your username and then were prompted to type your PIN and touch your key. Simple, fast, easy.
> 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.
Authentication has become incredibly complicated for normal users.
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.
I may be mistaken in its implications, but given the 9th Circuit's decision in U.S. v. Payne this week [1], I don't know if moving all our password knowledge to biometrics is a secure idea.
I can't help feeling this... In an adverse world software and electronic data is too ephemeral to entrust with authentication and authorization. What if we had something solid like a Yubikey, but:
Just to clarify Estonian Id-Card most certainly implements the PIV applet while Yubikeys implement both PIV and the OpenPGP Card (the latter has a benefit of natively supporting ed25519: https://github.com/wiktor-k/age-plugin-openpgp-card).
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??
I think passkeys can be used just like biometric authentication is used in mobile apps right now: you sign in just like you usually do (e. g. username + password + TOTP or something), then on subsequent visits you can skip that and go through passkeys instead. New device? Just sign in with a password again.
This feels overly cynical to me. The article is a bit rambly so let me try to distill the problems:
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?
If the underlying technology is poorly specified and confusing enough that it doesn’t get implemented well in 95% of cases, then yes, that does indict the technology. See also: PGP and email encryption in general.
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.
I only used "just" twice, and they were both justified. Having people remember their email addresses, and explaining something in a couple of sentences, are both pretty easy.
Points #1 and #2 are not entirely trivial, but they're not much more complicated than the alternatives. A relying party has to store the public key counterpart to a user's private passkey no matter what. Is it really that much harder to associate that public key with their user ID? Point #2 is probably the hardest to overcome if you already baked in the assumption of 1 key per user. That's concerning. But that problem can also be mitigated by the authenticator, by supporting export.
I'm not saying the article fails to identify real issues. I'm saying it fails to identify insurmountable issues. The nice thing about software is that a good canonical implementation can be used by everybody for free.
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.
> With barely any setup, Google/Microsoft/Apple will keep a backup copy, in case you lose your phone.
Not Microsoft. Their implementation has no synchronisation feature and provides no way to back it up or transfer to another device either. You lose the computer you lose the passkey.
Their implementation is very daft and goes counter to the point of passkeys since you will need a less secure way of authentication to remain enabled on the accounts you use a Windows Hello passkey for, for the sake of being able to recover those accounts.
Remember, the best security schemes are only as secure as the least secure scheme that is available to access the account. If you're still on an account that can be recovered by sending a 2fa code to email or SMS/texting then you have achieved nothing.
Passkeys are pretty useless for me. At first I was somewhat hyped, but it seems that everyone just ignores them. Chrome does not support them. I set it up on mac, today I tried to login to icloud using passkey, but it just didn't work. Few websites implemented them, but overwhelming majority of websites don't.
So, yeah, useless technology for now. Passwords and TOTPs are the way.
Likewise frustrated by the passkey implementation but like the idea. I’ve been experimenting with passkeys leveraging SSH tunnels. You can read more about it with a demo here: https://pico.sh/tunnels
You use it because a concensus of security experts is cool with them, a normal person has no way of analyzing it properly. I see a few post regarding “I rather stick to generated passwords and have a program memorize it for them” it’s rather funny the way they rebuke new vetted tech
At TableCheck we rolled our own passkeys SP implementation primarily for our internal users, so they can access admin-level accounts without passwords.
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.
It seems like most of these gripes are due to the web app's implementation, and not passkeys themselves. It's a bit harder supporting multiple passkeys, but certainly doable. As others have said, this is just FIDO2/WebAuthn.
I use Strongbox and store my Passkeys in a Keepass File. Vendor agnostic, private syncable and locked by my passphrase.
I like them and wish more services would implement them properly.
Passkeys has a good UX and security balance. The other method would be to memorize a 20 length random password all inside your head or let grandma create a “password” so she can easily memorize it.
Tech articles have gone the way of online recipes. I had to read his grandfather's biography to understand he had a bad experience logging in with passkeys
I suppose this means OTP's would continue gaining traction as an alternative to password managers, a convenient approach but a risky single point of failure
Hm. The main criticism is you get locked into a cloud platform storing your private key(s) when using „passkeys“. This can be convenient as you can use your favorite smart phone to authenticate everywhere or even choose to rely on local TPM storage on your laptop or PC through MS Windows. This trades convenience with the risk of a vendor lock-in. But AFAIU the FIDO2 protocol you are free to use a dedicated USB key storage instead to store your private key (protected by a PIN or passphrase) on your own. This a bit less convenient but gives you peace of mind if you hate MS/ABC/Apple.
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.
In theory any FIDO2 implementation could work with any service that accepts passkeys. In practice, compatibility matrices and allowlists are the reality.
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.
> when the room is in a country that has a list of travel advisories including "Violent crime is more common in the US than in Australia", "There is a persistent threat of mass casualty violence and terrorist attacks in the US" and "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance".
Indeed, the author is not alone. It may be subjective but there are worries one needs to reconcile when planning a trip to the US (both for work as well as private trips). It’s often that we choose another destination or “can we find a way to make this remotely”.
"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.
The last time I was in the US, specifically in Seattle, there were two separate shootings within blocks of where I was at the time, and one at a bar an hour after I left it.
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.
I think it's a hefty chunk of paranoia. The US is absolutely a non-issue unless you have previously pissed them off. This is the same for every country.
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)
Apparently... of course, the threat of "mass casualty violence and terrorist attacks" is real, but you're probably still more likely to die in a plane crash while getting to the US (or in a car accident while there) than in a shooting or terrorist attack. And if you insist on only travelling to countries that have a lower level of violent crime than Australia, you probably won't get around much (https://worldpopulationreview.com/country-rankings/violent-c...)...
Oops, you forgot the other 2 travel advisories the author quoted in that part:
- "Violent crime is more common in the US than in Australia"
- "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance"
I think some Americans don't realize that, outside of America, many people don't ever consider the risk of gun violence in their day-to-day lives, or owing thousands of dollars for visiting a hospital.
That second one needs to be pointed out in particular - the US healthcare system is so expensive that if you have healthcare insurance as a foreigner, they're typically excluded from the international plan. You have to specifically go out of your way (and pay more) to make your local health insurance cover the US.
To be fair I've been to the US a few times and I've never been shot and I did end up in hospital and it was smooth as butter. Because I didn't hang around where I was likely to get shot and actually checked my insurance cover and had the cert on me.
Note I live in London and everyone tells me I'm going to get stabbed too and die from the pollution...
The homicide rate in Australia is particularly low. But in terms of overall homicide rate the United States is higher than the vast majority of other developed countries, and indeed most developing countries.
Most of the world sees the United States as a dangerous country.
For example, using the source you've just given, the US homicide rate is over 5 times the homicide rate of the United Kingdom, France and Germany, and over 10 times that of Norway.
Granted, you're more likely to die in a car accident than to be murdered in the US, but that's no reassurance; this is partly because the vehicle accident mortality rate is so high in the US, at over four times the rate in the UK. And your comment about dying in a plane crash is completely wrong: the air travel mortality rate is very close to zero, with under 200 deaths for over 800 annual million air travellers; a rate of less than 0.025 per 100,000 per annum.
I know that US is vast, and there are millions of good places where one could feel safe, but I assure you, from the outside sometimes is seems you live in a mad max alternate universe
Good riddance. Any system that limits my options as power user I will not promote. Lots of services only let you enroll single passkey and "hardware attestation" would only make it even bigger lock-in.
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 main thing that hurts Passkeys was how the implementation was so deeply tied to letting the browser do stuff rather than making it something like TOTP where any password manager can implement it and it's usable, agnostic from the browser. Everything about Passkeys is defined around using your browser as the agent that authenticates.
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).
Because if something is new, then it's automatically better, even if it's not, so it gets a hype cycle.
Honestly I'm just relieved this appears to be crashing and burning on the runway. Crypto bullshit's gone through several destructive hype cycles by now and the main consequence of the latest round of the AI craze will be a nuclear wasteland of an internet.
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."
This was so obvious from the start. Whenever big tech creates "standards" now you already know it's going to be total horse shit. Look back at the old threads when passkeys launched. HN was full of fanboys thinking it's the best since sliced bread and passwords are so yesterday. Managing your passwords takes a bit of effort like everything in life where you don't want do give away control completeley to some corporate aholes. Whenever you let someone else manage your stuff you set yourself up to getting ducked.
Passkeys are being pushed by Government and Law Enforcement because PASSWORDS WORK and frustrate them. Police access 95% of the phones they seize so they want passkeys to be the norm because once they own the phone they own EVERYTHING you secured with passkeys.
The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials but if Apple decides to delete your key or you want to leave your iPhone behind, what are you supposed to do?
The platform lock in attempt is wild, my initial experiences with Passkeys were great on iOS and Safari, either getting pushed to touch-id or scanning a QR with my phone. But then in Chrome I couldn't get into GitHub because chrome would only push me to use their manager and wouldn't offer a QR code.
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.
Yep, this is why I don't use passkeys.
I tried. The power-grabbing garbage was immediately apparent and sent me straight for "heck no, I'll just use passwords until they figure this out, at least that can't control my password manager".
In principle I should be very in favor of them, but the wild variety of lack of support for basics, and the built-in-the-spec ability for site X to control how I store and sync stuff is utterly bonkers. It's feeling like the OpenID promise -> OAuth platform lock-in cycle all over again, but compressed into v1.
I use 1Password which supports Passkeys, and don’t have an issue across mobile or desktop.
I don’t get what the issues people have really are. I never experience them (fortunately!).
1Password is a closed-source, cloud-hosted service. At any time, for any reason, they can close and delete your account, leaving you high and dry. Self-hosted, multi-device password managers are the only real solution. Thankfully, Vaultwarden and KeePassXC fill this role perfectly.
Now if we could just get the other providers that require insecure email/SMS 2FA to follow suit, that would be great...
The lock in is intentional, security theater touted as a feature in the shitty, ambiguous spec. Unfortunately, the folks who contribute to the spec are more concerned about threatening projects that have the audacity to use common sense instead: https://github.com/keepassxreboot/keepassxc/issues/10407 (and https://github.com/keepassxreboot/keepassxc/issues/10406)
Same thing with google app on ios. My wife saved a password to a site on her phone and we were trying to find it to log in again. Since she had navigated to the site through the Google app, the password ended up in her google account instead of the iPhone keychain - unlike in every other app on the iPhone.
> and shut down my Google Pay account I never knew I had
Google loves that nonsense, don't they? It's as though they think so highly of themselves that they cannot imagine they might not be strictly doing us all a favor by signing us up for their services.
Fifteen years later, I still have friends occasionally sending messages to a GMail address I never asked for, never used, and didn't even know about for most of a year while it was virally spreading through people's address books, silently diverting mail away from my actual address. The only time I used this account, after I discovered that it existed, was to delete it - but GMail apparently still suggests it when people type my name, because I get an "oops, sent this to the wrong address" forward every few months.
No I will not be knowingly using any Google passkey service, but perhaps I will someday find that they have signed me up for it anyway.
As shitified as the world wide web has gotten over the last few years, that's almost a feature these days.
Now you have lots of chaff / ablative / imposter emails to divert away all the robo-mailers, spear fishers, destitute princes, and the like. Even the tiniest little mistake and the email goes to one of a million diversion accounts.
Side Not-a-joke: On this topic, I also really hate two-factor authentication you don't sign up for, don't want, yet are forced to add to your account, because Google Play is too much of SCIF to just let you log in. Even more security theater for the most basic activities. Now I need two-factor every time I try to use GitHub. Ugg.
My wife has the opposite side of this problem coin. Her gmail address (which she does use) has virally spread through a family and circle of friends who all believe it relates to a person in the US who we are entirely unconnected with in any way. Attempts to get them to sort this out always fail because inevitably the address gets re-added to some thread or other and starts spreading again.
Never surrender any email address that a random berk can then claim.
I had my Facebook taken over because I had all notifications disabled and forgot that the email address was associated to it. Some criminal behind an Egyptian IP address took my old email and was in my Facebook within two days of me surrendering it.
Why don’t you setup the Gmail account to forward? I know it’s a hassle, but will resolve the issue
The issue is not forwarding the email. The issue is people sending email to the Google address in the first place. As someone who just set up email on his own domain, I'm starting to wish I could search every database and contacts list for my old Google address and replace it with the new one which is actually mine.
That seems like an invitation for long-term pain if Google changes their policies, requiring someone to log in every X months or have their gmail account locked, for example, or some AI enforcement tool locks the account for inscrutable reasons.
The account doesn't exist anymore.
Odd! I've been able to sign into desktops running Chrome both on Windows and Mac. Both times Chrome will show a QR code that my iPhone scans. The actual passkey is stored in 1Password.
The dark pattern about signing up for google pay is absolutely inexcusable though. Sorry you're going through that.
I think they changed it recently to offer a QR code because checking now it's offering it. But I absolutely had the issue for the first few months of the year.
> Then 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.
I believe those transactions are never confirmed and are reverted after 7 days or something like that
I think your mistake is not using firefox.
You are able to share an Apple passkey to any nearby Apple device at any time using AirDrop. Passkeys can also be used cross-platform during sign in via an NFC/Bluetooth handshake initiated by QR code.
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.
Number 2 is not true. I have a Yubikey and it can't be used on Android without a Google made app or account. It's always the same story, give a plausible option to seem open or neutral, but make sure there are "details" that establishes chain of consequences preventing it that is weird enough to allow denying intention. Even though I'm not that young I thought I just need to wait for Firefox to implement it, but as time went by I got curious and found out why it actually can't be done.
I was able to log in to GitHub using a Yubikey on my Pixel without a special app.
Check whether your Yubikey supports resident keys (aka discoverable credentials) and whether the FIDO key for your account was created with residentKey: true, otherwise it’s a completely different (older) flow under the hood, where the private key actually gets sent to the server, and it wouldn’t surprise me if that’s the underlying cause of what’s happening to you.
Thanks for trying to help but I really meant it can't be done, not that it doesn't work for me. This is the starting point for understanding why https://bugzilla.mozilla.org/show_bug.cgi?id=1678045 but that rabbit hole is pretty deep if you want to understand the whole web of consequences.
Wow. I just bought a couple of new YubiKeys for the OpenPGP Curve25519 support. I was looking forward to using the NFC feature with my Android phone. Is it just a Chrome problem? I downloaded some OpenPGP app from fdroid and it says it supports NFC keys.
I'm not sure about your exact situation, lot of the scenarios are OK, just the one without Google services which are dependent on Google account doesn't work. That is actually irrelevant for "normal" phone users that are logged to Google all the time anyway.
This all sounds like "it's technically possible, but it's a huge huge hassle and sticking with passwords is significantly easier".
I consider myself technically savvy, but I end up with countless different passkeys for different devices, and then multiplied again by all of the different services out there.
I have so many keys scattered everywhere that I would need an excel sheet to keep track of them. I regret not doing that already .. or perhaps I regret using passkeys at all. I am still trying to figure that out.
Seems like it. And the primary reason I haven't switched. Seems like a huge hassle and offers no advantages to me.
But what happens if I as an iPhone user want to switch to Android next year? Can I move my Apple passkeys?
No, you can't. You need to login into every website and replace passkey with new one in website-specific way.
You can use passkeys cross platform already, eg with 1Password or even KeePass XC.
But I do agree with the point that Passkeys make it really easy to get locked in unless you’re careful.
"We do not support competitors' products."
No, you add a new passkey from Android and then remove the passkey from iPhone.
1. Login with the passkey from your iPhone.
2. In your account, add a new passkey from your new Android. Now both passkeys are active.
3. Login with your new Android passkey.
4. In your account, deactivate the passkey that is stored on your iPhone.
Passkeys aren’t passwords. You can have more than one active at the same time. So instead of moving a single passkey around, you add or remove them to change devices or service providers.
My issue with option 1 is that it utilizes bluetooth. And everything involving bluetooth is not reliable.
"Alright Mom, here's what you have to do..."
This is alone a big enough reason that there never has been any reason to be hyped about passkeys. The hype train on passkeys has been insane.
> If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this.
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.
So use a password manager still (1P). You can have multiple passkeys for different devices or keychains but no entering passwords or credentials. Still an improvement and far less vulnerable.
1Password is a platform, one that has gotten worse over the years. They've taken a bunch of venture capital, switched to rental pricing, and apparently now demand that everything be in the "cloud". No thanks. I prefer to be my own password manager.
Bitwarden (& vaultwarden) also offer passkey which seem to work pretty well.
I've not had a problem registering both this and my phone on any site.
If you've already got a password manager, what benefit do you get from passkeys?
Avoiding the risks of short, weak passwords? The risks of reusing passwords across sites? The inconvenience of remembering loads of passwords? The frustration of having to type passwords manually? The risk of getting phished or typing one site's password into a different site? Remembering and typing usernames? The password manager takes care of all that for you already.
And if your objective is to have a second factor just in case your password manager gets compromised? A physical button just in case someone takes over your mouse and keyboard? Or a credential stored in a secure element that's (somewhat) protected even if you use it on a compromised machine? Putting it in a password manager (or OS keyring) removes those advantages.
Passkeys can’t be phished, or shoulder peeped, or entered on a malicious domain. And for the layman, it means they can’t forget their password.
Technically the place where you store your passkeys can be hacked into, but there is no technology that protects against that. You could give a tech layman 5FA and he’ll give all 5 factors to the nice man on the phone call.
Automation.
Password managers should be the default authentication method, and the current hack of having it type text into a password field is both unwieldy and completely avoidable.
The risk of your password getting stolen in between your browser and whatever hash algorithm the service you're authenticating with puts your password through before storing/verifying it.
That's the benefit you get from passkeys that no password manager will otherwise be able to give you.
The actual implementation of password managers is really messy. Browser extensions that try to guess which field may or may not contain your username, copy the 2FA code to the clipboard in the hopes that you’ll easily be able to paste it on the next page… passkeys offering a standardized API to provide this information makes it worth considering alone IMO, even without considering the extra security compared to plaintext password.
I've found the Bitwarden to be hit and miss. Some sites work fine with it, others don't work. I haven't debugged it enough to work out whether the problem is on the Bitwarden end or the website end or something else altogether. Given I'm wary of the benefits (or lack of) of passkeys I haven't really looked into it in depth as I have other 2FAs I can use instead.
I think it’s about platform lock-in as well, tightly correlated to pivoting away from cookies due to regs and user pushback.
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?
This is why services need to support multiple passkeys per user just like they should support multiple 2FA methods...
Big problem with this is that enrolling the secondary passkey requires the authenticator to be present. This is super inconvenient and risky as it always requires both authenticators to be present at the same machine/physical location, exposing both to local, physical threats (faulty USB ports on your machine frying anything you plug in? Congrats, you've now fried your main and any backup authenticators before you realized what was happening).
Ideally, you should be able to get an authenticator's public key and be able to enroll one without presenting the authenticator itself, allowing you to keep it in a safe/etc.
This would enable an easy workflow - enroll main authenticator as normal, then enroll your safely-stored backup by pasting its public key. If you lose your main, go to your safe, get your backup and "promote" it to primary and enroll a new backup one which goes in the safe.
It always struck me that 2FA is a corporate suicide pact. Some percentage of users are going to lose their keys per year so your user base is going to decay like a radioactive element.
This is why you need to enrol the secondary passkey at the same time you enrol the first one, not later when you might not have the authenticator present.
In reality websites should not allow setting up a single passkey.
Do they typically not? My only contact with passkeys has been the 2FA service (Duo) at my place of work, and I've got a passkey on my phone and laptop, as well as OTP push notifications, OTP SMS, or recovery code from IT. It's particularly handy with the Chromeboxes hooked into the big presentation displays since I can scan a QR code with my phone to use the passkey stashed inside it.
Slightly poor wording from me maybe. There have been cases where for example only one hardware key could be set up but other methods were available at the same time.
I remember AWS having some weird choices at some point too, not sure how they are currently.
But yeah, typically I think most services have had multiple choises available at the same time.
The services that I use passkeys for (MS, AWS) do. I have separate passkeys for 2 browsers and on my phone.
The trouble is if it is on the service to do the support, they can revoke support at any time. They could use start tightening the screws on device attestation tomorrow for business reasons and drop support for your browser or phone.
Yes, this is crucial. So far all the services that I use do though.
> The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in.
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.
https://twitter.com/dmitriid/status/1782787035637375050
I agree. So far I think KeePassXC is the only one that allows you to export your Passkeys. I believe Bitwarden are working on it as well. That said, it's unclear whether this will provide any portability of passkeys between providers.
Once you export your passkeys, is there anything that can import them?
I assume each provider will have the ability to import as well as export. The question is whether you can do that across providers. That's not too different from the status quo for passwords and other fields though.
... and they are getting warned about that feature existing: https://news.ycombinator.com/item?id=39698502
with an excellent response to that warning here: https://news.ycombinator.com/item?id=39706876
untrue, 1Password stores the private key just like any other key material, and one can export it or get the private key from the bamboo menu
Where did you see that?
This comment just 4 months ago from 1Password says that exporting isn't possible: https://www.reddit.com/r/1Password/comments/18m4iph/comment/...
And I haven't seen any announcements in the opposite direction.
————
Edit: so I just checked and I can confirm that it's not possible to export passkeys from 1Password. Neither of the two available export options include passkeys.
> • 1PUX A 1Password Unencrypted Export (1pux) file will export all your data, except your passkeys. You'll need to create new passkeys with your next password manager
> • CSV (Export only certain fields) A comma-separated values file (.csv) will export only certain fields. It won't export data such as custom fields or file attachments.
This is why I’m not interested in passkeys unless I can use it with my password manager (which I probably can at this point). It would also be nice to see the spec for these specifically address lock-in and provide anti-lock-in measures.
KeePassXC has support for passkeys now. However I've only managed to make it work with GitHub. Bitwarden does not work for now (although their passkey implementation for log-in is reportedly in beta).
Not sure what your password manager is, but 1Password supports them and its a pretty smooth experience.
The idea of a passkey is that it's bound to a device, and you can have more than one passkey. Think of a YubiKey, just that you can use your Phone or your PC instead. You basically have designated hardware that is always allowed to just login to your account...
Then why can it be backed up to the cloud?
My passkeys are in 1Password and work on every new device I set up.
Enroll another passkey. Password manager can also do that (Bitwarden, for example), so I really don‘t see a reason for all the agitation.
Because there is no way to do that at scale. If I've tied 200 services to my Windows-managed passkeys and now I want to switch to Linux, I have to manually go to each of the 200 services and ask them nicely to allow me to enroll a second key. This is simply unacceptable - and it's not like I could have done this ahead of time when I first signed up.
I've had a link to OnlyKey's user guide bookmarked for about a year[1]. They're an open hardware company that offers a key. Despite that I still can't be bothered to go through with it. The article we're talking about includes many of the reasons.
I feel bad for the author. They put a lot of their heart into something that could have been awesome.
[1] https://docs.onlykey.io/usersguide.html
Honestly platform-locking has so frequently and consistently been the intent of security-washing rhetoric and major breaches have become so commonplace that I now view "security" in the press to be a euphemism for lock-in first and foremost, with other usages being anachronistic or niche
Dont forget the euphemism "For your security" == "surveillance" -> EDR
KeepassXC says that it is adding (has added) passkey support. I haven't tested this yet, but if it works, that would avoid platform lock-in. Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job.
The big tech companies (Google, Apple, MS) have all become evil.
> Assuming, of course, that the platforms don't somehow intercept the passkey requests and refuse to allow KeepassXC to do its job.
My understanding is the ability to do that is built directly into the spec with the attestation feature. The only thing that might slow it down is Apple choosing to not implement it and zero out their device string. Others can piggy back on that to protect themselves behind Apple's skirt, at least until Apple changes their stance anyway.
Platforms of course could just not allow Apple passkeys and only allow Apple users to use other 2FA options as well. Rest assured that small players like KeepassXC will be the first ones to have their passkeys blocked or not supported.
The whole thing is a trap IMO.
I've tried it and it works on GitHub. Sites seem to be hit-or-miss for now. Tip if you want to use it with the browser add-on, it needs to be manually enabled and you also need to remove any YubiKeys from the system because it will prioritize them over KeePassXC
I like that app but until they add in templates, it's a no go for me. They are discussing it though (for 2.8.0), so maybe a future thing.
https://github.com/keepassxreboot/keepassxc/issues/8228
You can always use passkeys like Yubikey or others which are much more multi-platform.
This isn't a viable option in practice, because Passkeys use "Resident Keys". This means the credential needs to be stored on the Yubikey - which has a limited number of key slots. Need to log in to more than 25 (I believe) websites? Tough luck!
It didn't have to be this way, but the hype train won over practical considerations: https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-tu...
I'm curious as to why the number of slots is so small. Surely this is not some kind of fundamental limitation on what's possible (or cheap) with hardware?
You could use YubiKey to unlock Bitwarden that can practically store unlimited keys
Use a better token. YubiKey is the most popular one, not the best one by a long shot. My (cheaper) alternative supports 300 resident keys per each hardware key.
Webauthn, FIDO, etc. is run by a consortium of corporations whose goal is to be your sole identity provider and own your digital life. Nobody should have been hyped about this crap from day one.
What alternatives exist?
Wouldn't this be solved by just having multiple passkeys for each account?
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.
There is a way around this. Password managers. I use 1Passwords and it acts as the vault for all my Passkeys. Can access them on all devices. Super happy with it.
Is there a way to export a passkey from 1P to use in a different manager? (Legitimately asking, I haven't tried passkeys yet due to portability concerns, and this would be good to know)
Not currently. Someone already did lots of research on this — https://community.bitwarden.com/t/passkey-portability/59177
There’s some hope for interoperability between password managers someday. There doesn’t seem to be agreement on how you can securely export, transfer and import today however.
nope, and that's (currently) by design! from a user perspective, passkeys are supposed to be impossible to duplicate. here are some workarounds:
- you can log into your 1password on multiple devices
- you can sign in by QR code, with the help of whichever phone has the passkey on it
- you can add multiple per-device passkeys to your accounts of interest (for example, log into github on desktop and then add a passkey for your desktop device for that github)
- you can keep all your passkeys on a hardware dongle
- you can set up and keep all your passkeys inside an open-source manager (e.g. KeePassXC)
For first-party systems, passkeys are supposed to be stored in hardware storage (TPM chips, secure enclave, etc). Once it's in the chip, the secret key's never coming out of those pins again (unless you're a nation state with a tunneling electron microscope and a very steady hand).
(The huge exception is iCloud Keychain and whatever Google's doing for passkey sync, but that's importing from account data into hardware storage, not exporting existing credentials from a user's existing device)
If you want portability, then you can use HW security keys that support passkeys.
Create a new passkey on the device? Or on the new device? I don't see why this is a big issue. Sure, it's slightly inconvenient to go through the 'create passkey' flow on a new device, but as long as the account you are using (let's say, GitHub) supports storing multiple passkeys per account and managing them online, there's no reason you can't.
For every single one of your 100+ accounts? What if you forget an account when doing so, then it's lost forever? If one of the 100+ websites is momentarily down I simply have to keep the old passkey provider around until it comes back up and then remember to switch just that one later?
Are you using every single one of the 100+ accounts constantly? No? Then you can do the passkey flow on demand as needed. It can be comparably simple as an email login or 'we emailed you an OTP' login confirmation flow. If you never get around to using the account ever again in your life, I suppose you never needed it?
If the website is momentarily down how are you going to access it with a password at that moment? You'd have to wait until it came back up. And then you could just as well set up the passkey.
I think it is true that you can's export passkeys stored in Apple Keychain. However, the statement is false in two ways:
- 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.
How do you sync it to your Windows PC? Is it native Apple-Microsoft sync or does it require e.g. installing an Apple application?
I would also like to know how this is achieved.
1Password
I had to turn off apple passwords/credit card autofill because it clashes with 1password - how donI enable the 1st class integration?
> - Apple's iCloud Keychain syncs across devices
...as long as you always keep buying apple.
I thought passkeys were shared across Apple keychain (like passwords?) so you make a passkey on iPhone your iPad can use it.
Yes, that's correct, they're stored in Keychain and shared using iCloud.
Ah, yes, poor choice of words on my part. They are in iCloud Keychain (I think this is required?). But if you only have one device it's basically the same thing, or if you're trying to leave the ecosystem.
Are they not private keys that shouldn't be synced across devices? I thought icloud facilitated automatic creation of passkeys for each device, not actually sharing the same passkey across devices?
That's the crux of one of the debates... members of the FIDO Consortium threatening KeePassXC and other open source tools with blocking for sharing "roaming keys", meanwhile "Oh, Apple wants to share keys via AirDrop? No problem", which is one of the concerns, that it's yet another "push users to Apple and Google's tool of choice".
There are two types of passkeys (1) resident, hardware-bound, non-copyable, installed on Yubikey etc., and (2) non-resident, copyable.
Technically, by not being copyable, a resident key isn't a "Passkey," but that's just terminology and it serves the same purpose as a passkey.
As I understood it, that's exactly the purpose and not an issue. You are supposed to create a new passkey on each device you have. The fact that they can roam around within e.g. the Apple ecosystem is just some added function that Apple offers.
If I first signup for a service on my iPhone, then want to login on a Linux desktop, for example, how would I login if the passkey is not on my system, and I can’t login on the desktop to say I’m me?
Maybe they sorted all this out so it “just works”, but there seems to be so many potential pitfalls, that I feel like I’d need to spend weeks researching stuff and testing edge cases before I could feel safe using it. No one is going to do that.
With a password, I know it works now, and it will work in 40 years. I don’t have that same kind of confidence with a passkey. Even if it’s great, if people don’t adopt it in mass, it will fade away and be removed, so how deep do I want to go? This isn’t something I want to be an early adopter on, at least not for anything I care about.
> If I first signup for a service on my iPhone, then want to login on a Linux desktop, for example, how would I login if the passkey is not on my system, and I can’t login on the desktop to say I’m me?
What's supposed to happen is when you tell the site you want to use a passkey and one is not available to your Linux desktop's browser you are shown a QR code that you can scan on your phone. The login will then take place via the phone using your passkey that is on the phone for that site.
If you want to test to see if your browser handles this right you can do so at <https://www.passkeys.io/>.
Once you are logged in with your passkey from you phone you should be able to go to your account settings on the site and somewhere in there find an option to add another passkey. You can then add a passkey generated by your Linux browser or your Linux password manager if you use a password manager that supports passkeys.
Some will object that this is not good enough because they might want to login to some desktop they have never logged in from before when they do not have their phone handy.
That's probably not as big a problem as they expect though because unless you are using passwords you have memorized the same problem applies to passwords. I've got over 400 accounts in my password manager, almost all with long random unique passwords. That means I'm not going to be logging in somewhere new to any of those sites unless I've got access to my password manager, which in practice means unless I've got my phone or tablet with me.
You get a link (or more commonly a QR code) that you open from the device on which you already have the passkey to grant access to the new device. Then you add the passkey for the new device.
FWIW I don't think that this makes passwords redundant in general, but with passkeys, password becomes a last-ditch safety valve to regain access to the account. Meaning that it can be generated, very long, and stored in a way that is optimized for safety and security over ease of access (like, say, an encrypted text file on multiple USB sticks stored in different physical locations).
... and that the FIDO Consortium threatens to block other, non-Apple/Google companies if they try to offer.
You are supposed to use multiple passkeys or you can use a password manager to store and sync your passkeys cross platform.
Your passkeys sync in iCloud they aren’t device bound, just platform bound. Passkey export import is being worked on.
Use a different factor of authentication and setup a new passkey?
Do you have to do this for every account? Like changing my password on every account?
yeah, I agree this is not a good experience
You can normally create multiple passkeys across different devices for the same login.
What about solokeys.com?
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?
I use 1Password to manage passkeys. It’s pretty nice. They sync across my devices, I can erase one if I need to, and generally with the exception of something odd with Firefox and one website they just work.
Store your passkeys in BitWarden.
Because if you don't want to, it'll get in your way every time you try to use your actual passkey. Oh right, I forgot they added an option - now it just gets in your way every time you try to use your actual passkey on a new device.
I love Bitwarden but they still don’t support that on mobile phones.
I think it's very close to landing into the release version. I've seen people discuss it working in the testflight/beta release on iOS
You can't trust Yubico?
Bitwarden? Proton?
Go buy a Yubikey?
Every time I see a long inscrutable discussion about Passkeys, I see a weird avoidance of the "something you know" part of security. Here in the US, courts and law enforcement have every right to get your username, fingerprint, retina scan, face ID, whatever. But they don't have the right to extract something from your brain. Unless I'm missing something basic (which at this point, I don't think is my fault since this whole thing appears incredibly difficult to explain), Passkeys skips past that whole thing in favor of making it a heck of a lot easier to replace "something you know" with "something you have". Which is a security nightmare.
Keys can require a pin (or maybe a password depending on implementation).
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.
PINs and passwords on HSM keys like this are typically very secure as they will wipe themselves or at least lock themselves after a small number of failed attempts. For example if you only allow 5 failed attempts a 4 digit random PIN has a 0.05% chance of being guessed and a 6 digit PIN is 0.0005%.
So the only real risk is key extraction, hardware key extraction is always possible but likely incredibly expensive, so for most threat models it is not an issue. (Software key extraction or side channels is a different problem which may be easier but in theory is not possible.)
PIN+limit is still a much worse user experience than a password:
- a PIN is hard to memorize, so people are more likely to use personally-relevant or common numbers, whereas a password can be easily be both complex and memorable - it's easy to burn through even 10 login attempts through any combination of temporary/permanent disability, stress, being drunk, damaged device... - a wipe-after-failed-attempts system is trivial to abuse, be it by a prankster or a real adversary - it's much easier to see someone's PIN over their shoulder or film them entering it
> But they don't have the right to extract something from your brain.
Most folks store passwords in password managers and don't use their brains to retrieve them.
But my password manager locks….requiring something stored in my brain.
Which is exactly where your passkeys can be stored too. Put them in a password manager like 1Password, disable biometrics, and law enforcement would have to enter a password to access them
Doesn't your password manager use biometrics to unlock though?
password managers are growing, but I'm not sure that 'most' people use them. Maybe 'most' software engineers or techies, but the average person probably has no idea what a password manager is.
>”the average person probably has no idea what a password manager is.”
In my experience, that’s a notebook or piece of scrap paper next to the PC with all their usernames and passwords scribbled on it.
That being said, all of the friends and extended family members that I have helped with computer issues have chosen to save several passwords in their browser’s autofill. Yet, none of them knew that they could view and edit these passwords.
Depends what you consider a password manager. "Word doc with all my passwords in it" is effectively a password manager in this context
They may not know the name of a password manager, but many may know their iPhone remembers and fills in passwords.
Which is a bad idea. Right? That counterpoint defends a bad idea. We should be against the practice of permanently-unlocked password managers, and password managers that are only locked by "something you have". People also create ssh keys with null passwords, but it's also a bad idea and we should be opposed to that.
Most folks do not do this. Although they should be.
> But they don't have the right to extract something from your brain.
sure they do if, unless you want to be held in contempt of court for not providing the information.
In the U.S., this is a still-evolving area of law, which has been raised before the Supreme Court: https://www.supremecourt.gov/DocketPDF/23/23-1020/302999/202...
The State of Utah instructed the jury in State vs. Valdez to infer that a suspect was guilty because he refused to provide his password to the police. On appeal, the Utah Supreme Court ruled that he had the right to withhold his password according to the 5th Amendment, and he shouldn't face negative consequences for doing so. The state appealed that ruling to the U.S. Supreme Court, citing various other state and Federal courts which have made conflicting rulings on this same issue.
Sixteen states (Indiana, Alabama, Alaska, Delaware, Iowa, Kansas, Louisiana, Maine, Michigan, Mississippi, Nebraska, North Dakota, Ohio, Oregon, South Carolina, South Dakota, and Texas) just filed a motion asking the Court to hear the case: https://www.supremecourt.gov/DocketPDF/23/23-1020/307804/202...
Quoting that brief:
"[C]ourts have issued orders requiring persons to unlock devices or provide passcodes. But courts across the country are divided as to whether the Fifth Amendment bars such orders. [...] The Court should grant certiorari to provide guidance on how the Fifth Amendment’s guarantee against self-incrimination applies in the modern context of electronic devices."
The Court has yet to decide if they'll hear arguments: https://www.supremecourt.gov/search.aspx?filename=/docket/do...
More info/commentary here: https://reason.com/volokh/2023/12/14/is-compelled-decryption... (But I recommend going directly to the primary source material—legal documents in Supreme Court cases are very accessible, even to non-lawyers.)
Don’t you have a right to not incriminate yourself? You only have to give them information as long as you’re not incriminating yourself, right?
Historically, US courts have declared that giving a password is proof that you control the given asset and that this can be incriminating.
In practice, juries will take a refusal to divulge a password as evidence of guilt, the cops will use it as an excuse for even greater brutality, the FBI is perfectly willing to hold you without trial for years on end, and in most cases they don't need it anyway because everything lives on someone else's computer and they're perfectly willing to hand your data over if they haven't already. Furthermore, because the defense is founded on the principle that the password serves as evidence that you owned the encrypted data, if the prosecution is able to prove that you owned the encrypted data in any other way, that protection goes away.
I am, of course, not a lawyer. I'm just summarizing easily available information, i.e. wikipedia.You cannot be compelled (in US court, anyway) to give up encryption passwords/keys.
You can certainly be compelled in a black site torture den, but most people don't have that as a looming threat yet.
> You cannot be compelled (in US court, anyway) to give up encryption passwords/keys.
Multiple people have been held in contempt for refusing to provide an encryption password by US courts.
Here's my opposing view: I love Passkeys.
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).
I went through passkeys.directory site and it's underwhelming. Too few sites implement it, and many implement it inconsistently:
- 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.
> It seems like we still have some way to go before we figure it all out.
You're 100% right, though I'm actually surprised that so many sites already support passkeys.
If passkeys is a good idea and consumers use them, then gradually sites will shift over. Changing how everyone in the world does auth is not going to happen overnight, or even in a year.
If your only argument is "wow, it's easy", you're not arguing from the perspective of any kind of security.
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.
Are you arguing against password managers or passkeys?
Honest question, not a critique: what's the point of passkeys if you already use 1password? It unlocks with touch ID both on computers and phones, it autofills and autogenerates username and password. Plus you've got the option to fall back to manual input if you don't have 1password available in a particular device, and credential sharing (outside of 1p) becomes feasible. What's better about passkeys with 1p?
They're easy to use! I don't have to go through a site's normal login flow. 1Password just shows a standard prompt where I can click "sign in"
Additionally, it makes 2FA quite a bit more convenient.
Lastly it's the only way to login to my Georgia Tech account without opening an app on my phone which is absurdly annoying.
> It would be inconvenient if I needed to login to a shared computer
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".
Most if not all providers that I've used still allow you to use a password.
If you _had_ to you your passkey you'd probably have to install 1Password + the extension in your browser. This is definitely not a great workaround.
I wish there was a "fast API" for password managers. You can help them autocomplete by using `type` and `autocomplete` attributes in your login form, and there is a "well-known" URL to find the password change form, but I wish there was a way to bypass the HTML page entirely. This would get us 99% of the features of Passkeys I think, where the user only interacts with the password manager's UI.
Also a 1Password passkey user. It is the most portable implementation of passkeys I've used. Still, if you want portability with passkeys you have to trust some company to sync them. I don't want to need to rely on Google, Apple, or Microsoft to sync my keys because those platforms all have some lock-in. Guess 1Password is a form of vendor lock-in too, but it is one I don't mind.
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.
What about selfhosting Bitwarden?
I’m with you on that. Also, 1Password’s built-in Watchtower tells you which of your saved accounts could have passkeys added to them.
I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.
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.
People keep trying to answer this question, so I'll try, too, but I'm going to do a better job than anyone else. ;-)
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'm assuming tech people would also like to know that a passkey is not just "a really long password" but also one that's never sent to the server directly - instead it's used in a challenge/response protocol (like SSH keys). Which requires software, either the browser or an external password manager, to run.
I think that's what you're getting at in paragraph 3?
There's no reason you couldn't have an open source passkey manager that allows you to backup and view the key if you really want to. SSH works just fine that way.
It's up to the server whether it uses it in challenge-response or not. That's application-specific behaviour that's past the definition of passkeys themselves.
The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
> 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.
This part right here is what I fear the most about Passkeys. I've read too many horror stories of people getting banned from Google (often for no valid reason) and losing access to all of their data. It is absolutely insane to hand over all your passwords to a company like this.
I have been using passkeys for a while in the form of yubikeys
Best practice is to register two keys to every website. Keep one physically in a safe.
With password managers I would say the same basic practice applies. Make sure you have a working offline backup of whatever secrets you hold dear.
There are some sites that only allow you to register a single passkey for an account (AWS Console last I checked) but these should be getting fixed as it becomes more popular
> 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.
There are so many apps that don't get this right. Make a login on the website, store it in 1password, and then try to login in their mobile app and it doesn't show up as a password because the associated URL is mismatched on the mobile app. Like mybank.com and auth.mybankmobileapi.com
1password has a URL field. All you have to do it add the extra URLs
Better yet, while on mobile, search for the entry of the desktop site and have it fill. 1password will ask if you want to update the entry for this site
I have been using 1Password for over 15 years and it has the ability to only show/fill passwords when on the correct site. The issue is, over time, companies shift their strategies on the web. URLs change, while the accounts stay the same. I have had to update these details many times. I've also run into situations where the browser plugin isn't functioning, for whatever reason, and the only way in is to copy/paste. There are also times where I'm not on my computer. For example, I usually piggyback on my dad's copy of TurboTax each year. When I'm over there, I will often need to pull up a password on my phone and type it into TurboTax as it logs into my bank to download the tax forms. Passkeys don't sound like they can solve that problem. I'd question if the Passkeys would work in TurboTax even if I was running it on my own computer.
With passwords and logins, it seems like there are far too many edge cases to draw a hard line to say they are locked in the password manager forever. Having a way to copy it out, or export, is also a way to ensure portability, if the password manager being used ever becomes bad and a different option is needed.
Password managers put users in a vulnerable position, as once a user is invested, they've got you by the short hairs. The thing that keeps this from being a big problem, is that there is always a way out. Eliminating this way out, or raising the barrier to exit, can temp these password managers to extort their users, which is not good.
Passkeys are signing a challenge using a captive secret, right? The relying party doesn't get the secret.
You can have multiple passkeys per username.
This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in.
You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey.
It’s a different mental model and the key is in the name. Passkeys are like keys. You can have more than one.
It's not a problem of mental model, it's a problem of scale. If I'm switching phone, the last thing I want to do is to go to every website I have an account on and essentially do a second sign up. This is simply a non-starter, and is a big part of why companies like Apple and Google are pushing for this spec: it nicely ties you in to their ecosystem and gives you a huge reason not to move to a different ecosystem.
Do you know if there an open source self-hosted implementation available?
KeePassXC supports passkeys in its latest version: https://keepassxc.org/blog/2024-03-10-2.7.7-released/
I use selfhosted vaultwarden [0] instance (its a rust implementation of the bitwarden server), and the bitwarden apps (i point the apps to use my server instead of bitwarden).
Vaultwarden + bitwarden client apps (for desktop/browsers) have passkey support, and i've been using them for a month or two without any issues.
That being said, bitwarden client apps for android and ios are going through a rewrite (from xamarin to native iirc), and are yet to support passkeys. However, the bitwarden folk said passkeys are the next feature coming to these apps.
[0]: https://github.com/dani-garcia/vaultwarden
https://github.com/protonpass
Also see https://proton.me/blog/big-tech-passkey
Bitwarden, which you can self-host (I do this) seems to have at least partial support now, and I know they're working on improving it. However, I'm not sure if their client and server are both fully FOSS.
Strongbox for iOS/macOS. Uses the keepass file format
So passkeys are essentially like SSH keys but for web/app logins
They are a pleasant and improved UX for the equivalent of X.509 PKI primitives.
https://en.wikipedia.org/wiki/X.509
... with some of the functionality of SSH keys removed, like being able to use one key for many accounts, or many keys (on many machines) all for the same account.
At least that's how I understand it.
> there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy
This is a deep, fundamental flaw in passkeys. It's just another example of enshittification disguised as denying end-user control "for their own good." There is no for-profit organization anywhere that I trust more than I trust myself, and there's no threat model where it's more likely I'll be socially engineered into giving up my long random password than that I'll suffer data loss.
Good for you; I'm ashamed to say that I've hurt my data sanctity far more than any criminal has, with 2am tinkering with my systems.
I have vaultwarden at home but I don't use it because I just know I'll fuck up my tunnel while I'm travelling or something.
This is my threat model: "hi mum. I need you to drive to my house and fish a keyboard out of the cupboard. Plug it into the big black box and type exactly what I tell you..."
Then use a password manager that allows it
Thank you. Very helpful
I’m in the same place.
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.
> 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.
It's my understanding that you can't switch password managers without generating a new passkey for each individual service you use (I'm not an expert here, so someone feel free to correct me). That's already enough for me to not switch.
This is why, for me, the problem is not the passkey model per se as much as it is the inability to export/backup/convert my iCloud Keychain database to another account or platform. Apple could arbitrarily delete my data or lock me out of my own account. Or it could just randomly break with no solution besides deleting the database and starting fresh. And according to the author, this has already been occurring!
>Externally there are other issues. Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.
So those are the real risks.
That’s my problem with TOTP second factor authentication. I’ve used Authy for years because it works on Windows and mobile, but now they’ve decided they aren’t going to work on Windows anymore (but they still force update a perfectly working Windows app and there’s no way to opt out). I have no way to export my 30+ TOTP accounts to a new system. I often don’t want to have my phone around when I’m trying to focus and get work done, but now I have no choice. It’s infuriating. Is there any cross-platform TOTP system that has the ability to export your keys? Is that even a thing that’s technically feasible?
> I’ve avoided passkeys so far because I just don’t have a good mental model of them.
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.
> "and use fingerprint/faceid instead of a password"
This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.
The fingerprint/faceid is just a local proof to unlock the actual asymmetric encryption key. It is not your actual identifier to the remote server. So if you need to redo your auth, you just rekey and stash the new key in your authenticator (or have your authenticator originate the key material and never expose it to main memory at all).
Think an SSH key protected by a passphrase. Your passphrase isn't the thing that actually logs you into the server, its just what you use to unlock your actual key material you use in your SSH handshake. Your fingerprint/face identity is just your local unlock of the actual key material stored in some other secure enclave.
The unstated value of a USB key is the functional similarity to metal keys for ordinary people.
The biometric stuff is simply allowing access to the keys. It’s not being used for anything else.
Your face or fingerprint being out there isn’t a concern because that’s not, ultimately, the thing being used to generate the keys or anything.
It’s an ease of use function.
On iOS for instance, as I understand it, these are being stored in iCloud Keychain. Which has a password. The derived key for iCloud Keychain is stored in such a way that the system has access if you allow biometrics to be used.
Biometrics then simply allow access, in essence, not part of the encryption process. The password for iCloud Keychain is necessary to add those items on a new device. Your biometrics aren’t stored by Apple anywhere other than in the device.
Honestly I am blown away how few people on this site understand how this stuff works. It’s fascinating and I’m surprised more people aren’t interested in understanding it. But so many people assume the biometrics are being used in the encryption process and that if your face is somehow stolen your whole life is doomed. These features have been on Apple devices for what.. a decade almost at this point? More? The process for Face ID is the same as Touch ID. Developers make zero distinction between the two in code, as that whole process is passed off to the system and effectively results in a bool value (or access to the secure item requested). At no point does a developer ever get your biometrics data.
I don’t know how Android or Windows do it but it is similar enough I suspect.
The FUD around passkeys feels like some sort of propaganda campaign to discredit it.
This is the part where you have people dismissing a security from a simple assumption and reverting back to another assumption of their current state. Is still dangerous
Your fingerprint/faceid/whatever is used to access the passkey. It is not the passkey. To that end, yes, if you are worried about clandestine access to your phone (if that is your passkey), then you probably don't want to allow access using fingerprint/faceid. And if someone can copy your passkey off of your phone, you are again compromised.
Your faith in humanity seem low, because this would never be pushed worldwide by security experts who eats and sleeps it, if it was so easily broken where you just figures it out during a comment
This sounds, to me, like a really bad and convoluted way of storing pub/priv in a password manager, and hoping the software implementation gets it right when it's trying to manage these things for me because I'm too dumb to manage passwords and too hobbled by bad IT policies that want to change my passwords every 4 weeks.
Yubikeys absolutely took off in certain corporate, government and tech environments. Just not so much with the general public.
Eh, somewhat. The lost key account recovery story is much better in large organisations, where you have a 24/7 helpdesk that can check your ID badge in person, a HR department with a photocopy of your passport, and suchlike.
But for example if you're using Azure/AD? No U2F + Password allowed, gotta go straight to "passwordless" [1].
So they never took off far enough for Microsoft to support them.
[1] https://learn.microsoft.com/en-us/entra/identity/authenticat...
[deleted]
The big question I have is are the keys device/browser specific?
Seems to me I need to be able to log in with a password from any place (my phone, my machine, my office, my wifes phone, her laptop, my friends laptop, etc.).
I mean, who knows when I'll want or need to get into Something.
Also, my wife and I share accounts (such as Amazon). So, it needs to work seamlessly across all of her devices.
Then there's always the "F-with it factor" that I loathe. At least I understand passwords. Can (mostly) always recover a password (I recall trying to recover my Apple ID password -- they bluntly said "ok, but you have to come back in 2 weeks", so I was locked out for 2 weeks).
And, of course the level of patience my wife has with Technology is less than zero.
I rely on my Safari auto fill, when I use another browser, I just copy the pw from Safari.
And I don't use any of the cloud services. I have an iPhone, but don't use iCloud.
A few weeks ago, I was unable to log in to Google on a new device with my 2FA token (Yubikey) because Google insisted on authenticating with a passkey/resident key, but the token had only been set up with non-resident TOTP or whatever it's called (and had been working properly in this mode for over a year). I was able to log in on another device and register the Yubikey with a passkey/resident key, but it was really scary! There is so much complexity here, and so little visibility and control afforded to users, that I feel very uncomfortable trusting it as my only login method for any moderately important service.
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.
It's a Google sign-in workflow problem. I've seen the same issue more than once - for whatever reason it decides that this one way of signing in is the one that you want to use right now, and it can be impossible to back out until some timeout kicks in.
If even Google can't get it right...
You can store passkeys in a password manager as well:
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)
It's still not a great multi-platform/multi-device story. I use multiple machines regularly (and I've migrated away from 1Password to the KeePass ecosystem, by the way) so syncing passkeys from my Mac(s) to my iPad, to my Fedora machines and my Windows working environment is simply not happening any way I look at it.
Passkeys are great for consumers who use one or two devices (or browsers - I also switch browsers frequently). For anyone with more than one platform or one device in their lives they suddenly become added complexity, because even though you _can_ have more than one passkey per account per service, in practice there are all sorts of weird edge cases.
They're just not mature yet, period.
You shouldn't ~~necessarily~~ need to "sync" your passkeys across all your devices; each device should have its own passkey. Then if you lose a device (or that one device gets compromised), you revoke the one key and everything else is fine.
Similar to SSH keys. No reason to use the same key on all your machines, use a different key from different places.
The passkeys on my laptop are different from the passkeys on my desktop which are different from the passkeys on my phone which are different from the passkeys on my main yubikey which are different from the passkeys on my backup yubikey.
Edited due to acknowledging people may choose a variety of alternative workflows.
I've installed KeePassXC on my Mac and Linux machines and it stores Passkeys. Low-tech syncing is by Signal Notes to Self. If there were an audited app for iPhones I'd still be using that method; there isn't, so I've moved to Bitwarden. Passkeys seems to work fine on Bitwarden.
How do the private keys get synced across my devices? What's the default in the Apple, Google and Microsoft ecosystems? Devices get lost after all.
By default they go in your cloud synced password manager for those platforms. iCloud Keychain etc.
Or you can use a third party password manager like 1Password or KeePassXC.
I currently use the 1Password passkeys, and when they work, it's pretty good. I get all the fun of showing up on a website, and with three clicks, I'm in. But I've used them on just a few websites (email and GitHub), and they work correctly maybe 10% of the time.
First, I had to figure out how to get the website to request the passkey. Then I had to figure out that I didn't want to use the browser's passkey but 1Password's, which is different on different browsers and platforms. And good luck if I'm on mobile, I don't think it's ever worked.
At this point I'm taking a break from signing up new passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).
PS: Why is it that no financial institution lets you use anything more than a SMS U2F?
How do you back up the private key? With ssh I know to back up .ssh with the rest of my home folder. With a passkey I'd have no idea where it was, and get the feeling the "modern" software won't tell me on purpose, so that it can manage/sync it for me. Which leads to a lack of a mental model.
The same way you would back up passwords stored in iCloud Keychain, 1Password, KeePassXC, etc.
Nice phrasing, I lack that mental model as well. Anyone here willing to distill down the whole thing to a few sentences? Who stores what kind of secret, and is there some kind of challenge/response at auth time?
A physical device which is not your computer stores some secret information which can authenticate you. This can be passwords, passkeys, GPG keys, your retina etc.
The physical device can be password protected. So you have two step authentication: 1. your physical device 2. your password to that device
Phones are currently being promoted for various reasons, but I believe something like Yubikeys or other FIDO2 fobs will be a better device. You can have multiple of them, you can store one of them in your bank safe. Someone stealing it of you is proper theft which can be traced in a usual manner by police. Stealing is not enough because you still need the password. The difficulty of asking you for password remains equal to difficulty of hitting you with a wrench. You don't need to remember stuff anymore, because you can just use your physical keys. You will need to travel with those keys, but its just same as your house keys. It is probably an extra key in your key fob.
To add to it, the U2F/FIDO2 standard will make it vendor independent, and so no lock-in.
What I find rather confusing is what happens on each device. There appear to be multiple places where passkeys can get stored (iCloud Keychain, Google account, Chrome profile, Bitwarden, ...?) and depending on where it's stored it may or may not get synced to various other devices, browsers and apps.
So my problem is that I keep forgetting which device, browser or app I used when I created a particular passkey. I'm never asked where I want to store a particular passkey and where I want it to be available. This is all an implicit function of a combination of factors apparently.
It's like misplacing my keys has been taken to a whole new level of abstraction :-)
There's something here I am not following. First you say:
> Stealing is not enough because you still need the password.
But then:
> You don't need to remember stuff anymore, because you can just use your physical keys.
How are these statements both true?
Safari on macOS uses passkeys without phone. So unless you consider security chip inside macbook a separate device, that's not true, that's just one of modes.
Thanks! A bit late to the party, but if you still see this, I presume the authentication exchange between the web server and the device is some kind of challenge response? And if so, does the challenge/response depend on the type of credential that's in the device?
Back when I implemented webauthn for the first time I remember the interactive tutorial webauthn.me provided by Auth0 was very helpful in wrapping my head around the process.
Most important feature imo: The effective "password" being sent over the wire is essentially some hash(secret, uri). Think about the consequences for phishing!
Not true.
Nice to hear I'm not the only one. Part of the problem is that it's always presented post-login when I'm already in the middle of doing something. And my password manager works well, so I don't see a clear benefit and I'm not really motivated to investigate vague claims.
I agree, plus the added abrasion from passkeys being implemented inconsistently and seemingly in a way that promotes vendor lock-in. Do I need a different passkey for my iPhone and an android tablet? Do I need a different passkey between iOS devices? Why does this service allow me to use a passkey in Bitwarden, but that service doesn't? These are all questions I've never had to ask about a complex password in a password manager.
The primary advantages of passkeys are phishing resistance, uniqueness per site, and breach resistance.
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.
>All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.
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.
Yes but what I'm still confused about is that: 1) Is one/some of your public key reused on different services 2) Or is there a different public key for each service
1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password
2) In the second case when one service is breached you'd still have to manage rotation of public key somehow, how trivially is that done with current implementation ?
>2) In the second case when one service is breached you'd still have to manage rotation of public key somehow
Why would you need to rotate your keys? If they're storing passwords/hashes it makes sense to rotate because they might be able to brute force the hashes on a GPU cluster, but you're not going to be able to brute force a randomly generated public key.
Not reused, each service has a different key
To rotate, you go to the key management page of the service and delete/add a new key.
The whole point of a public key is that it is not secret. A breach where a service leaks the public keys of its users does not harm your security posture at all.
Thank you for that description. I do understand at a high level that it’s similar to SSH keys with the pub/private aspect.
I think I really need to implement it myself at least once to really grasp it. Maybe that’s stupid/slow of me but that’s how I learn best.
The problem Passkeys (and FIDO2 and WebAuthn and U2F) solve is phishing. The core concept is mutual authentication: not just you to the service, but the service to your authenticator.
Totally agree. I have used fido2 and webauthn before and I liked it. Particularly with a hardware key the mental model is quite straightforward. Now with that Microsoft, Google and syncing business I am left totally confused. Why the hell should alI store a private key in some cloud?? What happens if that provider decides to terminate my account, if it gets pressured to release the key? Also how does this all work with Windows Hello and other things in between??? I know a bit of crypto and security protocola but the passkey concept and possible attack vectors totally escape me.
I agree, framing it as a mental model makes sense.
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.
What the parent says. I'm hoping this HN thread will help clarify this.
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.
They’re basically an advanced username/password that’s automatically generated by your device. I believe one of the benefits is they require an encryption component that is known only by the devices that you own. This is better than a password that’s stored on a server and can be lost.
Here's a primer on the basic idea: https://blog.codesolvent.com/2015/07/why-not-signed-password...
Yeah I’m not sure what’s going on either. Is this just a rebranding of mutual-auth SSL client certs?
It is a different technology with some different edge cases so I wouldn't call it a rebranding but in the broad scope yes. The problem with this stuff was always the integration, not the tech.
Kind of. With the sharp edges filed off. There's no CA though. The web site provisions and authorizes the client's key at onboarding.
ohh, I see. that's clearer than any other explanation I've seen, thanks.
Having a mental model of encryption has never improved security
The mental model is very simple. If you use things like Yubikey, it is exactly like a key you use to start your car. A single password protected key maybe. In essence, it is your password manager but something that everyone can use. And something that doesn't need to be on the cloud.
It is like a key to start your car, except you can register it with multiple cars. And it has 25 or so "slots" for car registrations. If you lose the key, you cannot order a copy from the car manufacturer. You also cannot make a copy yourself. But you can (usually) register multiple keys with the same car. You do this by plugging two keys into the same car, and the car learns both keys belong to the same owner. You just have to be careful and keep track of which car is registered with which key, and vice-versa. Sometimes the key will not work with a particular car. Also, after you plug in the key, the car will not start right away. It will first ask you to select which key to use. If you use Bitwarden, it may hijack the key insertion interaction and will offer to use its soft-key instead. So, some small differences ;-)
That is how you add new keys to my car, have 2 existing keys present to add a third
Well that doesn't help understand: How passkeys can be backed up? Where/how they are stored? What if I loose my phone, computer? How can I login to some app using pc/mobile?
I haven't been into passkeys as you see, but some easy login like that leaves me with a lot of questions.
The TL;DR version in my opinion is that passkeys are quite similar to a SSH key pair, like one you'd use on GitHub. Basically you generate a key pair, the server stores the public key, and the client stores the private key. When you want to authenticate, the server sends a challenge, you sign it with your private key, and send it back. The main debate is over how to manage those keys after generation.
- Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.
- Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up. So the passkeys are stored encrypted on disk, and the decryption key is stored in the keychain/keystore. Other options include passkeys actually stored in hardware (eg. Yubikeys, but then you can't back them up) or 3rd party password managers.
- Login: It's pretty seamless, just click "login with passkey". The browser handles finding the right passkey, and part of the signed challenge includes the domain the passkey is for, preventing MITM-style attacks. There's also a whole separate thing for authenticating a session on a different device via scanning a QR code or Bluetooth.
Here's a good fairly high-level breakdown of how it all works, if you want some additional detail: https://webauthn.wtf/how-it-works/authentication
https://news.ycombinator.com/item?id=40168230
I reread your analogy a few times, and while I think it's probably accurate, there is absolutely nothing simple in it. It reminds me of the "It's like Uber, but for mortgage insurances" kind of startup pitch. It perfectly encapsulates the concept, but the concept itself is just crazy niche.
To note: the key to start a car is provided with the car with no specific operation, is locked to no other device, doesn't care about who's handling it, can be duplicated and passed around. It would be closer to the traditional password system in all of its aspects IMHO.
https://news.ycombinator.com/item?id=40168230
See this and let me know if it makes more sense.
Apologies I dont mean to be rude, but this does not help me conceptualise passkeys in the slightest.
https://news.ycombinator.com/item?id=40168230
I think I'm a tech guy and know my fields. I still have no real clue how passkeys work, how it is better, what it really is.
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?
Passkeys are exactly like SSH keys. You should use them exactly like you use SSH keys.
"Exactly" is under a lot of strain here.
SSH is nice because you don't have to think about it. Your private key sits in your .ssh folder, and then everything is transparent. You _can_ put an SSH key in a smartcard if you want, but you have to opt-in to this kind of pain. And even if you do, almost all SSH servers will support that login method without issue.
Passkeys don't sit in your .passkey folder. Your browser doesn't look for passkeys in a standard folder at all. You don't just do passkey-keygen like you would ssh-keygen and forget about it.
Websites might support various combinations of FIDO/U2F/TOTP security keys, your USB security key might support various combination of FIDO2/CTAP/WebAuthn, and the user will be left confused what any of this mess means, why there are so many competing standards, and why they're asked to scan a QR code when they plug in their dongle, and it doesn't just work at all.
Passkeys ought to be exactly like SSH keys. Unfortunately, they are not.
The attempts to restrict when and how they are stored, and how you can access them - those are going to cause a lot of pain and confusion.
I have all of my SSH keys stored in KeepassXC, which (imho) is a lot more secure than having them hang around in my .ssh directory. Open KeepassXC, and the keys are available. Close it, and they're gone. Synchronizing the KeepassXC-file across devices means that I have access to the keys on all of my devices.
The big companies pushing passkeys are trying very hard to prevent this kind of convenience.
If they are exactly like SSH keys, then why not just keep using SSH keys. Clearly, there is something else to them.
SSH keys are clearly not a feasible authentication method for non-technical users. Passkeys are here to replace passwords, not ssh keys.
What about storing/backupping/managing passkeys versus SSH keys?
It's the same, you should not store or backup SSH Keys.
For me that means having multiple keys in `authorized_keys` for the same user and never transferring private keys between devices. From what I gathered from the discussion here, this is not a given.
So how can i scp my passkey to another machine?
Why would you want to? Just create a new passkey on the other machine. If you're saving them in a password manager, just create a new entry, "Another Machine's Passkey."
Usernameless always seemed like an optimization too far to me.
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.
> Usernameless always seemed like an optimization too far to me.
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.
> email is usually a better identifier, assuming you already need one for other reasons (like you say recovery is typically needed).
If you remember which one you signed up with, and it wasn't your work email from two jobs ago.
Or you can just use a verified email as a username...
There's no account recovery process for passkeys. I thought they are your identity?
No, your person is your identity. Passkey don't pay for services, people do. So there is always a recovery process, at least for any business that actually values you as a customer.
No, that's like having only one key to your house.
If you have two passkeys from different providers, they serve as backups for each other. And there are other alternatives, like a printout of recovery codes.
I've never tried to use passkeys, but determined a while ago my hard, non-negotiable, a priori requirements which would have to be met for me to be willing to use them:
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:
2. I can disable any attestation functionality to do my part to prevent any online service from making it mandatory.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?
> I can backup and copy a passkey without restriction ...
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.
Totally agree with this.
I wish Yubikey allowed users to import their own FIDO2/webauthn seed and overwrite the factory generated one, and then also allow the resident passkey functionality to be disabled.
It should be up to the user if they want to have multiple duplicate hardware authenticators and be able to backup their seed however they wish.
Why would the U2F-on-Ledger route stop working?
Firefox and Chrome display a permission dialog when a website requests attestation, and you can deny it. If you deny it, the website has no idea how your passkey is stored, allowing you to use a pure-software solution if you so desire. The website could discriminate against you for denying attestation, but note that Apple always denies attestation for passkeys, so websites intended for the general public are unlikely to discriminate against users who deny attestation.
So yes, I believe your requirements are met in practice.
1Password includes Passkeys in archive/exports of the 1Password database. Safari developers have stated that it is a planned feature to support Passkey exporting (but not currently supported) including between apps.
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.
> 1Password includes Passkeys in archive/exports of the 1Password database.
They explicitly do not.
That's new, in the past I tested and was able to export my database and it included the Passkeys.
As someone who happily uses Yubikeys, I really don't want to use a Passkey. I want to still use a username/password and the Yubikey. Not just username and Yubikey.
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.
You can open your Firefox about:config and set security.webauthn.ctap2 to false.
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.
Using a direct link to Google’s 2FA setup will allow a Yubikey to be setup as 2FA instead of a Passkey, too: https://joshua.hu/enrolling-hardware-keys-2fa-google-workspa...
Thanks for the link. But it doesn't work anymore. I am being prompted to register as a passkey!
> I want to still use a username/password and the Yubikey.
Why?
Because of the whole "multi-factor" thing, and not making account recovery impossible?
Passkeys are always going to be less secure than username + password + Webauthn, why would you intentionally make your account less secure and give yourself a massive failure mode in the process?
Password and other factors are not going anywhere. You can set password, TOTP, email, phone and passkey at the same time. And use passkey because it's convenient. But use other combination of factors, if you need to access website without passkey. At least if website owner allows it. But I think that most websites will allow it.
Account recovery is a separate issue. There's nothing about a pass key that makes account recovery any harder or easier than if someone loses their MFA TOTP device or forgets their password.
You can (and are generally required to unless you purposefully use a "non-compliant" implementation that ignores it) set a PIN on your passkey.
> Passkeys are always going to be less secure than username + password + Webauthn
It's less secure in the same way that a door is less secure if you put a single strip of duct tape across that same door. Technically yes, but not in any meaningful sense.
If you can recover your account solely with your username and password, then what security does your Yubikey provide?
Definitely not for security... so yeah, seems quite pointless.
Yubikey + PIN works as a very nice passkey
If you use Google Workspace you can set 2FA directly from the admin console, so you don't need to disable FIDO2 on the key. Does not help with gmail, though.
Not in my experience. In the Admin console I said do not use Passkey and it still created it as a Passkey :( This was about a month ago, so maybe they fixed it. Turning off FIDO2 made things work.
If you add a FIDO2 key as a security key in the admin console, it will show as a "passkey" in Google account settings, but it will actually be a non-resident key used only for 2FA and won't be able to be used for anything more than that.
Keys that do not support resident keys (or when you turn FIDO2 off) show differently in Google account settings which makes it all very confusing. The UX is inexcusable, really.
As a side note, turning on Advanced Protection also turns off passkeys.
> But of course, thought leaders exist, and Apple hadn't defined what a Passkey was. One of those thought leaders took to the FIDO conference stage and announced "Passkeys are resident keys", at the same time as the unleashed a passkeys dev website (I won't link to it out of principal).
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".
> I really like the idea of generating keys on the fly based on the domain name that I'm authenticating against.
You could do it on a USB cryptoprocessor, and securely, too. https://tillitis.se/
> At this point I think that Passkeys will fail in the hands of the general consumer population.
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.
They're a consumer capture mechanism insofar as password management tools are, and we want users to use those because they make security tolerable. The problem is that it turns out the OS vendor was in the best place to win the password management game.
The lock-in situation with passkeys seems far worse than with password managers, though. There is no "export" option for iCloud passkeys - despite being cloud-synced across your Apple devices.
If you decide to switch from an iPhone to an Android phone, you're looking at an arduous process of enrolling a new passkey for every single site.
Password management tools allow export.
Just you wait for governments to require platforms to only accept gov-signed keys.
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.
not to diminish your point, but since at decade or so I'm a more worried about corporate surveillance capitalism than I'm about government surveillance.
Why? Governments can do so much harm by incarcerating, fining or even killing you.
Don't get me wrong - corporate surveillance can be very annoying, especially in insurance / credit scoring / price discrimination etc, but it seems a comparatively lesser danger.
With a bit of a change, you can mostly avoid most of those corporations... you lose out on some tech goodies, but you can still live quite normally.
You cannot avoid the government.
I mean, same, but only because I realized a new undesirable thing was becoming a tacit reality that we'd have to accept on top of already undesirable thing
The part I hate most about Passkeys is that it essentially killed the FIDO1/U2F ecosystem.
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?!
> 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.
Passkeys are a godsend when compared to weak passwords and SMS 2FA. Try to think through how to protect a bank account or retirement account for the average consumer, some banks send you a OTP and have you read it back to prove who you are when you call CS, some think the OTP is sacrosanct and will never be read back.
I 100% agree with you but there has to be something for regular consumers to safely log into a website that may have 10s or 100s of thousands of dollars on the other side of it, and be secure.
> Just about every website which implemented Passkeys removed the option to use hardware tokens with "non-resident" credentials
Which ones? AFAIK they support passkeys in addition to password+U2F 2FA
Google.
It still support U2F 2FA, but only if you have a non-FIDO2 key. If you have a FIDO2 key it will use it as a passkey, with no option to change this.
For folks who don't know how passkeys work at a technical level, take a look at this implementation guide: https://webauthn.guide/
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).
> I don't get the passkey hate
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.
I don't believe this is necessarily true, as far as intent goes. I think Apple and Google focused on a core use case, shipped it, and subsequently lost interest or fired everyone involved.
Unfortunately, this scenario is indistinguishable from one in which they deliberately mishandled the specs in order to lock in users.
Thanks for your faith. I work on the team shipping passkeys at Google. We are very much hard at work to realize the full potential of passkeys. Platform lockin serves no one. That is no one's intent - independent password managers storing passkeys is already a thing today. More interop will come once relevant standards are blessed.
You can absolutely do public key challenge authentication with passwords. You can use argon2 to derive the secret key for your account from your password and use that to encrypt a challenge message
Passkeys can't actually replace passwords, right? I will always need a username and password with a website, then can generate a passkey as a separate auth mechanism, which if I lose, I will recover by setting up again using my username and password? I don't get how we can get to a place where passkeys are all, how do you get a passkey on a new device when you only have passkey auth on some other device enabled?
That's not the idea, no. The idea is that - instead of a password - you have a cryptographic key. Like an SSH key. This key is managed for you, so you never have to see it or type it. You ought to be able to either have just a few keys, or else a different key for every service you use.
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.
Both iOS and Android sync to other devices in the same ecosystem, so there is at least a limited form of device portability.
If you have both, register two passkeys with each account and that's even better, since they back up each other if the vendor somehow deletes your account.
Wouldn't transferring the keys around just massively increase the attack surface? There's a security reason why we want them stored on-device and never moved, right?
Think of all of the password leaks you've heard of. How many were due to syncing password vs password reuse, poor site security (e.g. storing in plaintext, weak encryption, etc.)
I'm not saying syncing is 100% secure (nothing is), but for most people it's not the main attack surface to be concerned about.
The KeepassXC file is encrypted (granted, only with a password). Sure, that file is now on multiple devices, so somewhat more vulnerable.
The problem with storing on-device comes when you use multiple devices. I have three devices (PC, laptop and phone) that I use regularly and interchangeably. What am I supposed to do, if the keys are tied to a single device? Worse, what do I do if that device dies, or is stolen?
This is how I'm using them. Still have a username/password, with a passkey as an additional factor. I use 1Password for passkeys rather than Apple's solution, which enables me to use them wherever I have 1Password.
Passkeys change nothing about account recovery. The same process for a forgotten password should be followed for a lost passkey.
They can, and hopefully will.
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)!
A long recovery code that both you and the provider need to know in order to authenticate you IS a goddamn password no matter how infrequently you expect to use it. It just changes what knowledge a hacker looks for either in your digital storage or in a company's databases.
If you get rid of all knowledge-based authentication in order to increase account security, then you necessarily increase the chances of permanent lockout. You can't square a circle.
As for phishing, maybe google should put its AI capabilities to good use, and if the text of an email matches enough patterns of examples it's seen before, there should be a banner at the top of the email warning "this looks like a phishing attempt: common tactics include X, Y, and Z. Confirm authenticity before reacting to this email."
Long recovery code is definitely a password lol. Needs to just have email recovery and call it a day.
There’s more to phishing threat models than strictly credential theft, as you seem to imply.
If passkeys are around, phishing will certainly still exist, and shift to dropping malware on endpoints or w/e vs going after logins
I don't think you know what phishing means. By "dropping malware on endpoints" I think you mean having a website serving malware? That's not phishing. For an attack to be "phishing", the website needs to be pretending to be some other website that the user trusts. Passkeys completely prevent the user from logging in to another website than the one they've created an account with.
Your attack only works on people who basically "trust any website" at all. For those, yeah there's no salvation.
It depends on the implementation. Some sites use it to replace both 2FA and passwords, some use it for just 2FA.
> 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.
They are stored in your platform's password manager. So they're available on all the devices you're logged into.
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.
“My platform”? So, like, the BIOS? What if I want to use both a PC and an iPhone?
Platform as in "ecosystem". iCloud Keychain, Google Password Manager, Bitwarden, 1Password, your Yubikey. Anything that can store passkeys.
If you want to use both you simply enroll both your PC and your iPhone. There's nothing stopping you from doing this. You can register multiple passkeys from different providers to the same account.
You can also log in to your PC with your iPhone by scanning a QR code. And then afterwards enroll your PC as a secondary passkey.
I see, so you can use one device to auth and create a passkey on another
Did you know that you can turn every $2 Raspberry Pi Pico clone board into a FIDO2 stick, and even make it Yubikey compatible? https://www.picokeys.com/
Well, not as secure as a commercial key, because the Pico doesn't have encrypted storage, but still much more secure than login/password.
I still use Keepass (well MacPass) and naively "cache" what I use regularly in Keychain because I completely distrust anyone else handling the keys to my castle. Whenever I get a Passkeys notification it's an irritation as I don't actually see what the supposed benefits of this are and I'm not really interested in changing how I work. Just feels like I'm being dragged into something complex I will never be able to escape.
Password managers can store the passkeys just like they store passwords. 1Password has had strong support for them for quite a while now
Yeah probably can. But why do I need Passkeys?
If you’re asking in earnest: For the majority of users, Passkeys offer a pragmatic alternative to passwords that is far superior in terms of security.
For you, based on what I’ve read in your comments, I would say that Passkeys are the first workable alternative to passwords. They are built on WebAuthn which (roughly summarized) was the standard developed by Google and Yubico in direct response to the Operation Auora attack.
While the Apple/Microsoft/Google implementations of Passkeys likely won’t meet your personal standards, they’re built on a proven and well designed open standard. Which means you can benefit from the technology without buying into a corporate ecosystem.
1: Phishing protection
2: Protection against data breaches since Passkeys are not reused
3: Ability to login to devices you don't own without entering a password (QR code scanning)
Strong mitm and phishing protection.
Try Keepassium on iOS. It removed my need to “cache” anything in the keychain.
Do you know how to turn the dratted thing off, by any chance?
My biggest issue with passkey is not passkey itself, which, when it works, is great, but more the implementation of it done on most websites.
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?
I've added a few passkeys to 1Password. It works pretty well on github.com, and sometimes on google.com. But apparently, passkeys.io bypasses 1Password and asks the OS for passkeys? So passkeys.io doesn't actually work for me, unless I want to store the passkey in the OS keychain. Which I don't, because I don't want to be locked into that.
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.
Hey, founder of Hanko.io here, we run passkeys.io. That behaviour is not intended. We've recently changed the demo to require authenticator attestation on passkey creation, that may have an impact on authenticator selection. But a quick test on my system (macOS, Chrome) resulted in the 1Password UI intercepting the "Create a passkey" flow - as expected. It would be awesome if you could help us understand why your experience is different.
With that being said, we are not happy with how password managers have implemented passkey intercepts, but ultimately that's a decision the user can make, as it can be disabled in the browser extension settings.
My assumption is that there's no proper browser API for third-party passkeys, so this extension probably monkey-patches website JavaScript which is not reliable.
Interesting. What OS/browser do you use?
Paypal has a really obnoxious failed implementation of passkeys where if you have totp configured, their login flow takes you to TOTP after your passkey auth.
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.
The problem with passkeys, beyond the painful UX that will scare any casual users away and the fact that they are being wielded as an extreme vendor lock-in mechanism is just that the design and implementation is so over complicated with second system syndrome.
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.
If you want passkeys without Javascript, leave a thumbs-up on [1].
[1] https://github.com/w3c/webauthn/issues/1255
Good to know, thank you for the link!
I've had Apple silently delete music from Music when I had iTunes Match, and I've stayed paying for Dropbox despite wanting to use iCloud, which would be no extra cost for me, because their mechanisms for dealing with conflicts are different - Dropbox saves a version with "Name's conflicted version 2024-04-26" in the filename, whereas AFAIK iCloud silently decides what to keep and drop so you can't manually decide how to merge a conflict.
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.
Passkeys are horrible because the design encourages the need for a smartphone, which is itself a disaster.
Passkeys only encourage the need for a password management tool, which is funny because if everyone had password management tools to begin with then we wouldn't need passkeys.
This is not true.
Passkeys still protect you from additional things that password managers don't protect you against:
1. Your credential can't be phished as it's cryptographically bound to the domain. You could stil be tricked into entering your password and TOTP into a malicious website.
2. Your credential can't be leaked by sloppy servers as it's public key crypto. This makes your security not depend on believing the website your logging into does proper password hashing and doesn't accidentally log password in plaintext.
Most password managers tie credentials to domains. In fact, this is a good indicator of possible phishing attempts when your password manager doesn’t offer to auto-fill your expected credentials.
True, the technical aspect of passkeys does that. But in practical Apple and others want to heavily push for the smartphone as that tool, because it locks people further into that system.
> Passkeys only encourage the need for a password management tool
The dependency on a password management tool.
Be it Yubikey or Apple secure enclave or whatever, it's a shit piece of hardware that will eventually break. Have fun replacing all your credentials at the same time when your phone dies.
> Have fun replacing all your credentials at the same time when your phone dies.
I won't have to, because I've got passkeys on my desktop, my laptop, on my security token, etc. Losing one device won't lock me out.
I just use a yubi key....
This is quite concerning, because I've recently started a project that uses webauthn-rs. I want to minimise spam on the project while I don't want to collect PII like emails for login.
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).
> I wonder if it means that the author will stop working on the library after their next release,
Just FYI it seems the library will still be maintained: https://infosec.exchange/@firstyear/112337225055591544
I just went through the dance of logging out of all my google accounts and then logging back into them. While I was doing that, I added passkeys as a security layer.
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...
It's Brave, the browser is responsible for handling the WebAuthn (or alternatively, the Bitwarden extension for Brave, assuming that Brave exposes some API to extensions which Bitwarden has not implemented correctly)
For what it's worth, 1Password Passkeys works fine in this use case. I suspect it may be a subtlety in how BitWarden works.
Good to know, if it is bitwarden, then I guess I'll expect a fix in the future.
Just add a passkey for brave too
No, I don't want to be tied to a single browser for my passkey, what happens if I want to log into a site on my phone using safari or chrome? I also don't want it tied to my apple keychain. What if I want to share my passkey with my partner?
lol it’s a passkey… why would you want 1 that can be shared and… lost you just register another one
Being like “I don’t want to add another passkey” is really a semantic issue what exactly is the difference to you or adding a passkeys to an account vs copying a passkey to another device except the fact that if you can copy it/share it… it’d be far less secure with more ways to leak
I like the idea of Passkeys, but the implementation of them being exclusively tied to my super account of Apple or Google makes me very cautious. I’ve read too many stories about automated systems killing someone’s account and the resulting havoc.
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.
> "If you really want passkeys, put them in a password manager you control. But don't use a platform controlled passkey store"
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...
Honestly, I think a big part of the problem is that passkeys have been tied to hardware devices and they don't have to be. A passkey is just a public key credential, and it can easily be provided by software as well as by hardware. You would still get many of the benefits (better UX, automatically secure, prevents phishing) and the overall customer experience could be a lot better. Imagine if passkeys could be saved, transferred, and imported as easily as a PDF. Instead, we get a bunch of walled gardens where Apple/Google/Microsoft/etc are trying to be the only provider you use.
I have my passkeys in bitwarden.
Does BitWarden support passkey export now?
Export to JSON and then grep for `fido2Credentials`
I gave up on passkeys after running Google's passkey demo and getting started example. They impement session expiration client side only. I reported it, but they said it had been reported already and they didn't intend to fix it. Seems a little careless for a tool promising improved security.
I've noticed a few websites I frequent have quietly started using passkeys (or something very similar) outside of the normal channels. My bank now asks me to go through a second factor on my phone app that seems very similar to how passkeys work and Outlook has a similar login flow but with an additional 2 digit challenge code for some reason.
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.
Translation: the solution is overcomplex and has so many failure points that it has already proven to be worse than passwords.
Somewhat related: last New Year the company I work for gave us, the employees, presents. Something I assumed to be a USB disk. Couple weeks ago I had to migrate from my old personal laptop to the desktop I finally put together and needed a USB key to put an OS on the new computer.
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.
Bitwarden now official released passkey support on mobile app on iOS/Iphone in Version 2024.4.2.
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.
The solution to most of the author's criticisms lies in not forcibly mixing Passkeys and WebAuthn-based 2FA.
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.
I wanted to use Passkeys from the initial spec stage. The UX seemed far more superior (the closest I think is passwordless via email).
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.
(derived, reproduceable-ish) sounds like a security horror O_o.
You can set up a new Ledger (crypto wallet) and deterministically recover your keys using a sheet with 24 words written on it.
I've got my sheet in my gun safe, but you can also hide it anywhere in your house.
Oof, the Passkeys ecosystem is incredibly complex. Even as someone that deals with it day in and day out at $CURRENT_CO, it can be a headache.
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.
I am exploring this now, actually got 2 students doing their thesis on this. It's very complicated and unnecessarily so.
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.
Noone put any thought into the goals of passkeys and it shows.
You have to beat email/password with optional password manager (syncing, remembering , autofilling) and optional MFA (physical proof)
passkeys cant beat that in any area because they have no goals
Definitely this. I think the worst aspect of Passkeys is that the noble goals (public key crypto! unphisability!) seem to somewhat unavoidably wipe out one of the--in hindsight--really valuable aspects of passwords-in-a-password-manager:
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.
I've been using Passkeys saved in 1Password, I thought that gave me the power to transfer them, but I just looked and apparently the export feature of 1P doesn't allow exporting the Passkeys, it just tells you you need to create new ones in your new password manager, so that's pretty crappy...
Yeah I agree. I am familiar with crypto and public key authentication and password hashing and so on, and I cannot follow all of the terms and use modes. To the average user it's going to be a complete black box. They won't have a clue what's going on.
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.
Yeah, unfortunately passkeys are confusing and the UX is generally fucking awful. I hesitate to just blame the tech companies for being greedy, as a result of my experience with passkeys I'm starting to wonder if maybe they've legitimately just lost the skills and knowledge necessary to actually make usable software.
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.
FWIW: MacOS and iOS allow third party password managers to ingrate directly into AuthenticationServices and list passkeys in the native passkey UI through a "Credential Provider" extension. And it's documented how: https://developer.apple.com/documentation/authenticationserv...
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 :(
https://github.com/w3c/webauthn/issues/1976
> 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 mean, I kind of understand this; they're going to have to do the WebExtension either way, since there's no standard API across platforms.
On the other hand. They already integrate with this API for their iOS app as it's the only way to do password autocomplete on iOS. Why not extend that use to MacOS?
I don't trust passkeys, and yet so far, I'm not bothered by them. This is because I use them as an additional way to log in.
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.
You can have multiple passkeys (using different devices or passkey providers) for a single site too. You don't need to fall back to another login mechanism.
Yep, that too. It's especially convenient if you have both iOS and Android since you can easily log in using either.
> Within enterprise there still is a place for attested security keys where you can control the whole experience to avoid the vendor lockin parts. It still has rough edges though.
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.
Just wanting to get rid of "passwords" means getting rid of "something i know" as an authentication factor. That should not be the goal. The issue is that the other authentication factors have real drawbacks. It's tradeoffs all around.
'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.
There is no auth panacea. There's too many different use cases, too many players involved. You cannot create one "thing" that solves all the problems for all the people. It was hubris.
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 am fully invested in the Apple keychain ecosystem, I’ve got multiple Apple devices (laptops and a phone) and passkeys have been incredible. Haven’t seen any of these issues.
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.
How about we stop reinventing the fricken wheel every 3 years and let users adopt something? U2F keys were pretty danged good and they were easy to explain to my 70 year old parents "This is like your front door key to your house, it's a physical key to your Google account".
I use iCloud's Passkeys extensively and have never had saved Passkeys "wiped out". I am not disputing that data loss bugs can happen, but three times for one user sounds pretty weird given the maturity of the ecosystem.
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?
It's not hyperbole. I recently (few weeks ago) got locked out of my GitHub account after iCloud Keychain thrashed my passkey and after analyzing the root cause it turned out to be a bug in webkit (that is now fixed in Safari technology preview after me raising it with the Webkit team)
https://bugs.webkit.org/show_bug.cgi?id=270553
> b) The author is doing something weird.
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.
One thing that comes to mind is with the earlier WebAuthn implementations in iOS, before they were stored in iCloud and called passkeys, there was no management interface for stored passkeys and 'clear website data' (to delete cookies etc.) would actually erase all credentials permanently. It was useless this way.
Why useless? Not an authentication scheme to and all other authentication schemes, but certainly a (much) better successor to the login cookie?
I do not mean passkeys in general but early iOS implementation was useless since it deleted passkeys along with your cookies and other website data. The passkey iOS implementation is useful in its current form.
> I use iCloud's Passkeys extensively
So what happens if you want to migrate away from iCloud for the storage of passkeys?
You generally enroll a passkey for a single device or connected group of devices. My icloud-syncing devices has a passkey. My windows laptop has another. My desktop has yet another. I have also enrolled my yubikey.
I could stop using my idevices tomorrow and not be negatively influenced.
I can't speak for OP, but for every service that I use passkeys with I enrolled both iCloud Passkeys (for convenience) and several YubiKeys (for portability and backup).
This is not different at all from a SSH public/private key combo. You are not supposed to duplicate SSH keys!
Your answer is totally reasonable, but I admit I don't have time for that in most cases.
1. Most services are not Passkey-only--most people are using it as a password alternative (e.g. eBay) or a second-factor alternative. So losing it won't lock me out.
2. A very small number (e.g. Google) let you configure Passkey as your sole second factor. For those, I am indeed careful to do what you do and have duplicates.
I do think this is kind of bad? So the grandparent totally has a point here: services find it hard to do only Passkeys (and thus realize the security benefits).
But, as a user, it's not something I worry about a lot, to be honest.
I was about to type something similar to this as well! I use passkeys pretty heavily, with iCloud sync. Never had an issue. The only similar issue I can think of is sometimes my Macbook will loose the contents of the on device wallet, including in one case an ssh key stored there. That was somewhat annoying!
It can't be hyperbole, their partner's car keeps exploding too! So often that they're switching back to a four horse carriage.
Agreed. I'm not so sure that some of the iCloud data loss bugs people talk about are actual data loss bugs. I've had a few issues over the years.
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.
To be clear, I don't work for Apple. :) And I'm not discounting that there are usage patterns that might lead to persistent bad experiences (like your example with Numbers).
But the implication that Keychain just kind of forgets saved Passkeys once in a while seems alarmist and probably unfounded.
Yeah exactly. It is possible that some expiry or provider specific bug may lead to revocation? I am not sure how it works entirely.
I will say that there are some very well known backup and restore issues with keychain however so I keep anything critical in MacPass as the primary copy.
> Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.
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 always set up two passkeys, one in iOS and one in bitwarden. I use the former on my phone (obviously) and the latter on desktop, in addition to “normal” logins with 2FA.
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.
> This library ended up with Kanidm being (to my knowledge) the very first OpenSource IDM to implement passwordless (now passkeys). The experience was wonderful. You went to Kanidm, typed in your username and then were prompted to type your PIN and touch your key. Simple, fast, easy.
> 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.
Authentication has become incredibly complicated for normal users.
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.
I may be mistaken in its implications, but given the 9th Circuit's decision in U.S. v. Payne this week [1], I don't know if moving all our password knowledge to biometrics is a secure idea.
[1] - https://arstechnica.com/tech-policy/2024/04/cops-can-force-s...
I suspect that's part of the eagerness to move everyone to passkeys.
I can't help feeling this... In an adverse world software and electronic data is too ephemeral to entrust with authentication and authorization. What if we had something solid like a Yubikey, but:
- 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
If you ignore the last 6 points about cameras and displays, then this is kinda what "Smartcards" are, I think?
https://en.wikipedia.org/wiki/OpenPGP_card
In fact the Estonian Id-Card is one of these if I'm not mistaken
Just to clarify Estonian Id-Card most certainly implements the PIV applet while Yubikeys implement both PIV and the OpenPGP Card (the latter has a benefit of natively supporting ed25519: https://github.com/wiktor-k/age-plugin-openpgp-card).
The problem with smartcards is: I don't see what's on them.
When Apple announced passkeys it was obvious that this would be the end result. I remember quite clearly complaining to a friend of mine at the time.
Question for the author regarding:
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??
> Just like ad-blockers, I predict that Passkeys will only be used by a small subset of the technical population
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/ "
I think passkeys can be used just like biometric authentication is used in mobile apps right now: you sign in just like you usually do (e. g. username + password + TOTP or something), then on subsequent visits you can skip that and go through passkeys instead. New device? Just sign in with a password again.
This feels overly cynical to me. The article is a bit rambly so let me try to distill the problems:
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?
If the underlying technology is poorly specified and confusing enough that it doesn’t get implemented well in 95% of cases, then yes, that does indict the technology. See also: PGP and email encryption in general.
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.
I only used "just" twice, and they were both justified. Having people remember their email addresses, and explaining something in a couple of sentences, are both pretty easy.
Points #1 and #2 are not entirely trivial, but they're not much more complicated than the alternatives. A relying party has to store the public key counterpart to a user's private passkey no matter what. Is it really that much harder to associate that public key with their user ID? Point #2 is probably the hardest to overcome if you already baked in the assumption of 1 key per user. That's concerning. But that problem can also be mitigated by the authenticator, by supporting export.
I'm not saying the article fails to identify real issues. I'm saying it fails to identify insurmountable issues. The nice thing about software is that a good canonical implementation can be used by everybody for free.
Why couldn't passkeys just be a user-friendly wrapper around assymetric key pairs tech people already using?
They kind of are, except...
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.
> With barely any setup, Google/Microsoft/Apple will keep a backup copy, in case you lose your phone.
Not Microsoft. Their implementation has no synchronisation feature and provides no way to back it up or transfer to another device either. You lose the computer you lose the passkey.
Their implementation is very daft and goes counter to the point of passkeys since you will need a less secure way of authentication to remain enabled on the accounts you use a Windows Hello passkey for, for the sake of being able to recover those accounts.
Remember, the best security schemes are only as secure as the least secure scheme that is available to access the account. If you're still on an account that can be recovered by sending a 2fa code to email or SMS/texting then you have achieved nothing.
That’s basically what they are?
Passkeys are pretty useless for me. At first I was somewhat hyped, but it seems that everyone just ignores them. Chrome does not support them. I set it up on mac, today I tried to login to icloud using passkey, but it just didn't work. Few websites implemented them, but overwhelming majority of websites don't.
So, yeah, useless technology for now. Passwords and TOTPs are the way.
Chrome supports passkeys
It does not. Not for Linux, anyway.
It is because desktop linux does not have passkey interface built into the OS. There needs to be TPM, systemd, etc need to talk altogether.
Just logged in to iCloud using chrome on a mac. Scanned a QR with iPhone and boom that was that.
I tried to log in using chrome on fedora. Scanned QR code with iPhone, waited like 20 seconds looking at "Connecting" and gave up. Does not work.
Likewise frustrated by the passkey implementation but like the idea. I’ve been experimenting with passkeys leveraging SSH tunnels. You can read more about it with a demo here: https://pico.sh/tunnels
You use it because a concensus of security experts is cool with them, a normal person has no way of analyzing it properly. I see a few post regarding “I rather stick to generated passwords and have a program memorize it for them” it’s rather funny the way they rebuke new vetted tech
Passkeys always had a bad smell to me.
At TableCheck we rolled our own passkeys SP implementation primarily for our internal users, so they can access admin-level accounts without passwords.
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.
It seems like most of these gripes are due to the web app's implementation, and not passkeys themselves. It's a bit harder supporting multiple passkeys, but certainly doable. As others have said, this is just FIDO2/WebAuthn.
I use Strongbox and store my Passkeys in a Keepass File. Vendor agnostic, private syncable and locked by my passphrase. I like them and wish more services would implement them properly.
Passkeys has a good UX and security balance. The other method would be to memorize a 20 length random password all inside your head or let grandma create a “password” so she can easily memorize it.
Tech articles have gone the way of online recipes. I had to read his grandfather's biography to understand he had a bad experience logging in with passkeys
I suppose this means OTP's would continue gaining traction as an alternative to password managers, a convenient approach but a risky single point of failure
Hm. The main criticism is you get locked into a cloud platform storing your private key(s) when using „passkeys“. This can be convenient as you can use your favorite smart phone to authenticate everywhere or even choose to rely on local TPM storage on your laptop or PC through MS Windows. This trades convenience with the risk of a vendor lock-in. But AFAIU the FIDO2 protocol you are free to use a dedicated USB key storage instead to store your private key (protected by a PIN or passphrase) on your own. This a bit less convenient but gives you peace of mind if you hate MS/ABC/Apple.
>you are free to use a dedicated USB key storage instead to store your private key
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.
I’m surprised no one has written a tool (probably would involve disabling SIP) to import/export passkeys on macOS. They’re in memory, right?
Is passkey just OTP + vendor lockin because the vendors accidentally allowed OTP key export and are embarrassed about removing it?
>Is passkey just OTP + vendor lockin because the vendors accidentally allowed OTP key export
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.
“…if you do want to use a security key, just use it to unlock your password manager and your email.”
This feels like the best advice, imo.
To paraphrase a well-known saying: Those who don't understand ISO7816 are doomed to reinvent it, poorly.
> when the room is in a country that has a list of travel advisories including "Violent crime is more common in the US than in Australia", "There is a persistent threat of mass casualty violence and terrorist attacks in the US" and "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance".
What's wrong with these Aussie technocrats?
Is the author suggesting he’s not traveling to the US out of security concerns? Is that really a thing?
Indeed, the author is not alone. It may be subjective but there are worries one needs to reconcile when planning a trip to the US (both for work as well as private trips). It’s often that we choose another destination or “can we find a way to make this remotely”.
From https://github.com/orgs/community/discussions/54450#discussi... :
"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.
The last time I was in the US, specifically in Seattle, there were two separate shootings within blocks of where I was at the time, and one at a bar an hour after I left it.
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.
I think it's a hefty chunk of paranoia. The US is absolutely a non-issue unless you have previously pissed them off. This is the same for every country.
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)
Apparently... of course, the threat of "mass casualty violence and terrorist attacks" is real, but you're probably still more likely to die in a plane crash while getting to the US (or in a car accident while there) than in a shooting or terrorist attack. And if you insist on only travelling to countries that have a lower level of violent crime than Australia, you probably won't get around much (https://worldpopulationreview.com/country-rankings/violent-c...)...
Oops, you forgot the other 2 travel advisories the author quoted in that part:
- "Violent crime is more common in the US than in Australia"
- "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance"
I think some Americans don't realize that, outside of America, many people don't ever consider the risk of gun violence in their day-to-day lives, or owing thousands of dollars for visiting a hospital.
That second one needs to be pointed out in particular - the US healthcare system is so expensive that if you have healthcare insurance as a foreigner, they're typically excluded from the international plan. You have to specifically go out of your way (and pay more) to make your local health insurance cover the US.
Quite a few people don't want to deal with that.
To be fair I've been to the US a few times and I've never been shot and I did end up in hospital and it was smooth as butter. Because I didn't hang around where I was likely to get shot and actually checked my insurance cover and had the cert on me.
Note I live in London and everyone tells me I'm going to get stabbed too and die from the pollution...
Actually, I specifically addressed the violent crime thing...
As for the medical costs - if you want to be on the safe side, you can (actually you should) get travel health insurance.
We don’t actually consider that in the US either, you probably shouldn’t get your views of the US from Reddit or the Guardian.
The homicide rate in Australia is particularly low. But in terms of overall homicide rate the United States is higher than the vast majority of other developed countries, and indeed most developing countries.
Most of the world sees the United States as a dangerous country.
For example, using the source you've just given, the US homicide rate is over 5 times the homicide rate of the United Kingdom, France and Germany, and over 10 times that of Norway.
Granted, you're more likely to die in a car accident than to be murdered in the US, but that's no reassurance; this is partly because the vehicle accident mortality rate is so high in the US, at over four times the rate in the UK. And your comment about dying in a plane crash is completely wrong: the air travel mortality rate is very close to zero, with under 200 deaths for over 800 annual million air travellers; a rate of less than 0.025 per 100,000 per annum.
Yes, there are plenty of people who avoid travelling to the US
I know that, but I didn’t think it was because of security. I don’t think of the US as particularly dangerous, but maybe my perception is wrong…
I know that US is vast, and there are millions of good places where one could feel safe, but I assure you, from the outside sometimes is seems you live in a mad max alternate universe
Homicide rate is 10x the rate of EU and over 30x the rate of Japan: https://independentaustralia.net/politics/politics-display/a...
Rape rate is about 3x the rate of EU: https://www.civitas.org.uk/content/files/crime_stats_oecdjan...
People killed by police (population adjusted) is about 30x the rate of Germany: https://www.statista.com/statistics/585152/people-shot-to-de... https://polizeischuesse.cilip.de/?p=1&year=2023
It's the guns and the police.
People get angry or frightened. It's better for everyone else if they're not carrying a firearms at that point.
Policing a nation where everyone is armed means the police are heavily armed and the non-insane ones very frightened all the time. See above.
The homicide rate is 8x Australia's, so yeah it is by comparison.
Likely out of ignorance of actual violent crime statistics.
Yes, this is a thing.
well... yes. I, for one, am slightly worried to go to the US.
I use 1password stored passkeys. Works. I don't care about the whining.
Good riddance. Any system that limits my options as power user I will not promote. Lots of services only let you enroll single passkey and "hardware attestation" would only make it even bigger lock-in.
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 main thing that hurts Passkeys was how the implementation was so deeply tied to letting the browser do stuff rather than making it something like TOTP where any password manager can implement it and it's usable, agnostic from the browser. Everything about Passkeys is defined around using your browser as the agent that authenticates.
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).
Why did it took so long to figure out that passkeys was a bad idea?
Because if something is new, then it's automatically better, even if it's not, so it gets a hype cycle.
Honestly I'm just relieved this appears to be crashing and burning on the runway. Crypto bullshit's gone through several destructive hype cycles by now and the main consequence of the latest round of the AI craze will be a nuclear wasteland of an internet.
Please, stop with the "anything that happens that I don't like is enshittification" trend.
Please.
passkeys are ok, but passwords should also be an option if you want
only passkeys is a problem
> We missed our golden chance to eliminate passwords through a desire to capture markets and promote hype.
Enshittification in a nutshell. The victory of greed over utility.
Yeah, good riddance.
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."
good article and another reason why ppl really need to stop using chrome
This was so obvious from the start. Whenever big tech creates "standards" now you already know it's going to be total horse shit. Look back at the old threads when passkeys launched. HN was full of fanboys thinking it's the best since sliced bread and passwords are so yesterday. Managing your passwords takes a bit of effort like everything in life where you don't want do give away control completeley to some corporate aholes. Whenever you let someone else manage your stuff you set yourself up to getting ducked.
[dead]
Johnny Hates Jazz.
This was foreseeable.
Sometimes you just know when a thing isn't practically feasible.
https://news.ycombinator.com/item?id=36717356
Passkeys are being pushed by Government and Law Enforcement because PASSWORDS WORK and frustrate them. Police access 95% of the phones they seize so they want passkeys to be the norm because once they own the phone they own EVERYTHING you secured with passkeys.
There is nothing wrong is passwords.
There is everything wrong with biometrics.
Wake up!