Signing into my accounts on my children’s devices has turned from a straightforward process to an incredibly frustrating experience. I find myself juggling all kinds of different apps and flows.
This strikes home for me, I'm the main gatekeeper of passwords and service accounts in my home. 2FA and passkeys are so annoying to juggle.
My kids use prepaid numbers, once I changed one and forgot to tell Apple, when I realized that I needed the old number later, it took me a month at least to get it back.
I really like passwords, the security risks are well known and really easy to handle compared to 2FA and all that crap, specially when 99% of your accounts are not sensitive enough to merit anything fancy.
teekert · 1h ago
I’m on proton (family) and put pass on all devices (inc the kids’) so I can quickly share credentials. But still, I agree that some kind of export of private keys is sorely needed.
ajsnigrutin · 3h ago
Passwords + OTP (stored in keepass or somewhere) is the win for me.
Everything else is a security theatre and an UX pain.
xeonmc · 1m ago
I use my OTP secret as my account password, best of both worlds for portability!
nixpulvis · 2h ago
This is how I feel as well.
adiabatichottub · 4h ago
It makes sense to keep printed backups of certain keys and passwords in a physically secure location, accessible to the people you trust in case of an emergency.
lixtra · 2h ago
You might even split them so that k out of n trusted people are needed to restore them.
Yes, I think that's a good idea for high-value secrets. In a family situation it would be a great way to limit elder abuse (unless all your children hate you).
toomuchtodo · 4h ago
Passwords are a weak authentication mechanism and incur liability. MFA is good, Passkeys are better. One time passwords via email are tolerable, still better than passwords.
(customer identity and access management is a component of my work at a fintech)
OJFord · 4h ago
Your fintech is probably not among the 99% accounts GP says don't warrant 'anything fancy'.
IME as a customer/user, financial institutions are some of the worst culprits for doing appalling things in the name of security (theatre) anyway.
tadfisher · 4h ago
Yes, because financial institutions are responsible for losses incurred via account takeover.
jazzyjackson · 32m ago
And yet they are still out here offering voiceprint authentication
AlexandrB · 4h ago
And yet no financial institution in Canada supports webauthn hardware tokens - instead choosing to bake their own scheme within their app or use SMS.
cuu508 · 4h ago
Security-wise, passkeys are worse than username/password plus WebAuthn as the second factor.
tptacek · 4h ago
But better than username/password + TOTP, and username/password + WebAuthn had really low uptake.
AlexandrB · 4h ago
Username/password + TOTP is still better than username/password + one time email, no? Especially since the latter creates additional dependencies/risks for the user in the form of an email account.
tptacek · 3h ago
They're about the same. The important factor is phishing resistance (neither TOTP nor email links have that), and an account that has lost its primary email account is 99% of the time already boned. I would use TOTP in preference to email backup, but that's mostly an affectation.
The reality is that TOTP has been obsolete for awhile now. It's a net negative for ordinary users that is kept front-of-mind for everyone because nerds like us are attached to it.
jrochkind1 · 3h ago
This is actually the first I've heard of this, re considering TOTP to be not worthwhile. Can you recommend some links to material for me to read to get up to speed with the argument?
tptacek · 1h ago
Basically everything ever written about U2F, WebAuthn, and phishing-proof authentication generally is about the weaknesses of TOTP. The principle component of the problem is phishing.
kriops · 4h ago
If and only if you somehow manage to compromise one secret without compromising the other.
bradley13 · 4h ago
This. All of this. Passkeys are a great idea, but the walled gardens are a huge problem. Also, services placing additional requirements (e.g., attestations) that potentially violate your privacy and anonymity.
Just now, at least in Europe, there is a huge push to force users to authenticate themselves with their actual identity, even for ordinary Internet services. This is happening simultaneously in many countries (including non-EU countries like Switzerland). It almost has to be a coordinated effort....driven by whom? Passkeys play into this.
Call me paranoid...
unsnap_biceps · 4h ago
The walls are going to come down. KeyPassX supports passkeys and allows you to export them as you wish. 1Password and Apple Passwords have both said they're going to support exporting and importing of passkeys.
Yes, it's awful during the transition period while the tech matures, but there is a path towards a great future.
akazantsev · 3h ago
> KeyPassX supports passkeys and allows you to export them as you wish.
The last time I tried to use passkeys, the desktop was easy. What about mobile? There wasn't a local third-party password manager that could work with passkeys on Android.
unsnap_biceps · 53m ago
Unfortunately KeyPass is pretty fragmented on mobile devices, but there is https://strongboxsafe.com and https://keepassium.com for IOS with passkey support, but I don't know what options there are for Android, but I suspect there are somewhere.
lurking_swe · 2h ago
> There wasn't a local third-party password manager that could work with passkeys on Android.
sounds like you found yourself a market opportunity…
akazantsev · 1h ago
The only thing I found is that I'm entirely disinterested in passkeys for the next 5 years.
DavideNL · 2h ago
…and do you think we can trust Big Tech on their promises, based on their reputation / recent news events?
palata · 1h ago
Walled gardens are a huge problem, but they are orthogonal to passkeys. We have had walled gardens for a loooong time already. We should fight them, I agree.
But passkeys are just a way of democratising private keys instead of passwords.
Sure, there will be examples of walled gardens leveraging passkeys. But we have plenty of examples of walled gardens that don't need passkeys at all. It's a different problem.
bmandale · 5h ago
> An attempt by an open source password manager to provide export of private keys was ruled insecure and should not be supported.
The name of the issue reveals the actual problem: "should never be exported in clear text". If the export was encrypted with a passphrase in a standard format, then there would be no issue. It's specifically doing it in plain text that causes consternation. Of course, in practice it doesn't make much of a difference when users are incapable of choosing secure passwords, let alone passphrases. But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports.
> For many years already, people lose access to their Google account every day and can never regain it. Google is well known for terminating accounts without stating any reasons. With that comes the loss of access to your data. In this case, you also lose your credentials for third-party websites.
In practice this is frequently already true. Many sites require an email to sign up. Whenever you attempt to log in on a new device, they require you to type in a code sent to your email. Without access to your email, you cannot sign in.
tuckerman · 5h ago
Where is the line exactly though? If the password manager put up a big red notice when trying to export in plain text is that enough? If not, why not?
I am sympathetic to the intent but the words of Patrick Henry come to mind too often in conversations like these. I love passkeys and appreciate secure defaults but I feel strongly that user freedom is a more fundamental requirement than preventing phishing attacks.
AndrewDucker · 2h ago
Because many end users will ignore that. And this technology is set up to prevent end users from hurting themselves, even if that constrains technologically capable ones.
tuckerman · 10m ago
My values are such that it’s inappropriate for a few folks at companies and random consortiums to make that decision on behalf of all society.
If KeepassXC wanted to enforce that world view for the safety of their users, it’s their right, but this is essentially a threat of blacklisting an entire password manager for adding a feature demanded by their users (who likely predominantly used by technically savvy users at that).
AlotOfReading · 5h ago
But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports.
Why is the protocol dictating the user's security model? I can see why particular applications wouldn't choose to support insecure exports (and would even agree with that), but I genuinely don't understand why the protocol is dictating that an application can't allow users the freedom to choose their own security model. The same issue exists with HSTS, which I've found infuriating when the system is obviously wrong and I have to resort to absurd workarounds as a user because the application is handicapped from giving me an "ignore this" button.
Moreover, "just" password protecting a file isn't allowed by the draft CXP standard (https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html#...), you have to use a HPKE scheme where the key exchange is manually orchestrated by the user to export offline. I get it from a security perspective, but that's stupid.
tadfisher · 4h ago
The other side of this is the Relying Party, a.k.a. the website operator that is relying on the user's password manager to be decently secure and resistant to phishing. Otherwise, why ditch passwords plus 2FA?
AlotOfReading · 4h ago
The website already has guarantees against phishing because those are enforced by the managers. What's prevented is the snooping case of taking an export and cloning it without the exporting manager being involved. This is essentially indistinguishable from many legitimate use cases like archival or access to deceased relatives' credentials, which users might want regardless of the website's preferences.
tadfisher · 4h ago
> The website already has guarantees against phishing because those are enforced by the managers.
There is no such guarantee if credential-stealing malware can export your private key material in plaintext!
AlotOfReading · 3h ago
If the malware can orchestrate the managers, why wouldn't they simply use that power to orchestrate the offline export as they were going to do anyway? The RP ID makes the process a bit noisy, but it doesn't seem to change the fundamental vulnerability for the credential owner.
dan-robertson · 4h ago
What do security professionals think about passkeys? In particular, those who were not involved in designing them. Lots of the arguments in this article feel very much like the sort of thing one would expect from someone into open source (not saying they are wrong, and I think they are well explained here) but I feel they will inevitably be the product of different concerns than those a security practitioner might have.
tadfisher · 4h ago
I helped implement support for passkeys in a banking product. They obviate so many attack vectors and adoption is high enough that it should be a requirement to at least support them.
We already require TOTP-based 2FA, and have even implemented secure TOTP via our mobile apps. Customers still do not understand 2FA and probably never will; we regularly have customers request 2FA resets after using their 10 backup codes. SMS- or email-based 2FA is a no-go.
We don't require hardware attestation, as that is the recommendation of the FIDO alliance and Google/Apple/Microsoft. It doesn't make sense to cut out iCloud/Google-synced passkeys given the clear security benefits over passwords+2FA.
Keep in mind that for our service, we regularly see attackers set up copycat sites to phish user credentials, and pay for Google Search ads to appear before our site in search results. These phishing attempts are sophisticated and customers will send their 2FA codes through them. _This is impossible with passkeys._
tptacek · 4h ago
Security people are generally pretty positive on Passkeys. Eliminating passwords has been the white whale of information security for over 3 decades. Practitioners are generally positive about FIDO2 (Yubikeys are fetish objects for them). I think message board people would probably be surprised at security practitioner attitudes towards Apple and Google authentication lock-in (locking my team into Google authentication would be one of my first moves at a new firm, and that's not an idiosyncrasy of mine so much as me doing what other CISO-types all say they do).
No comments yet
arccy · 1h ago
Pretty much everyone likes them? Nobody likes passwords, especially passwords by users. Passkeys essentially force the users to have some sort of password manager, whether third party, or OS / browser integrated. Plus they're unphishable in normal use.
They're technically weaker than password + hardware key but stronger than anything else, including password + totp. Google Advanced Protection still wants you to have a hardware key for your account.
vaylian · 2h ago
I think hardware keys are the best option for passkeys, because they have a separate (physical) user interface compared to software-based keys. This makes it easier to understand the login process. You physically interact with the hardware key to confirm that you want to log in. And you can use your key for many different accounts.
The downside is of course that hardware keys are typically not cheap and you should also buy a backup key. Another unnecessary downside is that certain companies like Microsoft require the use of resident keys, which take up storage space on the hardware key. The better alternative is non-resident keys, of which you can have an infinite number on your key.
jcmontx · 4h ago
One day Authy for desktop was deprecated and all of a sudden I was forced to always have my smartphone with me, which I was struggling to replace with a dumbphone. To this day, I have no way out of owning an smartphone for this very reason
psanford · 4h ago
I assume you were using Authy desktop for TOTP? You don't need a smartphone for storing TOTP seeds or generating TOTP codes.
jcmontx · 4h ago
Indeed, but I have like 40 different cloud providers, social networks and SaaS' which would be a pain to migrate
palata · 2h ago
I understand, but 40 doesn't sound too bad. When I moved from gmail to my custom domain, I had more than that to migrate. I just did it one at a time over a few months.
Same when I got my Yubikeys: I gradually moved the OTP seeds to them, wasn't that painful.
dwedge · 2h ago
It's worth doing specifically because you can't be sure twilio won't do a second rug pull for mobile
cuu508 · 4h ago
Are there many sites that only support Authy's push authentication and nothing else?
jcmontx · 3h ago
No, not really, it's about migrating/restoring every single 2FA key would be extremely inconvenient
arp242 · 3h ago
TOTP should just be a (typically base32) secret string; I don't know if Authy allows exporting that though (and if not, that only underscores the point of this article).
I just use a simple shell script with dmenu/xclip/oathtool:
The Passwords app in macOS 26 and iOS 26 support exporting passkeys to other password managers.
skybrian · 4h ago
It’s been announced but there’s no release date yet, in case anyone is wondering why they don’t have it.
ezfe · 3h ago
The export/import function is present in the public beta
hbn · 2h ago
iOS 26 and macOS 26 will likely be released this month or next.
alphazard · 5h ago
Unfortunately the tech community is full of people who pride themselves on being aware of and advocating for the latest standard put out by whatever company. That's how we end up with lots of complicated nonsense like most of what is sent in HTTP headers, or the contents of a TLS certificate.
On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.
This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.
alphazard · 4h ago
The complexity is unwarranted. The only thing that needs standardizing is how to hand over public keys (SSH format works fine), and what to sign to prove identity.
Everything else about managing which public keys are for what does not need to be decided in a standard. The users can choose whatever key management solution works best for them. What those links get at is a problem of key management. A single set of keys, where you send all of them to every server all the time, is a bad strategy.
palata · 3h ago
> On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse.
Ever tried to SSH with a security key... through FIDO2? Or would you say that having your private key as a file on your computer is strictly better than having it in a security key? :-)
yomismoaqui · 5h ago
All developers pass this magpie phase [1] and as you get older you start to see new things more critically.
I guess a desirable trait of seniority is to balance the urge to play with new toys vs the feeling that sometimes we are running in circles, repeating the same mistakes with different tech.
I’ll add that eventually it’s less about what I want and more about what would work for other people I know. Many of them aren’t very technical.
What do you need to do to keep family from (a) not getting locked out and (b) not getting phished?
palata · 3h ago
Are you trying to say that security keys are not a good thing? I love security keys, that's my one example of a good technology.
shreddit · 5h ago
Unfortunately the tech community is full of people who pride themselves on speaking for everyone and telling everyone to stop having fun with new tech because their solution is the best. And the one only truth.
karmarepellent · 5h ago
> Signing in is cryptographically signing a commitment to the current ephemeral tunnel.
I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding?
Aside from the wonderful possibilities that are offered by using port forwarding of some kind, you could also simply use OpenSSH's ForceCommand to let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service).
I guess no one uses SSH for authentication in this way because it is non-standard and kind of shuts out non-technical people.
alphazard · 4h ago
> authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding?
No, it's just how you authenticate with signing keys. Given that a secure channel has been set up with ephemeral keys, you can sign a commitment to the channel (like the hash of the shared secret key) to prove who you are to the other party.
> let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service)
This is exactly what I recommend. If everyone did this, then eventually then the browsers or 1password could support it.
palata · 2h ago
The thing is, if you want to use SSH with a secure element, suddenly you're using FIDO2, right? OpenSSH already supports it.
And WebAuthn is using FIDO2, it's not that different, it's just that WebAuthn adds some stuff like a relying party.
manithree · 4h ago
Not just non-technical people, but a lot of Windows developers I've worked with over the years can't seem to grasp the asymmetric key concept enough to use it for git (and then complain about git over over https).
Being in charge of the strength and security of your private key is something most people don't want to do, so we get multiple identities made "easy" by walled gardens getting popular in passkeys.
adiabatichottub · 4h ago
@alphazard, what are your thoughts on using self-signed X.509 certs, since 95% of the infrastructure is already there?
alphazard · 4h ago
I'm opposed to using certs where public keys will do. Certificates especially X.509 are more complicated than the public keys that they reference. They include things like domain names, serial numbers, version numbers, etc.
The complexity of X.509 belongs in the domain name system. If a bunch of large corporations want to come up with complicated formats so they can decide who gets to call themselves what on the internet, let them do that, but don't let them complicate basic security for the rest of us.
The experience to beat is swapping SSH keys. 95% of developers have setup access to a new machine using SSH. That should be the default experience for authenticating on the internet, and anything more complicated should be strictly opt-in.
adiabatichottub · 3h ago
Yes, I agree much of the added complexity isn't necessary, but since TLS is a common and widely used protocol for just about everything other than SSH, it seems like it would be easier to plug in.
Edit: or put another way, why should I have to load another library for PKA when I already have one that works just fine?
turtlebits · 3h ago
"Solved" doesn't mean anything unless you have implementation/adoption.
palata · 2h ago
And it's just not true: ever wondered what those fingerprints are that nobody cares about and blindly goes for "yes" in SSH? The vast majority of SSH users would have no idea if they got MitM-ed.
WebAuthn helps prevent just that.
01HNNWZ0MV43FF · 5h ago
> Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.
How do I sign in from multiple computers?
alphazard · 4h ago
There are multiple solutions to this, with tradeoffs. Doesn't change the fact that the service should only want a public key, and you should only give the service a public key. That's where this new complexity is being forced on users and developers. You need to be able to sign in, or let your users sign in, but you can choose how complicated of a key management strategy to have.
You can either have 1 key pair per service and sync them with something like 1password. Or you can have 1 key per service per device. Keys that never leave the device is usually considered more secure (and I agree for what I consider my threat model to be).
Important services like primary email, your bank, or cloud platform should probably do 1 key per device. Everything else benefits from the simplicity of 1 key per service with the keys synced.
tadfisher · 4h ago
You are describing passkeys. All of this applies to the passkey scheme.
Actually, a benefit of passkeys is the standardization of client-side cross-device authz operations via caBLE and similar; your secret keys never leave your primary device, but are usable from other devices over a variety of transports.
alphazard · 4h ago
> All of this applies to the passkey scheme.
It also applies to SSH keys.
I never said that passkeys couldn't do everything SSH keys can do.
My criticism is that they are more complicated to do the same thing.
This is exactly what not valuing simplicity looks like.
palata · 1h ago
A passkey uses FIDO2, which asks you to sign a challenge. If you use OpenSSH with a security key, it will... use FIDO2. If you use OpenSSH with a private key on your computer, you also sign a challenge, right? So it's not less complicated.
WebAuthn just adds a few things like the relying party and a counter (that nobody seems to use). And the relying party helps preventing phishing, which SSH doesn't do really well in practice (most people don't use SSH certificates and don't check the server fingerprints).
So it's just not true that passkeys are more complicated to do the same thing.
karmarepellent · 4h ago
A service that lets you sign up by uploading a SSH public key could just as well let you upload multiple public keys in your profile to be able to connect from other devices.
tadfisher · 4h ago
Amazing, just like passkeys!
Nextgrid · 52m ago
Biggest difference is that SSH keys allow you to store and submit the public key without the private key being present.
With passkeys, the private key must be present and usable (at least with current implementations) at the time of enrolment.
This raises a major problem: with SSH keys you can keep an backup key in a secure location (bank vault, etc) and still be able to register it. With passkeys your backup key must be present and connected when registering it, so you can’t keep it in a secure location as you always need it when registering. This exposes both keys to risks such as hardware failure (let’s say faulty USB port that spikes anything plugged in with 12V… you connect your main key, it doesn’t work, now you connect your backup key and same thing happens… by the time you realize both your primary and backup keys are toast).
karmarepellent · 4h ago
The sarcasm is duly noted. But I simply answered the question. I don't have any strong opinion regarding passkeys.
No comments yet
vbezhenar · 5h ago
ssh is terribly insecure with no way of checking server certificate fingerprint automatically. Web solved it decades ago with CA.
karmarepellent · 5h ago
This is incorrect. SSH certificates work just like x509 certificates in that regard. Also, with PubkeyAuthentication, there exist all kinds of ways to collect host keys before connecting to them for the first time and thus avoiding the trust-on-first-use problem. Especially in private networks where you control all the nodes.
palata · 2h ago
SSH does have certificates, but in practice most people using SSH don't use SSH certificates and don't check the fingerprints.
Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).
tptacek · 14m ago
If you have a small, stable number of hosts, an SSH PKI doesn't make a lot of sense. With a large fleet, and/or if you want to tie your fleet into an OIDC IdP, certificates are pretty common; the most common way of solving this problem, I think?
Leaving off everything else I think about DNSSEC, this is a baffling feature. DNS solves the problem of introducing unrelated counterparties, which is not the SSH host key problem --- people generally don't SSH into hosts they're not somehow affiliated with. This is what CA-based PKIs are made for, and OpenSSH has a good (non-X.509) certificate system already; lots of people use it to get e.g. SSO login for SSH.
Tying authenticity to a global, remote set of authorities is a tradeoff we make for anonymous introductions to random web servers whenever we need them. SSH doesn't have that problem, so the tradeoff gets you... nothing?
seany · 5h ago
Exporting passkeys is the single required feature for me to start using them more. The "anti phishing" push has really gotten a little too crazy. It seems mostly related to our legal inability to push security responsibility onto consumers.
jazzyjackson · 5h ago
Given that you don't strictly need to have one passkey per site, is this desire to move passkeys around a holdover from wanting to "export" your passwords? Because if you can export them, an exploit can too. I find passkeys rather more interesting when they cannot be exported from a HSM / key enclave / yubikey, but of course I need to be able to register multiple yubikeys per site, and a few of my accounts didn't allow for this so I ended up using my yubikey for TOTP since I can have the same seed on multiple devices.
mgulick · 2h ago
My keepass database has around 400 different entries in it. If I needed to transfer to a new password manager, it's not feasible to go around to 400 different sites to register new passkeys. In case one might say the answer to that is oauth, I'm also not interested in putting my faith in Google/Microsoft/Apple being benevolent arbiters of my ability to access my accounts.
recursive · 4h ago
You should be allowed to keep your passkeys in such enclave. But there seems to be no alternative. I'm in the same boat as the GP. I'm not touching passkeys unless and until I can export them into a file I can get my grubby hands on. I'm guessing that's never happening. Not sure what one-passkey-per-site has to do with it.
tuckerman · 4h ago
Export is a good check against lock in. I just went through my password manager and I have 60 passkeys. It would be a huge pain if I have to switch to a different password manager and there isn't export/import.
palata · 1h ago
There are two kinds of passkeys: the ones you can sync (i.e. export) and the ones you can't. The ones you can't sync are typically security keys, and there it's a feature.
So yeah, you can have whichever you want, nothing prevents it!
EbNar · 5h ago
>Exporting passkeys is the single required feature for me to start using them more.
Ditto
habinero · 4h ago
Nothing to do with legal responsibility and it's not about only consumers.
I have 50 terabytes of data breaches on a NAS with lots of plain text or badly encrypted passwords, and that's just a small subset of what's out there.
dan-robertson · 4h ago
> Obviously, one could pay for an authenticator like 1Password, which at least is ecosystem independent. However, not everybody is in a situation where they can afford to pay for basic services like password managers
This argument was made in the context of moving out of the Apple ecosystem (are there other ecosystems one would want to leave where the only option is paying for something like 1password?). I don’t really buy it because I can’t work out a situation where one is switching from some expensive ecosystem but unable to pay a low fee for 1password. But maybe I’m missing an example.
the_mitsuhiko · 4h ago
> This argument was made in the context of moving out of the Apple ecosystem
Author here. Insert your favorite ecosystem in that people currently have. If you have a windows 11 computer you end up with Windows Hello passkeys for free. If you have a Chromebook then it will be something else.
Apple devices show up in low income households somewhat regularly where I live because of subsidized iPads for education.
kbelder · 1h ago
>I can’t work out a situation where one is switching from some expensive ecosystem but unable to pay a low fee for 1password.
You lose your job.
Dr4kn · 4h ago
There is also keepass, which you can sync with whatever free cloud storage you want. It might not be the nicest password manager you can use, but you can always use it for free.
Bitwardens free tier is also generous enough that a lot of people won't have to pay
dan-robertson · 4h ago
Seems like the existence of keypass does not support the argument made in the OP.
shmerl · 3h ago
> One slightly more concerning issue today is that there is effectively no way to export private keys between authentication password managers
Not being able to use the passkey manager at all is a bigger concern. For example Keepassxc works with some sites but not with others. It's super annoying and way worse than situation with passwords.
ewoodrich · 2h ago
I use Bitwarden and have never had issues saving or using passkeys with any site I can recall via the Chrome extension.
dmfdmf · 3h ago
I think that now that IPV6 has 2^128 addresses that some of these can be assigned to individuals as a unique ID, maybe at birth like SSN. It could serve as the base of a public key and secret private key blockchain system controlled by the individual or his trusted agent in some kind of identifier/authenticator system. If properly implemented it could serve as an anonymous ID and age verification system on the internet which seems to be coming soon in a not-so anonymous form to a fascist, commie or authoritarian govt near you, i.e. all of them as current events now show.
I don't know if that would work but it is an interesting idea to me. However, it also illustrates that authentication and protecting user identity on the web without sacrificing anonymity is a _political_ problem not a technical problem. I have always been told that when thinking about security you have to define what threat are you trying to protect yourself from. I see discussions on security and virtually all of them ignore that the govt or govt controlled corps (i.e. fascism) is a much bigger threat to individuals and freedom than so called "hackers" or "terrorists" and other boogie men, etc.
AnotherGoodName · 5h ago
> there is effectively no way to export private keys between authentication password managers
No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today.
You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on google and add it! This is effectively how you’re meant to move passkeys around. Create a new and register that with the same services as the old one.
The real hassle right now is remembering all the services you attached your current passkey to so you can register a new passkey with them and it’d be nice if there was something similar to ninite installer for passkey registration. But still it's not a huge blocker. You can absolutely use multiple passkeys and login with any one of them.
recursive · 4h ago
I don't want to cede a chokepoint to my online identity to a multinational conglomerate with no support department. I don't understand the UX for adding more passkeys.
I'd rather have the possibility of being "tricked" than get locked into another walled garden. Maybe I'm wrong for feeling that way, but there are literally dozens of us.
AlexandrB · 4h ago
> Otherwise people would be tricked into giving away passkeys much like they are with passwords today.
Is this really a common attack vector vs. a company leaking their whole customer database and a bunch of password being revealed that way?
habinero · 4h ago
Yes, it's called phishing.
AlexandrB · 4h ago
Phishing is different (from the user's POV) than exporting a password and "giving it away". I don't see how phishing would be applicable to passkey exports.
palata · 1h ago
> Phishing is different
Nope, it's exactly that: tricking people into believing that they are exporting their passkey securely where actually they are sharing it with the attacker.
> I don't see how phishing would be applicable to passkey exports.
Phishing is applicable to everything humans can do: if you can ask a human to do it, you can phish a human to do it.
hooverd · 3h ago
Effectively ceding control of your online identity is a feature? Would you be willing to bet real money that the passkey attestation feature will never be abused be these same companies ?
palata · 1h ago
How is that effectively ceding control of your online identity?
You can buy a security key (that does not have your name on it), have it generate a FIDO2 key and use it as a passkey. You can have 100 Yubikeys for 100 different websites if you want.
But you can't ever export the private key from the Yubikey, and that's a feature. That's the whole point of the Yubikey.
jazzyjackson · 5h ago
Just made the same comment, weird that its an unpopular opinion. Chalk it up to a UX issue around user expectations.
AlexandrB · 4h ago
It's not just that. There's a huge lack of trust with the tech industry. I don't think anyone trusts tech companies to act in the user's best interests with this kind of restriction instead of using it to drive more platform or service lock-in.
palata · 1h ago
I get the lack of trust with TooBigTech, but I personally use passkeys with security keys (Yubikeys). WebAuthn is just a bunch of protocols that can run independently from TooBigTech.
recursive · 59m ago
It's hard for more people to verify whether this is actually independent from big tech. With a password, you can write it on a piece of paper. You can then type it back in. If any character doesn't match, it doesn't work. This seems like a trustworthy demonstration that it is actually independent. Passkeys have too much magic to understand in this way.
palata · 1h ago
I don't get the downvotes here.
I feel like people mix up the protocols and the implementations. Because one can share their passkeys with a Google password manager does not mean that they have to. Passkeys are just WebAuthn, which works on its own.
Since I'm getting downvoted as well: I am using passkeys with Yubikeys, without depending on any TooBigTech.
My kids use prepaid numbers, once I changed one and forgot to tell Apple, when I realized that I needed the old number later, it took me a month at least to get it back.
I really like passwords, the security risks are well known and really easy to handle compared to 2FA and all that crap, specially when 99% of your accounts are not sensitive enough to merit anything fancy.
Everything else is a security theatre and an UX pain.
For example https://shamir.securitytools.io/
(customer identity and access management is a component of my work at a fintech)
IME as a customer/user, financial institutions are some of the worst culprits for doing appalling things in the name of security (theatre) anyway.
The reality is that TOTP has been obsolete for awhile now. It's a net negative for ordinary users that is kept front-of-mind for everyone because nerds like us are attached to it.
Just now, at least in Europe, there is a huge push to force users to authenticate themselves with their actual identity, even for ordinary Internet services. This is happening simultaneously in many countries (including non-EU countries like Switzerland). It almost has to be a coordinated effort....driven by whom? Passkeys play into this.
Call me paranoid...
Yes, it's awful during the transition period while the tech matures, but there is a path towards a great future.
The last time I tried to use passkeys, the desktop was easy. What about mobile? There wasn't a local third-party password manager that could work with passkeys on Android.
sounds like you found yourself a market opportunity…
But passkeys are just a way of democratising private keys instead of passwords.
Sure, there will be examples of walled gardens leveraging passkeys. But we have plenty of examples of walled gardens that don't need passkeys at all. It's a different problem.
The name of the issue reveals the actual problem: "should never be exported in clear text". If the export was encrypted with a passphrase in a standard format, then there would be no issue. It's specifically doing it in plain text that causes consternation. Of course, in practice it doesn't make much of a difference when users are incapable of choosing secure passwords, let alone passphrases. But requiring exports to be encrypted is the least one can do to maintain a degree of security while still allowing exports.
> For many years already, people lose access to their Google account every day and can never regain it. Google is well known for terminating accounts without stating any reasons. With that comes the loss of access to your data. In this case, you also lose your credentials for third-party websites.
In practice this is frequently already true. Many sites require an email to sign up. Whenever you attempt to log in on a new device, they require you to type in a code sent to your email. Without access to your email, you cannot sign in.
I am sympathetic to the intent but the words of Patrick Henry come to mind too often in conversations like these. I love passkeys and appreciate secure defaults but I feel strongly that user freedom is a more fundamental requirement than preventing phishing attacks.
If KeepassXC wanted to enforce that world view for the safety of their users, it’s their right, but this is essentially a threat of blacklisting an entire password manager for adding a feature demanded by their users (who likely predominantly used by technically savvy users at that).
Moreover, "just" password protecting a file isn't allowed by the draft CXP standard (https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html#...), you have to use a HPKE scheme where the key exchange is manually orchestrated by the user to export offline. I get it from a security perspective, but that's stupid.
There is no such guarantee if credential-stealing malware can export your private key material in plaintext!
We already require TOTP-based 2FA, and have even implemented secure TOTP via our mobile apps. Customers still do not understand 2FA and probably never will; we regularly have customers request 2FA resets after using their 10 backup codes. SMS- or email-based 2FA is a no-go.
We don't require hardware attestation, as that is the recommendation of the FIDO alliance and Google/Apple/Microsoft. It doesn't make sense to cut out iCloud/Google-synced passkeys given the clear security benefits over passwords+2FA.
Keep in mind that for our service, we regularly see attackers set up copycat sites to phish user credentials, and pay for Google Search ads to appear before our site in search results. These phishing attempts are sophisticated and customers will send their 2FA codes through them. _This is impossible with passkeys._
No comments yet
They're technically weaker than password + hardware key but stronger than anything else, including password + totp. Google Advanced Protection still wants you to have a hardware key for your account.
The downside is of course that hardware keys are typically not cheap and you should also buy a backup key. Another unnecessary downside is that certain companies like Microsoft require the use of resident keys, which take up storage space on the hardware key. The better alternative is non-resident keys, of which you can have an infinite number on your key.
Same when I got my Yubikeys: I gradually moved the OTP seeds to them, wasn't that painful.
I just use a simple shell script with dmenu/xclip/oathtool:
On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse. Signing up is uploading a public key. Signing in is cryptographically signing a commitment to the current ephemeral tunnel.
This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.
Everything else about managing which public keys are for what does not need to be decided in a standard. The users can choose whatever key management solution works best for them. What those links get at is a problem of key management. A single set of keys, where you send all of them to every server all the time, is a bad strategy.
Ever tried to SSH with a security key... through FIDO2? Or would you say that having your private key as a file on your computer is strictly better than having it in a security key? :-)
I guess a desirable trait of seniority is to balance the urge to play with new toys vs the feeling that sometimes we are running in circles, repeating the same mistakes with different tech.
[1]: https://blog.codinghorror.com/the-magpie-developer/
What do you need to do to keep family from (a) not getting locked out and (b) not getting phished?
I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding?
Aside from the wonderful possibilities that are offered by using port forwarding of some kind, you could also simply use OpenSSH's ForceCommand to let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service).
I guess no one uses SSH for authentication in this way because it is non-standard and kind of shuts out non-technical people.
No, it's just how you authenticate with signing keys. Given that a secure channel has been set up with ephemeral keys, you can sign a commitment to the channel (like the hash of the shared secret key) to prove who you are to the other party.
> let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service)
This is exactly what I recommend. If everyone did this, then eventually then the browsers or 1password could support it.
And WebAuthn is using FIDO2, it's not that different, it's just that WebAuthn adds some stuff like a relying party.
Being in charge of the strength and security of your private key is something most people don't want to do, so we get multiple identities made "easy" by walled gardens getting popular in passkeys.
The complexity of X.509 belongs in the domain name system. If a bunch of large corporations want to come up with complicated formats so they can decide who gets to call themselves what on the internet, let them do that, but don't let them complicate basic security for the rest of us.
The experience to beat is swapping SSH keys. 95% of developers have setup access to a new machine using SSH. That should be the default experience for authenticating on the internet, and anything more complicated should be strictly opt-in.
Edit: or put another way, why should I have to load another library for PKA when I already have one that works just fine?
WebAuthn helps prevent just that.
How do I sign in from multiple computers?
You can either have 1 key pair per service and sync them with something like 1password. Or you can have 1 key per service per device. Keys that never leave the device is usually considered more secure (and I agree for what I consider my threat model to be).
Important services like primary email, your bank, or cloud platform should probably do 1 key per device. Everything else benefits from the simplicity of 1 key per service with the keys synced.
Actually, a benefit of passkeys is the standardization of client-side cross-device authz operations via caBLE and similar; your secret keys never leave your primary device, but are usable from other devices over a variety of transports.
It also applies to SSH keys. I never said that passkeys couldn't do everything SSH keys can do. My criticism is that they are more complicated to do the same thing.
This is exactly what not valuing simplicity looks like.
WebAuthn just adds a few things like the relying party and a counter (that nobody seems to use). And the relying party helps preventing phishing, which SSH doesn't do really well in practice (most people don't use SSH certificates and don't check the server fingerprints).
So it's just not true that passkeys are more complicated to do the same thing.
With passkeys, the private key must be present and usable (at least with current implementations) at the time of enrolment.
This raises a major problem: with SSH keys you can keep an backup key in a secure location (bank vault, etc) and still be able to register it. With passkeys your backup key must be present and connected when registering it, so you can’t keep it in a secure location as you always need it when registering. This exposes both keys to risks such as hardware failure (let’s say faulty USB port that spikes anything plugged in with 12V… you connect your main key, it doesn’t work, now you connect your backup key and same thing happens… by the time you realize both your primary and backup keys are toast).
No comments yet
Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).
Tying authenticity to a global, remote set of authorities is a tradeoff we make for anonymous introductions to random web servers whenever we need them. SSH doesn't have that problem, so the tradeoff gets you... nothing?
So yeah, you can have whichever you want, nothing prevents it!
Ditto
I have 50 terabytes of data breaches on a NAS with lots of plain text or badly encrypted passwords, and that's just a small subset of what's out there.
This argument was made in the context of moving out of the Apple ecosystem (are there other ecosystems one would want to leave where the only option is paying for something like 1password?). I don’t really buy it because I can’t work out a situation where one is switching from some expensive ecosystem but unable to pay a low fee for 1password. But maybe I’m missing an example.
Author here. Insert your favorite ecosystem in that people currently have. If you have a windows 11 computer you end up with Windows Hello passkeys for free. If you have a Chromebook then it will be something else.
Apple devices show up in low income households somewhat regularly where I live because of subsidized iPads for education.
You lose your job.
Bitwardens free tier is also generous enough that a lot of people won't have to pay
Not being able to use the passkey manager at all is a bigger concern. For example Keepassxc works with some sites but not with others. It's super annoying and way worse than situation with passwords.
I don't know if that would work but it is an interesting idea to me. However, it also illustrates that authentication and protecting user identity on the web without sacrificing anonymity is a _political_ problem not a technical problem. I have always been told that when thinking about security you have to define what threat are you trying to protect yourself from. I see discussions on security and virtually all of them ignore that the govt or govt controlled corps (i.e. fascism) is a much bigger threat to individuals and freedom than so called "hackers" or "terrorists" and other boogie men, etc.
No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today.
You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on google and add it! This is effectively how you’re meant to move passkeys around. Create a new and register that with the same services as the old one.
The real hassle right now is remembering all the services you attached your current passkey to so you can register a new passkey with them and it’d be nice if there was something similar to ninite installer for passkey registration. But still it's not a huge blocker. You can absolutely use multiple passkeys and login with any one of them.
I'd rather have the possibility of being "tricked" than get locked into another walled garden. Maybe I'm wrong for feeling that way, but there are literally dozens of us.
Is this really a common attack vector vs. a company leaking their whole customer database and a bunch of password being revealed that way?
Nope, it's exactly that: tricking people into believing that they are exporting their passkey securely where actually they are sharing it with the attacker.
> I don't see how phishing would be applicable to passkey exports.
Phishing is applicable to everything humans can do: if you can ask a human to do it, you can phish a human to do it.
You can buy a security key (that does not have your name on it), have it generate a FIDO2 key and use it as a passkey. You can have 100 Yubikeys for 100 different websites if you want.
But you can't ever export the private key from the Yubikey, and that's a feature. That's the whole point of the Yubikey.
I feel like people mix up the protocols and the implementations. Because one can share their passkeys with a Google password manager does not mean that they have to. Passkeys are just WebAuthn, which works on its own.
Since I'm getting downvoted as well: I am using passkeys with Yubikeys, without depending on any TooBigTech.