74 replies
11h2m
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?
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.
Neither can passwords if you’re using a password manager to handle them.
So again, if you’ve already got a password manager, and would put your passkeys in a password manager, what is the benefit of passkeys?
You're wrong, with password managers you can definitely be phished. Unless it's literally impossible to extract the password to enter it manually, but I don't think password managers make that impossible (and if it's possible, users will do it).
With passkeys it's literally impossible.
Could you expand on how to trick a password manager to enter the password on a fake domain ?
I'd see having the user add the domain themselves, or get the user to copy/past the password themselves on some other form. But the phishing is not happening on the password manager side, and these use cases still exist even after you chose passkeys (i.e. I'd still need to somewhat log into Google's auth from my Nest hub for instance to have it show the calendar)
It happens to me very regularly that a password in my password manager is needed on a different domain. Maybe the logon process is at id.domain.com and password is pinned to domain.com, or maybe the password was created at signup.domain.com and so it doesn't pop up on domain.com, or you have to log in to a hotel's site with the password from their reward scheme (different domain), etc...
In any case users are trained by the internet to need to search for the right password outside the pinned domains. Most of the time I guarantee people don't add the extra domains to the password records. So when a phishing site pops up they'll do the same: search for the site name/domain that they think they're logging into and go from there.
Password managers solve password reuse, weak passwords, etc. but IMO do not solve phishing, especially not for the kind of user who's most susceptible t it (little technical understand, hates this stuff, just wants to follow instructions and not deal with it), but passkeys might.
At least on Bitwarden you can just edit the domain if that comes up a lot for you (or even add multiple domains to a password). I'd rather do that than copy/paste on a regular basis. Honestly I can't say I ever copy/paste.
I'm totally with you.
These issues won't be solved unless passkeys work absolutely everywhere the user has to authenticate. Logon required or weird and funky domains is currently due to service providers being a mess themselves (I'm looking at you, Microsoft). So should we expect them to miraculously get their act together and have each of these system flawlessly work with their passkey auth. from now on ?
That's where I think we're stuck with that class of issue for as long as there are multiple auth systems, passkeys or not.
I dunno about you. But I like being able to get my passwords out of the password manager. How is not being able to do so a feature?
Because that opens you up for being phished.
It cuts out the necessity for a password manager browser extension to handle stuff like autofill, password generation, etc. Those extensions have had fairly significant vulnerabilities in the past. So you're reducing the attack surface, as well as getting a cryptographic guarantee against phishing (the signature the client returns include the domain that sent the challenge).
Edit: The other great part is that the server just stores your public key, so it's idiot proof on their end. It makes a breach effectively useless, since offline cracking is impossible.
This is absolutely not true, it depends heavily on usage patterns of the password manager and its features. Not all are browser extensions that autofill, and even if they did, sites change their domains for auth occasionally that break this functionality (or more often, signup is on a different domain from auth) meaning you must manually copy-paste your password somewhat often if you don't meticulously, and manually, maintain your domain list for a credential. The average person is *not* going to do that, they're going to go "huh, it broke again" and copy paste their randomly generated password.
Please, do not give security advice you are not equipped to handle.
On the other hand, Passkeys have no easy way to extract the private key and do not request to enter the private key to authenticate. The authentication model is objectively better than passwords because you have to try very, very hard to extract the private key, to the level of compromising the device it's stored on or digging through hard to understand keychain exports if you store them in your password manager. Even outside of the storage model, they're better because you don't just send the thing that can be compromised over the wire to authenticate.
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.
If your TLS connection has been MITM’d, you have much bigger problems than your unique randomly generated password being sniffed out.
It is not required that your connection has been MITM'd. The service you are authenticating can accidentally log the plaintext password, they can store it with an insufficiently secure hash function or not salt it. A malicious browser extension can scrape it directly from the input form. Etc, etc, etc.
Passwords are reasonably secure since we've been using them for a long time but there is in fact a huge chain of trust required to keep them secure and links in that chain frequently break.
It's very easy to fall prey to an Evilginx or similar AITM phishing attack. Passkeys or TLS client certificates are the only guaranteed defense. Relying on the user noticing the different domain or the lack of autofill by the password manager, not so much.
If they control the information flow can't they simply steal the passkey too?
No, because they never see anything that needs to be kept secret.
Passwords are based on symmetric cryptography. When you log in to a site using a password you give the site your password in plain text, hopefully over an encrypted communication channel such as HTTPS so that no one between you and the site can see the password.
The site then takes that plain text password and decides if it matches the plain text password you gave them when you created the account or most recently changed your password. If the site is following good security practices they aren't actually storing a copy of the password in plain text. They will store a hash of it and compare a hash of the password you just send to see if the hashes match.
Passkeys are based on asymmetric cryptography, also known as public-key cryptography. When you set up an account at a site to use passkeys your device generates a public key and a matching private key. The site is given the public key and your device keeps the private key.
When you want to log in later the site sends your device some data, your device does a computation on that data that involves the private key and sends the result to the site. The site can recognize that whatever did that computation had access to the private key that corresponds to the public key the site has on file.
Nope.
Passkeys use public-key authentication wherein the server only stores the public half of a keypair and the client authenticates by correctly signing a challenge sent by the server, which the server then verifies using the public key.
At no point is the private key ever sent over the network or otherwise exposed to any infrastructure or code controlled by the server.
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.
Very easy to put the a password into the wrong place when doing it manually.
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.
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.
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.
Problem remains when you lose one, and need to block and enroll a new backup?
Enrolling both at the same time still requires both authenticators to be present at the same machine/physical location.
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.
That’s why most 2FA’s are 1.5FA by default where you can recover via SMS, delayed e-mail, etc, and you can (sometimes) only disable this by clicking through three scary screens and saving your 10 backup codes.
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.
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.
Apple’s iCloud for Windows includes an iCloud Password app which allows accessing and managing your keychain stored passwords on Windows. They also have a browser extension for Chrome and Edge which does autofilling in those browsers on Windows. I haven’t used them in a long time so I don’t know if they have added passkey support to them yet.
I had to turn off apple passwords/credit card autofill because it clashes with 1password - how donI enable the 1st class integration?
...as long as you always keep buying apple.
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.
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
... and they are getting warned about that feature existing: https://news.ycombinator.com/item?id=39698502
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!
You could use YubiKey to unlock Bitwarden that can practically store unlimited keys
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 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?
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.
Not sure what your password manager is, but 1Password supports them and its a pretty smooth experience.
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).
Store your passkeys in BitWarden.
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
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
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.
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
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.
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.
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.
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
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
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
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.
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.
Enroll another passkey. Password manager can also do that (Bitwarden, for example), so I really don‘t see a reason for all the agitation.