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?
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.
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.
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.
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.
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.
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)
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.
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...
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.
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.
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 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
Worse than that, having a gun doesn't make you safer; it increases the risk to everyone in your household. But I can absolutely understand why fear drives people to own guns -- it's a vicious circle as increased gun ownership drives fear, which in turn drives even more gun purchases...
Sure, but those rates are also really low. That’s a bit like saying you’re scared of using your car because a plane is much safer. The chance of getting hurt while visiting a meeting in Silicon Valley is still one in a million.
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.
I've heard horror stories about hospitals not accepting insurance. Wouldn't want to be in a situation of being ill and having to pay more than I can earn in a lifetime.
They will accept it. The cover has to be specifically for US hospitals otherwise the insurer won't pay out and they know that and won't accept it. You have to avoid insurers who only cover certain providers as well.
You have to read your insurance contract and info sheet properly rather than go for the lowest price.
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...
London's homicide rate is (roughly, depending on which source you use and year you take) about one-fifth of the average US homicide rate; you are safer in London than in almost anywhere in the US.
13 per million per year in London. 60 per million per year in New York.
That's an 0.006% chance of getting murdered killed in NY every year.
And that doesn't account for (a) putting yourself in a good position to get killed like being a gang member and (b) the aggregate reduction in risk by only travelling there.
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.
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.
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 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)
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'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.
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.
Linux most definitely has a TPM interface, it's called /dev/tpmrm0 and plenty of libraries for accessing it (eg. https://github.com/parallaxsecond/rust-tss-esapi/ full disclosure: I'm co-maintaining it). Systemd is not needed for that.
So where are things falling down? I seem to be unable to get passkeys to work in linux; Chrome or Firefox. I’m suspecting the issue is something to do with bluetooth.
IIRC, all these hardware exist. Software is not 100 % fine for them. The point is to have OS and password manager trust each other. Once this is done then all should work. That should allow for the browser to query the password manager for appropriate info. At the moment, password manager is poorly integrated onto OS.
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.
> If you use a software-based password manager, passkeys are indistinguishable from passwords both from a UX perspective and a security perspective.
That's not correct. Passkeys use public-key cryptography and a challenge-response authentication mechanism, so an adversary in possession of a read-only copy of the database of the service you're trying to authenticate with won't be able to authenticate as you - which is very much a security improvement over passwords, even when both are stored in a password manager.
> an adversary in possession of a read-only copy of the database of the service you're trying to authenticate with
True, but GP is referring to the private key on the (user’s) device or computer being stored in a password manager. The main protection that passkeys offer in such a case is that there’s no case of passkey reuse across services and accounts, which is something that’s possible with passwords even if one used a password manager (albeit poorly by not generating unique passwords for each account).
Since the passkey is the private key in the private-public pair, if it’s stored on a password manager it can definitely be stolen by malware (if you could have a key logger, you could have something else too). The only solution is to have the passkey (actually private key) reside in hardware or be protected by dedicated hardware.
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?
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.
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.
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.
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.
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".
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
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.
Yep, I agree with that response completely. That whole thread is a great read about the reality of the passkey situation, and what it will take to really make it great.
Thank you for posting this comment. I'm saddened but not surprised that attestation is being seriously talked about as a way to get independent password managers in line but not large corporations, and completely agree with Dan there.
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.
Well then their enshitification just continues with their unending quest for burning every user-centric bridge they ever built. Goddamn
To answer your question, "bamboo menu, Copy Item JSON" which I believe is turned on due to my "Preferences, Advanced, Show debugging tools" being checked. I actually did try the $(op item get --format=json $its_uuid) first but figured there was some sekrit env var or --fields some_horseshit that I needed to dig up and it was more energy than I wanted to spend for a HN comment
So, OT1H, what I send was half true - they are available for export but only after some hoop jumping and seemingly not in the official export packaging, which I suppose almost guarantees they will not "round trip" back into a Vault in any kind of disaster recovery scenario
It seems those 1Password jokers just get great thrills out of ensuring that anytime I have something to praise them for they ensure they have some user hostile stupidity ready and waiting to drive people away
Wow I confirm that this option appears once I enable the developer options. Don't say it too loud though — I'm sure 1Password will remove it if they notice that it slipped past their view because of just dumping the JSON object.
I wrote the initial .opvault import into KeePassXC and briefly considered going after their local .com cache file (hidden in a very obtuse place, of course) since it seems to be using their same opdata01 <https://support.1password.com/cs/opvault-design/#opdata01> encoding, at least when last I looked, but then suspected that the audience who would have already paid for 1P but wanted to switch would use 1PUX. Seems maybe that does need more consideration
This will be the straw, and now comes the “god how do I migrate off this shitshow” - enshittification pun intended. I nearly cancelled upon their choice to even add telemetry, then they made it possible to disable and off by default (though they still ask to turn it on).
The whole fucking point of a password manager, though, is to store and securely provide authn material while ensuring users can’t lose it… which necessarily includes ability to access it, and back it up.
It looks a LOT like passkeys and FIDO are, relatively effectively, backdooring what Google got beat to death for when they attempted to add “Web Environment Integrity” to browsers.
edit: But can I? I’m already questioning how hard it’s going to be, and if it’s feasible without a lotttt of hurt.
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.
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 don't sync anywhere because I don't use the Apple keychain for my passwords. No idea if there is a solution for Android but the original claim was syncing between your devices was only possible if you stayed strictly with the Apple ecosystem. This is not accurate since you can sync to Windows even if you can't sync to Android.
However the Windows sync is only possible due to Apple providing an app for use in Windows which suggests its still within the Apple ecosystem. Apple could on a whim decide to discontinue their app for Windows.
Which makes it the same as every password manager except KeepassXC which the passkey community seems to be upset to allow exporting. So commiting to the Apple solution is no different than any other. Passwords are exportable.
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 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.
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.
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.
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.
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.
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.
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.
The attacker could pretend to be the service the user is trying to authenticate to, issue a bogus challenge signed with the user's public key. That will allow intercepting the user's interactions but by this time the attacker has control over the target system so why not just take what is inside rather than go to the effort of interacting with the user?
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.
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).
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.
Yeah, I do this too, but many people I know wouldn't even think about the fact that they could do that, or why they would. They just know that whatever password manager they use doesn't find the password but if they search for it, it's there. So they do that and get on with their lives, inadvertently opening up an avenue for phishing.
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.
There can be vulnerabilities, this is clearly the hottest attack surface of password managers. I remember a few years ago Tavis Ormandy from Google Project Zero found such vulnerabilities in a bunch of the most popular password managers which allowed to steal credentials from a rogue website.
I'd still recommend using a password manager, as overall and in practice the risk of phishing and (re)using (weak) passwords is far greater than this kind of rare vulnerabilities (and also I work for a company that makes a password manager ^^)
True, but it also opens me up to using the same password on all machines I use. You can argue that’s a negative, but personally I like being able to add a new machine to my collection without worrying about who the vendor is.
The metaphor might be a bit esoteric, but that's similar to wishing that Hardware Security Modules (HSMs) allowed you "get your <private keys>" out of the HSM. As sibling comment says, that's how you get phished. The whole point of an HSM (and a passkey) is that the super-secret private part never leaves the HSM no matter how nicely you ask and no matter how compromised the machine is.
A password manager, OTOH, is happy to hand out your private key ("password" in this case) to anyone that has access to it.
It's a middle ground. You should be able to move passkeys from one vendor to another with some export process but the secret key is not exposed when you use it which reduces the risk of having it stolen
It's not that kind of impossible. It means that even if you are tricked into giving your passkey to the attacker, it's cryptographically useless to the attacker because a passkey is bound to a specific origin.
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.
Except we're talking about protections against phishing, and as much as I love the clipboard it will paste anywhere you like, including definitely wrong and evil places.
Except now you have vendor, browser and device lock in. So password managers are required to solve those very real problems anyway.
The value of these seem very low. Passkeys are a solution looking for a problem.
Mayve 10 years ago before password managers became a thing they made more sense? Now they're just kind of annoying and hard to share (sharing passwords is a real need for many people /applications / services)
>> Passkeys can’t be phished, ..., or entered on a malicious domain.
> Neither can passwords if you're using a password manager to handle them.
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.
> Passkeys have no easy way to extract the private key and do not request to enter the private key to authenticate.
Sure the do. All somebody needs is the password to your password manager. It's a single point of failure and by putting your passkeys in there to you've made it even more vulnerable.
Do you put a passkey on your password manager that exists outside of that ecosystem? Once you have that why not just use it for everything?
The parent wasn't giving security advice. They were asking a valid question.
> Sure the do. All somebody needs is the password to your password manager. It's a single point of failure and by putting your passkeys in there to you've made it even more vulnerable.
Not more vulnerable than if they were just using password. You're still missing my point, password managers do not give you the ability to just copy-paste the private key of a passkey into a form field, unlike passwords. Some don't give you access to it at all (*cough* Apple *cough*). Sure you can get the private key if you have access to the password managers vault, but that's not what's being talked about. Common usage patterns matter immensely in security. At the end of the day, the attack surface for passkey-based authentication is smaller than password-based authentication, which is a step in the right direction.
> The parent wasn't giving security advice. They were asking a valid question.
The parent made a blatantly false and dangerous statement and then followed it up with a question. Did we read the same comment?
I agree that it's not more vulnerable than just using a password, I'm only saying that it's only slightly less vulnerable under the best circumstances and incredibly more vulnerable under the worst circumstances (ie. if somebody got ahold of your password manager).
I also agree that passkey-based authentication provides a smaller attack surface than purely password-based authentication.
But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.
This is an HN forum. Nobody's giving "security advice," but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?
> I agree that it's not more vulnerable than just using a password, I'm only saying that it's only slightly less vulnerable under the best circumstances and incredibly more vulnerable under the worst circumstances (ie. if somebody got ahold of your password manager).
I feel like we might have a mismatch in understanding what a passkey is. You make a new keypair for each account to authenticate to. A leaked passkey is generally no more vulnerable than a password when leaked.
> But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.
Correct. The gold standard is a hardware secured, non-cloud synced private key.
> This is an HN forum. Nobody's giving "security advice,"
It's a technical forum with statements on a technical topic. Making statements like that can always be misinterpreted as technical advice by default.
> but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?
This is fair. The answer is: convenience. It is most definitely worse security posture to sync passkeys than to store them on a separate, physical device that can answer challenges without leaking the private key.
The reason to use them over passwords is they are more secure, even when synced to a cloud vault.
Thanks for helping to clarify what we're talking about. I disagree with some of what you're saying, but I also see where you're coming from re: the convenience of passkeys in your pw manager.
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.
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
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.
> 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.
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!
Because the security key doesn't store any public keys.
Basically, the security key stores a single symmetric key. It'll generate a public/private keypair on registration, encrypt it, and send it to the server. On authentication the server will return the keypair back to the security key, which decrypts it and uses the retrieved private key for authentication.
Yes, but that provides a significantly less secure experience. All the important cryptographic operations are done in a regular computer program rather than in a HSM, at that point why bother with the Yubikey at all?
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?
Because yubikeys were designed long before passkeys become a thing. And hardware people love cutting cost to the bare bone to save one cent of $50 device.
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.
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...
I’m really not sure the “only real solution” is every human needs to selfhost a password manager. That’s ill-advised; an extreme take.
The vast majority of the population will do a worse job on the availability and security of a selfhost solution than 1Password, whose core business and value proposition is password management.
I’m a very happy user of 1Password for Families and consider it the likely the best ~$50 a year that I spend on hosted technologies.
That's a fundamental problem with cryptographic security: you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) but you cannot trust yourself doing that either, because you can, and will, make mistakes.
I know how to do that in theory (I've worked with Shamir secret sharing on elliptic curves before) but you don't have the option to do that in LUKS, so in practice you can't use it.
My rule of thumb is if for some reason you need to use crypto keys that can't be easily replaced, you need to have a safe at the bank with the keys stored in 2 differente media formats, that are recreated every year.
I don't trust many people to do that.
I have everything encrypted and self hosted and I sometimes wonder what I would do if I was suffering from amnesia after an accident for example. And having a note somewhere telling me I have a safe in bank X is the only solution I have found.
> I have everything encrypted and self hosted and I sometimes wonder what I would do if I was suffering from amnesia after an accident for example.
Ah! I have the exact same recurring worry, it's very unpleasant. I'd really prefer to keep home media unencrypted, but the thought of a robber seeing my tax returns or photos of my infant daughter is constantly at the back of my mind.
> the thought of a robber seeing my tax returns or photos of my infant daughter is constantly at the back of my mind.
Even worse is the eventuality of them getting their hand of a picture of your ID card or passport, or whatever they can later use to steal your identity. Identity theft is nightmare stuff.
> [...] you cannot trust people to manage your keys for you (because due to lack of regulation preventing that companies have this bad habit of pulling the rug under their customers' feet) [...]
Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contracts that stipulate fiduciary duties, courts will enforce those contracts just fine.
As a technical alternative (or augmentation), you can also use a threshold secret sharing mechanism to store your keys amongst your friends and/or with companies.
Now what you can complain about is that there is no convenient way to do all of this. And that's a very legitimate complaint! Convenience is important.
However, the way to get convenience is not via regulation.
I'm not sure what you mean by 'despite all evidence'?
You can also write:
> The blind faith some people have in [regulation and government] despite all evidence always leaves me in awe.
In any case, markets ain't perfect. They are made of people, after all. But they are better than the alternatives. And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.
> The blind faith some people have in [regulation and government] despite all evidence always leaves me in awe.
The Western world and Asia is a pretty good evidence that government works. If you want the libertarian dream of no government, you can go to Somalia, or South Sudan, or Yemen, or whatever failed states you can think about.
> And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.
Oh sure you won't go to jail, but the alternative doesn't exists so you can't get it either. Like the convenient safe storage we both wish it existed.
In totalitarian dictatorship, you can't build such a tool without getting murdered or jailed, in totalitarian Capitalism you can build it but it will eventually be blocked from reaching any significant room on the market because of big corps or if you raise money from VC in order to get the marketing you need, it will eventually be bought out by one of the big player who will close or enshitify it.
The good alternative is what's called democracy, where the sovereign people vote for things instead of leaving the power to the party or the market.
I would definitely trust my lawyer with my bitcoin seed.
But the whole thing depends on how much you own in bitcoin.
If it's a whole lot, check how other people in more traditional domains are dealing with their lawyers or notaries handling these sums. (For one, it's a bit easier with bitcoin, because you don't need to tell your lawyer or notary what you are giving them. And you can encrypt the private key data with something derived from an easy to remember password. It doesn't need to be 100% cryptograhpically secure, it just needs to lower the temptation for your lawyer.)
Btw, I think the bigger problem in practice wouldn't be your lawyer stealing from you, but your lawyer somehow losing your data.
> Just leave your key with your lawyer or a notary
> […]
> However, the way to get convenience is not via regulation.
Fun fact: the reason why giving it to your lawyer or a notary works is exactly because of regulation regarding these professions. Without regulations, there would be no such alternative.
Feels. I had half a bitcoin on a disk that I left alone. Forgot about it. Reinstalled the OS. Three times. I was a sysadmin for years, but the cobblers' children go barefoot.
The whole original point of what underpins FIDO2 was device locked, unphishable credentials. Wanting to export and move passkeys between devices is kind of counter to that. And I would argue vendors completing the attestation process are much more trustworthy than storing your own keys god knows where.
Oh, ok. If that's the same thing as passkeys, then I finally figured out that I'm not interested. To me it looks like another vector for platform lock-in, or getting mysteriously locked out of my accounts with no recourse. I'll wait for FIDO3.
Yep. I absolutely refuse to support anything that wants to dictate what I do with my identity.
Such things do have purposes, in high-stakes environments. They prevent accidents. The vast majority of uses on the public web are not even remotely in that realm. It'd be better off being a separate spec that only a handful of internal-only systems use, ideally requiring MDM to set up conveniently (to strongly discourage normal and even high-stakes-normal website usage).
My banking website has absolutely no business knowing and being able to approve or deny what brand my authenticator is.
I also think that the "self-hosted" requirement is an over-reach. It would be sufficient to require some standardized commodity that can, in principle, be self-hosted, but is available in an equivalent form from multiple unaffiliated third parties. E.g., a WebDAV folder.
I disagree. While Vaultwarden may be a bit much to ask of the unwashed masses, the storage model of KeePass* is very easy to understand and works with any existing file synchronisation solution, which almost everyone already has at this point. The effort is nearly as low as with a cloud hosted solution, and the value/safety proposition is quite high.
Your vault is stored locally on each device, so if they decide to shut down you just export locally, import somewhere else and move on. It’s not as big of a deal as you seem to be implying.
Having the passwords in the cloud is useful though. Before, if you wanted to use your vault across multiple machines, you had to store your vault in someone else’s cloud. This simplifies the process.
> 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.
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.
I'm locked out of my Gmail and it still forwards to the recovery email address, but I can't get in to change the settings. They also won't allow me to download all my data, as required by statute, because I can't log in.
I've got some active GMail forwarding addresses that I haven't logged into for 10+ years. I don't think they could change how that worked now even if they wanted to.
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.
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.
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.
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.
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.
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
> 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.
Using a good old password means you don't rely on any particular service, period. Passkeys means you do, you rely on either a particular type of device (e.g. Apple device) or a SaaS.
It doesn't matter how many SaaSes offer it or how many brands of devices adopt it. It still means that for access to all of your accounts, you either 1. Have to stay with that brand of device or 2. Have to rely on the goodwill of the SaaS not to suddenly start raising their prices (the comparison here is passwords, which are free).
Before you say that switching providers is possible, that doesn't really matter. Let's say I stored the passkeys on my iPhone/iCloud. And then it got stolen.. whoops! Now I must at the very least acquire another Apple device until I can reach any of my accounts, i.e. I'm tech-dead until I do so.
If switching is not frictionless, it's an absurd level of lock-in, almost making it impossible. I have to go into every single account and add a new passkey? What if I forget one when I switch, then I'm out of luck and can never use the account again?
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...
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.
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.
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).
One big issue with this QR thing is that phone will need to talk via bluetooth to the PC. Like every PC comes equipped with bluetooth chip. Should be some kind of pin code instead.
No, it doesn't. There only communication is happening through the site. The site issues a challenge to the PC, the previously registered phone confirms to the site that the challenge is met, and from now on the site trusts the PC. The PC and the phone can be on different continents.
The problem though is that you have to do this for every single site you access. So if you have 100 log ins and are switching PC or phone, you'll have to do this same dance 100 times in the next period. And of course, if you're switching because you lost your one device that was registered this way...
Edit: everything I say below is not just wrong, but confidently wrong...
"Communicate over bluetooth" doesn't mean anything. What app or BT device would they be using? How would a PC communicate with a YubiKey over bluetooth?
I have no idea where you got this strange concept from, but registering multiple passkeys from multiple devices on the same account on a site requires no communication between the devices - it only requires a trusted device to approve the request.
That's how it works. You open Google Chrome on Linux, press "Log in with PassKey", scan QR with iPhone, then iPhone contacts Google Chrome via bluetooth to do its crypto magic (which doesn't work 50% of times) and may be it'll work.
> 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.
I have over 300 in my password manager, and I know there is no way for me to remember all do that, but when I travel I do like to have enough with me so if something happens I can get up and running again.
Once on vacation I shattered my phone. Only time that’s ever happened and I happens to be away from home. I was able to get a new phone at the local Apple Store, but the only reason I was able to get setup and running again was I happened to bring my iPad, by sheer dumb luck. Other than using it for 2FA to get my new phone setup, I didn’t use it at all.
In my most recent trip I brought my recovery key with me, and know my password for that 1 account. As long as I can get into that, I can get everything else setup from there. But I need someplace to start to make myself whole again. It seems like PassKeys make that more risky.
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)
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.
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.
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.
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.
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 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.
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.
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?
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'm referring to the process of switching where my passkeys are stored to a different place. E.g. moving from them being stored by Apple to them being stored by Google or any other provider.
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.
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.
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?
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).
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??
> 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.
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.
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
You can’t avoid these corporations if you want to remain active on the internet. They keep shadow profiles. They sell and share your data from one service to another (I stoped using Facebook for example, but Netflix shared its watch data with Facebook.)
I don’t think it’s possible to avoid them. Confuse them maybe.
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.
Probably because governments can just buy the corporate surveillance results, bypassing any shoddy protections that even exist completely. So corporate surveillance is government surveillance.
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.
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).
> 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.
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?
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.
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.
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.
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?
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?
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.
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.
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)!
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.
I’m a security engineer, I’m pretty fluent on the topic. And phishing comes in beyond the methods you describe -> malicious attachments downloaded, etc etc.
I do agree but in this discussion we're talking about the general problem of logging in to a website.
That's the case where phishing is the most devastating. Solving that problem is a huge step in making people's online lives more secure. Just because we didn't solve all problems, doesn't mean we shouldn't solve what we can solve. If you're a security engineer, it's your job to promote ways for people to be more secure online. And this is what I am trying to do myself.
The discussion you brought up is, which I object to:
> 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.
And I can point out several ways phishing is currently prevented without passkeys. And several ways it occurs without logins, such that it’ll still be around after passkeys. And phishing is difficult, but per defense in depth concepts, it is not the mission critical focus you label it as.
So to turn it back around, I don’t think you understand phishing threat vectors well haha.
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."
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, 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.
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.
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.
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.
They shouldn't be exactly like SSH keys. With SSH keys, you can go and copy/paste your private keys on a scammer's website because they asked you nicely. People will totally do it as they don't understand what they're doing.
The main thing with passkeys, and key dongles in general, is that you simply can't do that as the keys are inaccessible and you can only prove possession of a key when asked by a domain you've explicitly registered with (the proof-of-possession is never sent to any other domain than that which you registered with).
What OP says is that opens the possibility for key providers to lock-in users, as that seems like an unavoidable side-effect of the legitimate goal of preventing phishing (phishing is the biggest security issue today, to increase security means making phishing impossible, so I still support passkeys as the best solution for that).
There's a big difference between "can't just hit the copy button and paste in the key" and "can't export the key as part of a backup." Physically preventing users from ever accessing their own keys is an absurd user-hostile proposition. Even more absurd when the they're software keys stored in a database the user can decrypt. The FIDO alliance is just ensuring that password managers will require 3rd party backup tools to be useful.
Password managers have prevented phishing just fine by binding passwords to particular domains, ssh keys prevent phishing with IdentitiesOnly and passkeys are bound in the same way as regular password managers.
Any security solution that involves lay people having access to keys is NOT secure. What you call "absurd user-hostile" is actually basic security in the real world with non-technical people.
Technical people can already be secure using appropriate protections, but even for them it's very difficult to do it properly.
Lay people will, without understanding what they're doing, ask the password manager to give them their password to enter manually on any phishing website as they'll think that it's not working because it's "broken". So , absolutely no, password managers do NOT prevent phishing.
If you think I am exaggerating, well, I work with this and I assure you it's even worse than that.
There has been a pretty insane number of times I've asked someone for their SSH public key and I get a response of ---- BEGIN RSA PRIVATE KEY ----. From people employed in tech jobs. Now imagine someone who barely understands how to use a computer, they're an easy target to get their identity phished.
I don't think the answer to these problems building system that treats users the same as an attacker when it comes to accessing and backing up their own private keys. Because at the end of the day the ability to export your private keys and store them somewhere securely is the account recovery of last resort.
Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense. It's fine for Apple or Google to store your keys at your request and they should keep them secure but the model of "here's my key, now don't ever let me look at it but let me use it via what is effectively DRM" is silly.
If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key." isn't enough to stop people giving it away then no security was ever going to work for them. They would give away the credentials that lets them use the key in its absence.
> Because at the end of the day the ability to export your private keys and store them somewhere securely is the account recovery of last resort.
Or just have multiple passkeys for the same account. It doesn't matter if I lose the passkeys on my laptop because I've got other passkeys to those accounts on several other devices.
> Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense
Resident keys practically are HSMs, aren't they? None of my passkeys are backed up to a Google or iCloud account.
> If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key.
In those conversations with people who should be experts I usually made a point to tell them send me the public key and told them to never share the private. They still sent the public. People have been told to never share passwords either but I still often hear "yeah my password for this is blahblah123..." when asking for help.
I would say the exact opposite, traditional ssh key management should eventually give way to resident keys. Aka, treating them just like passkeys.
We've been storing ssh keys directly on our yubikeys since before passkeys were a thing.
Not only is it clearly more secure it's also been a usability lift. Plugin your yubikey, start an ssh agent, and run ssh-add -K to get all your resident keys added to your current session.
You should produce a key per device, and produce a backup key that is safely stored & not used anywhere.
You can recover if you lose all devices via your break-glass backup key, and you limit the blast radius of "my key got stolen" from rotating all your keys to just a single device (or maybe the more likely "I screwed up and pushed my key somewhere public")
... which is completely nonviable if you connect to more than a single service.
I agree that you should use a different key per device, but when you connect to over a dozen different services/machines it quickly starts to become a serious chore to add another key. Have fun spending an hour enrolling your new device - provided you can even remember every single usage it should be enrolled with.
Unfortunately SSH certificates have really poor uptake in practice, and it's essentially unheard of to have a personal CA instead of a per-company CA.
But yes, having a single long-living "primary key" everyone can trust which you'd use to generate short-living per-device "secondary keys" would indeed be the ideal solution.
Sure, but then limits you to a handful of keys. The WebAuthn people don't like this, they want one key per service, so basically YubiKeys no longer really work with WebAuthn (unless you're fine with only ever using a max of 25 services).
I understand this, but the person who responded said Passkeys are exactly the same as SSH and used the same, when asked what they are. If that was true, then we would just teach non-technical users to use 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.
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."
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.
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 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.
> 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.
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.
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.
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.
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.
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.
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.
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'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?
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.
> 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.
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.
791 comments
[ 2.8 ms ] story [ 564 ms ] threadThe 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?
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.
But the implication that Keychain just kind of forgets saved Passkeys once in a while seems alarmist and probably unfounded.
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.
So what happens if you want to migrate away from iCloud for the storage of passkeys?
This is not different at all from a SSH public/private key combo. You are not supposed to duplicate SSH keys!
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 could stop using my idevices tomorrow and not be negatively influenced.
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.
https://bugs.webkit.org/show_bug.cgi?id=270553
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.
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.
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.
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
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.
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.
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
- "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.
As for the medical costs - if you want to be on the safe side, you can (actually you should) get travel health insurance.
You have to read your insurance contract and info sheet properly rather than go for the lowest price.
Though you might need to get a US specific one. Mine contains a clause that specifically excludes the USA from coverage, and that’s not uncommon.
Note I live in London and everyone tells me I'm going to get stabbed too and die from the pollution...
That's an 0.006% chance of getting murdered killed in NY every year.
And that doesn't account for (a) putting yourself in a good position to get killed like being a gang member and (b) the aggregate reduction in risk by only travelling there.
Quite a few people don't want to deal with that.
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.
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)
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'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.
So, yeah, useless technology for now. Passwords and TOTPs are the way.
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.
If you store passkeys in hardware, then yes, passkeys are more secure, but you lose portability.
That's not correct. Passkeys use public-key cryptography and a challenge-response authentication mechanism, so an adversary in possession of a read-only copy of the database of the service you're trying to authenticate with won't be able to authenticate as you - which is very much a security improvement over passwords, even when both are stored in a password manager.
True, but GP is referring to the private key on the (user’s) device or computer being stored in a password manager. The main protection that passkeys offer in such a case is that there’s no case of passkey reuse across services and accounts, which is something that’s possible with passwords even if one used a password manager (albeit poorly by not generating unique passwords for each account).
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)
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.
In reality websites should not allow setting up a single passkey.
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.
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.
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.
To answer your question, "bamboo menu, Copy Item JSON" which I believe is turned on due to my "Preferences, Advanced, Show debugging tools" being checked. I actually did try the $(op item get --format=json $its_uuid) first but figured there was some sekrit env var or --fields some_horseshit that I needed to dig up and it was more energy than I wanted to spend for a HN comment
So, OT1H, what I send was half true - they are available for export but only after some hoop jumping and seemingly not in the official export packaging, which I suppose almost guarantees they will not "round trip" back into a Vault in any kind of disaster recovery scenario
It seems those 1Password jokers just get great thrills out of ensuring that anytime I have something to praise them for they ensure they have some user hostile stupidity ready and waiting to drive people away
The whole fucking point of a password manager, though, is to store and securely provide authn material while ensuring users can’t lose it… which necessarily includes ability to access it, and back it up.
It looks a LOT like passkeys and FIDO are, relatively effectively, backdooring what Google got beat to death for when they attempted to add “Web Environment Integrity” to browsers.
edit: But can I? I’m already questioning how hard it’s going to be, and if it’s feasible without a lotttt of hurt.
- 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.
...as long as you always keep buying apple.
I've not had a problem registering both this and my phone on any site.
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.
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.
That's the benefit you get from passkeys that no password manager will otherwise be able to give you.
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.
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.
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.
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?
With passkeys it's literally impossible.
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)
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.
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'd still recommend using a password manager, as overall and in practice the risk of phishing and (re)using (weak) passwords is far greater than this kind of rare vulnerabilities (and also I work for a company that makes a password manager ^^)
See https://lock.cmpxchg8b.com/passmgrs.html if you'd like to know more
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?
A password manager, OTOH, is happy to hand out your private key ("password" in this case) to anyone that has access to it.
I want to move my passkeys where I want and use tools I want.
Not allowing anyway of changing passkeys is terrible. Imagine someone switches from IOS to android. How do they use their passkeys?
Even if they had a big “warning don’t do this” sign it would be better than not allowing it in anyway.
Who says you can't change your passkeys? Just log into the site with your existing passkey (or other 2FA) and change it.
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.
The value of these seem very low. Passkeys are a solution looking for a problem.
Mayve 10 years ago before password managers became a thing they made more sense? Now they're just kind of annoying and hard to share (sharing passwords is a real need for many people /applications / services)
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.
Sure the do. All somebody needs is the password to your password manager. It's a single point of failure and by putting your passkeys in there to you've made it even more vulnerable.
Do you put a passkey on your password manager that exists outside of that ecosystem? Once you have that why not just use it for everything?
The parent wasn't giving security advice. They were asking a valid question.
Not more vulnerable than if they were just using password. You're still missing my point, password managers do not give you the ability to just copy-paste the private key of a passkey into a form field, unlike passwords. Some don't give you access to it at all (*cough* Apple *cough*). Sure you can get the private key if you have access to the password managers vault, but that's not what's being talked about. Common usage patterns matter immensely in security. At the end of the day, the attack surface for passkey-based authentication is smaller than password-based authentication, which is a step in the right direction.
> The parent wasn't giving security advice. They were asking a valid question.
The parent made a blatantly false and dangerous statement and then followed it up with a question. Did we read the same comment?
I also agree that passkey-based authentication provides a smaller attack surface than purely password-based authentication.
But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.
This is an HN forum. Nobody's giving "security advice," but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?
I feel like we might have a mismatch in understanding what a passkey is. You make a new keypair for each account to authenticate to. A leaked passkey is generally no more vulnerable than a password when leaked.
> But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.
Correct. The gold standard is a hardware secured, non-cloud synced private key.
> This is an HN forum. Nobody's giving "security advice,"
It's a technical forum with statements on a technical topic. Making statements like that can always be misinterpreted as technical advice by default.
> but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?
This is fair. The answer is: convenience. It is most definitely worse security posture to sync passkeys than to store them on a separate, physical device that can answer challenges without leaking the private key.
The reason to use them over passwords is they are more secure, even when synced to a cloud vault.
The big tech companies (Google, Apple, MS) have all become evil.
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.
https://github.com/keepassxreboot/keepassxc/issues/8228
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
Basically, the security key stores a single symmetric key. It'll generate a public/private keypair on registration, encrypt it, and send it to the server. On authentication the server will return the keypair back to the security key, which decrypts it and uses the retrieved private key for authentication.
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.
I don’t get what the issues people have really are. I never experience them (fortunately!).
Now if we could just get the other providers that require insecure email/SMS 2FA to follow suit, that would be great...
Does it work well?
The vast majority of the population will do a worse job on the availability and security of a selfhost solution than 1Password, whose core business and value proposition is password management.
I’m a very happy user of 1Password for Families and consider it the likely the best ~$50 a year that I spend on hosted technologies.
This way you don't need to trust any single one of your friends to be 100% honest nor 100% available.
you could rsync files before you could Dropbox too, but there was still a need for a Dropbox.
I don't trust many people to do that.
I have everything encrypted and self hosted and I sometimes wonder what I would do if I was suffering from amnesia after an accident for example. And having a note somewhere telling me I have a safe in bank X is the only solution I have found.
Ah! I have the exact same recurring worry, it's very unpleasant. I'd really prefer to keep home media unencrypted, but the thought of a robber seeing my tax returns or photos of my infant daughter is constantly at the back of my mind.
Even worse is the eventuality of them getting their hand of a picture of your ID card or passport, or whatever they can later use to steal your identity. Identity theft is nightmare stuff.
Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contracts that stipulate fiduciary duties, courts will enforce those contracts just fine.
As a technical alternative (or augmentation), you can also use a threshold secret sharing mechanism to store your keys amongst your friends and/or with companies.
Now what you can complain about is that there is no convenient way to do all of this. And that's a very legitimate complaint! Convenience is important.
However, the way to get convenience is not via regulation.
It is, because no company is ever going to give you the convenience you want at their own expense ;)
You can also write:
> The blind faith some people have in [regulation and government] despite all evidence always leaves me in awe.
In any case, markets ain't perfect. They are made of people, after all. But they are better than the alternatives. And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.
The Western world and Asia is a pretty good evidence that government works. If you want the libertarian dream of no government, you can go to Somalia, or South Sudan, or Yemen, or whatever failed states you can think about.
> And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.
Oh sure you won't go to jail, but the alternative doesn't exists so you can't get it either. Like the convenient safe storage we both wish it existed.
In totalitarian dictatorship, you can't build such a tool without getting murdered or jailed, in totalitarian Capitalism you can build it but it will eventually be blocked from reaching any significant room on the market because of big corps or if you raise money from VC in order to get the marketing you need, it will eventually be bought out by one of the big player who will close or enshitify it.
The good alternative is what's called democracy, where the sovereign people vote for things instead of leaving the power to the party or the market.
Would you really trust your lawyer with your bitcoin seed? If they stole everything from you, how would you even prove it?
But the whole thing depends on how much you own in bitcoin.
If it's a whole lot, check how other people in more traditional domains are dealing with their lawyers or notaries handling these sums. (For one, it's a bit easier with bitcoin, because you don't need to tell your lawyer or notary what you are giving them. And you can encrypt the private key data with something derived from an easy to remember password. It doesn't need to be 100% cryptograhpically secure, it just needs to lower the temptation for your lawyer.)
Btw, I think the bigger problem in practice wouldn't be your lawyer stealing from you, but your lawyer somehow losing your data.
Fun fact: the reason why giving it to your lawyer or a notary works is exactly because of regulation regarding these professions. Without regulations, there would be no such alternative.
Whether or not you can import them into something else though…
Such things do have purposes, in high-stakes environments. They prevent accidents. The vast majority of uses on the public web are not even remotely in that realm. It'd be better off being a separate spec that only a handful of internal-only systems use, ideally requiring MDM to set up conveniently (to strongly discourage normal and even high-stakes-normal website usage).
My banking website has absolutely no business knowing and being able to approve or deny what brand my authenticator is.
[1] https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
They used to offer their apps offline and you could "host" it anywhere. Venture Capital ruined them.
1Password has fallen hard from their earlier excellence.
BitWarden is open source to a large degree and even provides an (open source) server for self-hosting.
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.
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.
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 dark pattern about signing up for google pay is absolutely inexcusable though. Sorry you're going through that.
I believe those transactions are never confirmed and are reverted after 7 days or something like that
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.
There are choices.
It doesn't matter how many SaaSes offer it or how many brands of devices adopt it. It still means that for access to all of your accounts, you either 1. Have to stay with that brand of device or 2. Have to rely on the goodwill of the SaaS not to suddenly start raising their prices (the comparison here is passwords, which are free).
Before you say that switching providers is possible, that doesn't really matter. Let's say I stored the passkeys on my iPhone/iCloud. And then it got stolen.. whoops! Now I must at the very least acquire another Apple device until I can reach any of my accounts, i.e. I'm tech-dead until I do so.
If switching is not frictionless, it's an absurd level of lock-in, almost making it impossible. I have to go into every single account and add a new passkey? What if I forget one when I switch, then I'm out of luck and can never use the account again?
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
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.
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).
The problem though is that you have to do this for every single site you access. So if you have 100 log ins and are switching PC or phone, you'll have to do this same dance 100 times in the next period. And of course, if you're switching because you lost your one device that was registered this way...
"Communicate over bluetooth" doesn't mean anything. What app or BT device would they be using? How would a PC communicate with a YubiKey over bluetooth?
I have no idea where you got this strange concept from, but registering multiple passkeys from multiple devices on the same account on a site requires no communication between the devices - it only requires a trusted device to approve the request.
No idea how Yubikey works, never used it.
Because surely such devices never get stolen, or dropped from a cliff.
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.
Once on vacation I shattered my phone. Only time that’s ever happened and I happens to be away from home. I was able to get a new phone at the local Apple Store, but the only reason I was able to get setup and running again was I happened to bring my iPad, by sheer dumb luck. Other than using it for 2FA to get my new phone setup, I didn’t use it at all.
In my most recent trip I brought my recovery key with me, and know my password for that 1 account. As long as I can get into that, I can get everything else setup from there. But I need someplace to start to make myself whole again. It seems like PassKeys make that more risky.
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.
- 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)
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.
But I do agree with the point that Passkeys make it really easy to get locked in unless you’re careful.
But then I have the analogous problem of never being able to switch password managers!
The idea isn't to move your keys around willy nilly the idea is that should you need to, you're not beholden to bitwarden inc.
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.
There’s no way I’m doing that for each of them (or figuring out which ones support passkeys).
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.
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.
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?
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.
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.
Your passkeys sync in iCloud they aren’t device bound, just platform bound. Passkey export import is being worked on.
As I understand it the workflow would be: * get a new passkey * enroll the new passkey with all existing services * unenroll the old passkey with all existing services
That is certainly onerous for the "can my mom do this?" test. Like, I'm not even sure I want to deal with this myself and I have a Solo key (in a box).
Further, seems any service I'd want to protect with a passkey, is also a service that would be very difficult to lose access to, should I lose the passkey (or it fails). Therefore I need to enroll two passkeys with each service, to have one as a backup.
Uhh, OK. So now if I were to change passkey vendors/services - it's enroll two replacements, unenroll two? I haven't ever done this so maybe it's not as onerous as it sounds?
I wonder if it means that the author will stop working on the library after their next release, and more importantly, if the UX is going to be horrible with people unable to log in and other issues they mention.
On a tangent, I share their discomforts about travelling to the US. The last time I was there, I felt uncomfortable being out on the streets alone. Maybe the portrayal of police brutality towards POC is a factor (for me).
Just FYI it seems the library will still be maintained: https://infosec.exchange/@firstyear/112337225055591544
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??
Actually, I think it might be worse. The predators like Apple/Google have already pounced on passkeys as a consumer capture mechanism, so they'll ensure it doesn't fail.
I was sceptical about something-you-own auth vs. something-you-know auth from the beginning and recieved backlash from my tech peers for it. I hate to be able to go "told you so" on this one. Lets hope im wrong about the government involvement, but i dont think i will.
You cannot avoid the government.
I don’t think it’s possible to avoid them. Confuse them maybe.
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.
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.
- credit card sized
- completely airgapped
- standardized
- controlled by a non-profit association
- hard- and software open sourced
- built-in camera to scan data
- built-in display to show data
- configuration mode: scan human-readable configuration
- data is QR code or something like Base58 to copy by hand
- backup by supporting applications: scan and print out data
- browser integration by an extension using a webcam
https://en.wikipedia.org/wiki/OpenPGP_card
In fact the Estonian Id-Card is one of these if I'm not mistaken
I'm trying to follow the developments in the 2-factor-auth space and this was one thing that confused me a lot. I've read a lot of hype on Passkeys being the next big thing but it was really hard to find an actual explanation what they are and how they work. And once I found out that these are keys that are stored on the security key, I was rather disappointed, because I really like the idea of generating keys on the fly based on the domain name that I'm authenticating against. This way I can "store" an infinite number of keys. The upside of Passkeys is supposedly that you do not need to remember which username you have on a website, but I think that's a minor upside.
Related question: What is the official name for the (FIDO2-based?/WebAuthn-based?) technology that calculates and reconstructs keys on the fly based on the domain name of the service that I'm authenticating against? It is really difficult to learn the right terminology in the area.
Edit: I think I found the answer here: https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-tu...
A key that is reconstructed on the fly is called a "non-resident credential".
You could do it on a USB cryptoprocessor, and securely, too. https://tillitis.se/
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.
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.
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.
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?
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.
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.
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)!
If passkeys are around, phishing will certainly still exist, and shift to dropping malware on endpoints or w/e vs going after logins
Your attack only works on people who basically "trust any website" at all. For those, yeah there's no salvation.
> 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.
And I can point out several ways phishing is currently prevented without passkeys. And several ways it occurs without logins, such that it’ll still be around after passkeys. And phishing is difficult, but per defense in depth concepts, it is not the mission critical focus you label it as.
So to turn it back around, I don’t think you understand phishing threat vectors well haha.
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."
> 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.
I think it's totally reasonable, and probably a good thing for users having to use their username at login. Especially as it reminds them what username they are using for that service.
I could totally see a situation where a user uses a Usernameless passkey for years to access a service and for some reason loses access to the Usernameless passkey, and then has also forgotten the username for the service, so cannot even start an account recovery process.
I think it depends on the service. But aside from the occasional forum or social site, usernames are just an extra step. I don’t want or need one for banking/administration/ordering a product. For better or worse, email is usually a better identifier, assuming you already need one for other reasons (like you say recovery is typically needed).
> Especially as it reminds them what username they are using for that service.
Like passwords, forced usernames are hard to remember, if you use different ones. If you use the same, then it leaks privacy across services. (Technically usernames can be private but the expectation from decades of social sites is they are public)
> […] loses access to the Usernameless passkey, and then has also forgotten the username for the service
Correct, no identifier at all can’t be recovered. Hence, email.
If you remember which one you signed up with, and it wasn't your work email from two jobs ago.
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 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.
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.
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.
Password managers have prevented phishing just fine by binding passwords to particular domains, ssh keys prevent phishing with IdentitiesOnly and passkeys are bound in the same way as regular password managers.
Technical people can already be secure using appropriate protections, but even for them it's very difficult to do it properly.
Lay people will, without understanding what they're doing, ask the password manager to give them their password to enter manually on any phishing website as they'll think that it's not working because it's "broken". So , absolutely no, password managers do NOT prevent phishing.
If you think I am exaggerating, well, I work with this and I assure you it's even worse than that.
There has been a pretty insane number of times I've asked someone for their SSH public key and I get a response of ---- BEGIN RSA PRIVATE KEY ----. From people employed in tech jobs. Now imagine someone who barely understands how to use a computer, they're an easy target to get their identity phished.
Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense. It's fine for Apple or Google to store your keys at your request and they should keep them secure but the model of "here's my key, now don't ever let me look at it but let me use it via what is effectively DRM" is silly.
If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key." isn't enough to stop people giving it away then no security was ever going to work for them. They would give away the credentials that lets them use the key in its absence.
Or just have multiple passkeys for the same account. It doesn't matter if I lose the passkeys on my laptop because I've got other passkeys to those accounts on several other devices.
> Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense
Resident keys practically are HSMs, aren't they? None of my passkeys are backed up to a Google or iCloud account.
> If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key.
In those conversations with people who should be experts I usually made a point to tell them send me the public key and told them to never share the private. They still sent the public. People have been told to never share passwords either but I still often hear "yeah my password for this is blahblah123..." when asking for help.
We've been storing ssh keys directly on our yubikeys since before passkeys were a thing.
Not only is it clearly more secure it's also been a usability lift. Plugin your yubikey, start an ssh agent, and run ssh-add -K to get all your resident keys added to your current session.
You can recover if you lose all devices via your break-glass backup key, and you limit the blast radius of "my key got stolen" from rotating all your keys to just a single device (or maybe the more likely "I screwed up and pushed my key somewhere public")
I agree that you should use a different key per device, but when you connect to over a dozen different services/machines it quickly starts to become a serious chore to add another key. Have fun spending an hour enrolling your new device - provided you can even remember every single usage it should be enrolled with.
AFAIK there is no equivalent for Passkeys.
But yes, having a single long-living "primary key" everyone can trust which you'd use to generate short-living per-device "secondary keys" would indeed be the ideal solution.
So basically we've been storing ssh keys directly on yubikeys the same way passkeys are stored since before passkeys were a thing.
It seemed a clearly superior option compared to letting ssh private keys roam around on random computers.
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.
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.
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.
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.
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.
Use a passkey on https://www.passkeys.io and it works great! On google too. But use it on PayPal, it does not anymore. Who’s to blame?
How can it be that the website decides which password manager I should use to store the passkeys? That's crazy and goes against all intuition.
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.
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.
Google tries to force use of passkey now that if you enroll a Yubikey it will now be a Passkey, instead of a second factor. With no option to disable it. I have to run the Yubikey Manager tool and then disable "FIDO2", so that I can force it only be used as a 2nd factor.
This will cause a fallback to FIDO/U2F where possible and your browser will appear to not support FIDO2. I've observed this with the default Keycloak flow for Security Tokens. May be a bug, too...
I don't know if this works with Google but if you try it, let me know :)
This needs no restart of Firefox, so you can use it to quickly disable it instead of fully disabling it on your Hardwaretoken.
Why?
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?
> 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.
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.
Well, not as secure as a commercial key, because the Pico doesn't have encrypted storage, but still much more secure than login/password.
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'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.
They explicitly do not.
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.
So yes, I believe your requirements are met in practice.
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.
[1] https://github.com/w3c/webauthn/issues/1255