Toward a Passwordless Future(privacyguides.org)
privacyguides.org
Toward a Passwordless Future
https://www.privacyguides.org/articles/2025/03/08/toward-a-passwordless-future/
69 comments
Passwords are still leakable, guessable, and can be phished. Passkeys are “second-factor-only”: your device responds to a challenge and acts in a similar capacity to a yubikey. The private keys contain much more entropy than a password, never leave the device, and the challenges and responses are both signed with site-specific keys so they can’t be phished. So from a security perspective, a lot is gained.
From a user perspective, instead of trying to get the dang webform to autofill, I just smile for a second and become authenticated.
From a user perspective, instead of trying to get the dang webform to autofill, I just smile for a second and become authenticated.
Until you lose the device. Or you're given security codes and those are again, leakable and guessable. No normal user is going to accept their phone being stolen and losing access to their bank account. It's bitcoin as unregulated fiat levels of wishful thinking
Registering your phone as a passkey through Apple or Google will cloud-sync the key. This isn’t great for isolation, but is pretty good for availability.
Using something like KeepassXC puts you in charge of your own backups.
I’m sure we can all find people for whom one or the other would be preferable.
Using something like KeepassXC puts you in charge of your own backups.
I’m sure we can all find people for whom one or the other would be preferable.
> Registering your phone as a passkey through Apple or Google will cloud-sync the key.
Isn't it lovely that the big players can do that...
and when Keepass or others want to do it, they are threatened in no uncertain terms with de-attestation? 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".
> https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
"Users should be prevented from copying or sharing a private key".
Isn't it lovely that the big players can do that...
and when Keepass or others want to do it, they are threatened in no uncertain terms with de-attestation? 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".
> https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
"Users should be prevented from copying or sharing a private key".
"Leakable" isn't a purely negative property. It's the same thing you can use to provide access to a trusted spouse, and ensures a trivial solution to the "lost device" problem when traveling.
You can provide access by registering another key. Similarly, the trivial solution to the "lost device" problem is a backup.
well if your hardware is compromised using passwd manager or passkeys is not different at all
for now phone hacked = say goodbye to work,banking etc is not ideal yes but in the future where you can implant chips under skin??? now we talking
for now phone hacked = say goodbye to work,banking etc is not ideal yes but in the future where you can implant chips under skin??? now we talking
I really don't want to use Passkeys until they can be stored in my password manager of choice on Linux, Android and Windows.
What are you using? I think most managers already do passkeys
I was enthused when it first got added to KeypassXC but after a few attempts I couldn't get it working and haven't bothered since. Something fundamentally isn't quite working here and I am not a big fan of the workflow for them its entirely out of my hands and I am not a fan of that.
I don't want to use passkeys until I can chose and verify that they are device bound.
KeepassXC famously has no network sync of any kind and supports passkeys.
Use a hardware token (eg. yubikey) then?
1Password ticks all these boxes.
It doesn't support using the passkeys in chrome for android as far as I'm aware
Okay, but now you moved the goalposts by adding the context of Chrome. It works on Android in Firefox.
Okay. Maybe discuss this with whoever develops your password manager. The tone of your reply has me thinking that you’re using an open-source password manager. Maybe they’ll accept a PR from you?
Passkeys are supported by my password manager of choice, in the OSs that I care about.
Passkeys are supported by my password manager of choice, in the OSs that I care about.
I wish first and foremost that all my accounts could support passkeys/passwordless sign ins instead of only like 12/60.
My second wish would be that passkeys should be as easy to work with as ssh keys. Somehow, they tend to be more complicated. Asking you if you want to use your phone or security key (when you have neither, you are using a password manager) and often failing to immediately detect your preferred method of storing them, defaulting to Google, Microsoft, or Apple's solutions.
My second wish would be that passkeys should be as easy to work with as ssh keys. Somehow, they tend to be more complicated. Asking you if you want to use your phone or security key (when you have neither, you are using a password manager) and often failing to immediately detect your preferred method of storing them, defaulting to Google, Microsoft, or Apple's solutions.
Passkeys are not a panacea. They're an amalgam of multiple standards that half the time aren't implemented right or not fully supported. It's the industry's attempt to design-by-committee a one-size-fits all solution to many, many different problems. News flash: one-size-fits-all fits nobody well.
Passwords are a perfectly fine single factor. Add more factors to get more security, in specific use cases where they make sense. Passkeys don't fill the use case that a single-factor like passwords do.
Password Managers are also perfectly fine when combined with multiple factors and attack mitigations (and are certainly no worse than Passkeys we have now, key access managed by a central piece of software/key control/authorization). They solve many different use cases without breaking others. They're customizable, and not overly-dependent on standards. They are a loosely-coupled interface. They can be synchronized for multiple device/site access. They can be upgraded to support an infinite amount of security mechanisms. They can be changed in backwards-compatible ways, and they don't force one-size-fits-all on anybody. They even support Passkeys without forcing you to use them (though of course lots of Passkey software ignores the fact that you might have a password manager, and forces you to use the browser's Passkey store or nothing).
You want to uniquely identify a device? Fingerprint it on login. Having a separate passkey per device isn't any better, because if the attacker can get the device fingerprint, they can also probably get the passkey, because they have access to the device. And password reset still has to be a thing, because we all lose devices, backup codes, etc, so it's not like there isn't an easier attack anyway.
How is the passkey that much better than client-side certificates from 15 years ago? That was abandoned because of all the problems around key management; and now you want to bring back key management?!
Please stop trying to solve a problem by creating more problems. This is all about use cases. Just let users, and companies, decide what use cases they'll support. Don't force everyone to use a crap solution just because it makes big corporations happy.
Passwords are a perfectly fine single factor. Add more factors to get more security, in specific use cases where they make sense. Passkeys don't fill the use case that a single-factor like passwords do.
Password Managers are also perfectly fine when combined with multiple factors and attack mitigations (and are certainly no worse than Passkeys we have now, key access managed by a central piece of software/key control/authorization). They solve many different use cases without breaking others. They're customizable, and not overly-dependent on standards. They are a loosely-coupled interface. They can be synchronized for multiple device/site access. They can be upgraded to support an infinite amount of security mechanisms. They can be changed in backwards-compatible ways, and they don't force one-size-fits-all on anybody. They even support Passkeys without forcing you to use them (though of course lots of Passkey software ignores the fact that you might have a password manager, and forces you to use the browser's Passkey store or nothing).
You want to uniquely identify a device? Fingerprint it on login. Having a separate passkey per device isn't any better, because if the attacker can get the device fingerprint, they can also probably get the passkey, because they have access to the device. And password reset still has to be a thing, because we all lose devices, backup codes, etc, so it's not like there isn't an easier attack anyway.
How is the passkey that much better than client-side certificates from 15 years ago? That was abandoned because of all the problems around key management; and now you want to bring back key management?!
Please stop trying to solve a problem by creating more problems. This is all about use cases. Just let users, and companies, decide what use cases they'll support. Don't force everyone to use a crap solution just because it makes big corporations happy.
The article praises passkeys for not even needing email for login, but omits to mention recovery flow. How do you recover your account if you lost your access to the passkey provider, and you didn't provide an email address?
So, I think "not even needing email" is unlikely for foreseeable future, unless we find other ways to authenticate people reliably.
So, I think "not even needing email" is unlikely for foreseeable future, unless we find other ways to authenticate people reliably.
The article glosses over much more than that. Everything towards the end feels like provided talking points without the same scrutiny that the current situation is given.
A password, and extra secret information on things like my bank account have always worked well for me. I simply cannot stand 2FA using a smartphone. Why? Because I don't have or want one. Luckily, my bank allows use of a landline for 2FA, which works perfectly, but I dread the day they stop supporting it.
Also, the whole bloody thing with passwords is noxious. I don't want to login to your site, I just want to read some stuff.
Also, the whole bloody thing with passwords is noxious. I don't want to login to your site, I just want to read some stuff.
I wish SQRL would become more popular.
https://www.grc.com/sqrl/sqrl.htm
https://www.grc.com/sqrl/sqrl.htm
How is it better than passkeys?
So... what happens with passkeys if you lose/break/someone_steals your phone?
I'm talking about normal users, without backups.
I'm talking about normal users, without backups.
They're screwed, but that already happens. You have no idea how many people lose their phone or forget some password and just get a new phone/account, without trying to recover the old one.
Parents who lost their child's photos and are like oh well.
Assuming a normal user doesn't use the same password everywhere (which means everyone already knows their password), the alternative is saving them. Lost password or lost passkey doesn't make much difference.
Computing literacy is low so people will just suffer the consequences.
Parents who lost their child's photos and are like oh well.
Assuming a normal user doesn't use the same password everywhere (which means everyone already knows their password), the alternative is saving them. Lost password or lost passkey doesn't make much difference.
Computing literacy is low so people will just suffer the consequences.
The same thing that happens if you enroll in 2FA and lose your 2FA cred: you go into a complicated account recovery process.
For this reason, at the huge providers, when you enable 2FA (or Passkeys) you usually have to set up a recovery buddy account or something like it.
For this reason, at the huge providers, when you enable 2FA (or Passkeys) you usually have to set up a recovery buddy account or something like it.
But if that "buddy account" is 'passworded' by the same passkey device?
Getting a new sim card with the same number is easy, you just go to your mobile provider with your ID card, and you're done in five minutes.
I mean still... the article mentions a "single point of failure" as a bad thing with other methods, but forgets about it here.
Getting a new sim card with the same number is easy, you just go to your mobile provider with your ID card, and you're done in five minutes.
I mean still... the article mentions a "single point of failure" as a bad thing with other methods, but forgets about it here.
Getting a SIM card is too easy, many millions have been lost to sim-jacking.
In most countries, not really.
Some countries have problems with people and IDs, like US, so that's a different story.
Some countries have problems with people and IDs, like US, so that's a different story.
Until the passkey workflow goes sideways for "tech" people I don't think the risks will be acknowledged (if then even).
Those of us who don't want the let Google, Apple, or Microsoft manage our passkeys (i.e. pledging our fealty to our lords) will be seen as fringe lunatics.
I'll keep my workflow of always visiting sites by typing the URL myself, using a password manager, and TOTP 2FA w/ the secrets saved offline on paper. At least until I'm not allowed to do that anymore.
Those of us who don't want the let Google, Apple, or Microsoft manage our passkeys (i.e. pledging our fealty to our lords) will be seen as fringe lunatics.
I'll keep my workflow of always visiting sites by typing the URL myself, using a password manager, and TOTP 2FA w/ the secrets saved offline on paper. At least until I'm not allowed to do that anymore.
Same here, I don't like passkeys for many reasons. Another reason is that I can't see the key that I'm using. Therefore: What if Bitwarden doesn't pick up the passkey? Tough luck, I'm out of options. I cannot manually create a passkey entry in Bitwarden because it's all hidden magic. If I notice that the password manager doesn't pick up a registration then I just add it myself. Not possible with passkeys.
Luckily Bitwarden supports passkeys. And you can self host it. And even vaultwarden/bitwarden-rs supports passkeys
Easy if you're in the same country as the provider. Not so easy if you're on the other side of the planet.
All of the major implementations sync across all of your devices and use recovery codes as part of the setup process. Apple’s implementation is designed to cover loss of all devices, and I’d assume the others are similar:
https://support.apple.com/guide/security/escrow-security-for...
The key thing to understand is that passkeys are not intended to be as secure as hardware tokens but to be more secure than traditional passwords with phishing-friendly MFA. That allows them to offer better recovery options but might not be good enough if you are the target of a serious actor.
https://support.apple.com/guide/security/escrow-security-for...
The key thing to understand is that passkeys are not intended to be as secure as hardware tokens but to be more secure than traditional passwords with phishing-friendly MFA. That allows them to offer better recovery options but might not be good enough if you are the target of a serious actor.
What if the provider of the major implementation decides to shut you out of your account?
Well, it's true that a password manager is a single point of failure.
If you have two password managers then they can serve as backups for each other. Unfortunately that means you have to register each account twice.
If you have two password managers then they can serve as backups for each other. Unfortunately that means you have to register each account twice.
Just use a password manager that allows you to have a local copy of everything (e.g. KeePass) and just back it up as any other file
That could work, assuming your usual file backup methods are secure enough and it doesn't create a circular dependency.
[deleted]
That depends on whether you need to have an active account to use your existing devices. For example, an Apple user would need to migrate before things fall out of sync but they have a full copy on every device.
The fallback path here is what you’d do with any other MFA loss. It’s not a federated login system so you’d be looking at some kind of account recovery process for each of the sites where you used your passkey, just like you would if you lost a Yubikey or changed phone numbers.
The fallback path here is what you’d do with any other MFA loss. It’s not a federated login system so you’d be looking at some kind of account recovery process for each of the sites where you used your passkey, just like you would if you lost a Yubikey or changed phone numbers.
This is incorrect, there is no fallback once they have shut you out. The correct answer is to not use a passkey that's managed by the device ecosystem.
Citation? Are you conflating losing access to your iCloud account with a remote-wipe? I’ve used devices which had synced passkeys when iCloud was disabled (MDM gaffe) or unavailable due to a password change, and the credentials which had already been synced continued to work without issue.
> The fallback path here is what you'd do with any other MFA loss.
Which, in many cases, is avoid MFA because it's less secure. Yes, less secure because availability is part of security.
And I don't have a better plan to store all those recovery codes than to store all those passwords. So the attacker can still get in with the same effort, but I have to keep getting my phone. No thank you.
Which, in many cases, is avoid MFA because it's less secure. Yes, less secure because availability is part of security.
And I don't have a better plan to store all those recovery codes than to store all those passwords. So the attacker can still get in with the same effort, but I have to keep getting my phone. No thank you.
I agree that storing recovery codes is a pain point, but they're fundamentally different from passwords in that you don't need to use them for each login. That allows you to put them in cold storage, whether that's an encrypted flash drive, a piece of paper, a box buried in your back yard, or whatever else you want. Doing the same thing for information you need on each login would be ridiculous, but for a once-in-a-blue-moon recovery situation, the lack of convenient access is fine.
> Yes, less secure because availability is part of security.
This is too often forgotten. Availability is a fundamental part of security and must be part of every threat model.
And your threat model needs to be matched with what it is being protected. One size does not fit all.
For example to log in to my brokerage account, I may be ok with a solution where I might lock myself out and have to go to a physical branch to restore access. Because while that would be a pain, it's better than having my life savings stolen.
But to log in to, say, facebook? Availability and convenience is #1 above all, it's just cat videos and other extremely low value stuff so it's not worth any inconvenience.
This is too often forgotten. Availability is a fundamental part of security and must be part of every threat model.
And your threat model needs to be matched with what it is being protected. One size does not fit all.
For example to log in to my brokerage account, I may be ok with a solution where I might lock myself out and have to go to a physical branch to restore access. Because while that would be a pain, it's better than having my life savings stolen.
But to log in to, say, facebook? Availability and convenience is #1 above all, it's just cat videos and other extremely low value stuff so it's not worth any inconvenience.
We can’t trust users to not re use a password, why do we expect they will go through the effort of storing / understanding recovery codes?
It’s easier to print things and you have clear instructions telling you why it’s important.
The key here is thinking about relative risk: many people get compromised by reusing passwords or being phished every day compared to the number of people who simultaneously lose all of their devices and recovery codes.
The key here is thinking about relative risk: many people get compromised by reusing passwords or being phished every day compared to the number of people who simultaneously lose all of their devices and recovery codes.
It's not easier to print things. Only about 60% of the population has a printer and that number is going down, not up.
One confound is that many people don’t own a personal printer because they have access to one at their library, job, friend’s home, etc. and that’s fine for something you do once and likely never use over your lifetime.
Normal users have backups in the cloud. They also enable biometric so a stolen phone is no use. Even if stolen in a mugging.
[deleted]
they should have an activation factor that, e.g. bio or pin.
The problem with passkeys is that they couple a security credential to a device containing lots of personal information. I don't take my phone into certain countries where I sometimes travel, but I do bring my yubikey. I get the security benefits without the exposure of everything that's on my phone.
So it's effectively SSH keys, but for regular app/site logins with a nicer UI.
Closer to having your existed devices work similar to a yubikey: it’s a signed challenge-response, per-site, instead of a single shared key.
That and the hypothetical ability to use different private keys per device, which could be canceled in case of loss or theft, seems legitimately useful. Not interested unless and until there's a standalone, standardized, open-source, cold-backup'ed way to use passkeys though.
Try out KeepassXC :)
Already using it for my password manager. Didn't know they'd added passkey support; thanks for the tip.
I've only heard bad things about privacyguides.org.
https://www.reddit.com/r/PrivacyGuides/comments/thnjjf/priva...
https://www.reddit.com/r/PrivacyGuides/comments/thnjjf/priva...
This post is 3 years old and mostly talking about a completely different website, because the poster didn’t know privacyguides.org moved to a new domain after the old one was hijacked.
https://www.reddit.com/r/PrivacyGuides/comments/thnjjf/comme...
https://www.reddit.com/r/PrivacyGuides/comments/thnjjf/comme...
Still a no from me. Right now passkeys are just a way for services to exert more control over users. I don't see that changing for decades at minimum.
> Right now passkeys are just a way for services to exert more control over users
How?
How?
Article talks how password managers are bad because they are a single point of failure, and then suggests syncing passkeys between devices using... password managers.
What? Who wrote this?
What? Who wrote this?
I am largely unconvinced of the downsides of passwords presented in the article. Especially the historical angle. Old != bad. In fact, it is a testament to the fact the the password system is simple enough to be done analog, easily understood without any training.
My question to the people here is are passkeys actually the future? Or are they an over-hyped over-engineered being forced on everyone? I say this as someone not knowing much of passkeys. And I'm not a fan of the "holier than thou" feeling from people proselytizing passkeys. Take the public's / user's doubts seriously. You wouldn't break into someone's home and force them to get a different lock mechanism for their safe, or front door.
---
Counter-points to "password bad"
> Password Overload
Use a password manager.
> Email Requirement
Passwords don't require email. Email is a used as user ID commonly. You can also use other mechanisms such as "store this long key in your records and if you forget your U+PW then use it for recovery".
> Single Point of Failure ... email acts as a one-stop shop for attackers looking to hack your accounts, either by getting into your email account itself or by sending you convincing password reset emails that send you to a phishing page ...
I agree. Solely having "what you know" info makes phishing possible.
> Service Provider Negligence
A weak argument that could be applied anywhere to "but I don't trust them to do the right thing". All we need is good U+PW auth libraries and clear education like https://thecopenhagenbook.com/. Give actually big fines for companies that have breaches, then magically security will get better.
> Human Error ... passwords rely on randomness to be secure, but they also rely on humans to generate them... Humans are very bad at generating random numbers
Use a password manager. This article reeks of a wannabe expert tone with the certainty, finality, and generality (I can speak confidently yet have an out because I used the word "most" or "possibly"!) of its claims.
> Imagine if every time you connected to a website with HTTPS, you had to come up with your own encryption key. Would that be a secure system?
I can't take the author seriously with these arguments. Put your big boy/girl pants on and use your brain, stop using hypothetical straw-mans to easily knock down.
My question to the people here is are passkeys actually the future? Or are they an over-hyped over-engineered being forced on everyone? I say this as someone not knowing much of passkeys. And I'm not a fan of the "holier than thou" feeling from people proselytizing passkeys. Take the public's / user's doubts seriously. You wouldn't break into someone's home and force them to get a different lock mechanism for their safe, or front door.
---
Counter-points to "password bad"
> Password Overload
Use a password manager.
> Email Requirement
Passwords don't require email. Email is a used as user ID commonly. You can also use other mechanisms such as "store this long key in your records and if you forget your U+PW then use it for recovery".
> Single Point of Failure ... email acts as a one-stop shop for attackers looking to hack your accounts, either by getting into your email account itself or by sending you convincing password reset emails that send you to a phishing page ...
I agree. Solely having "what you know" info makes phishing possible.
> Service Provider Negligence
A weak argument that could be applied anywhere to "but I don't trust them to do the right thing". All we need is good U+PW auth libraries and clear education like https://thecopenhagenbook.com/. Give actually big fines for companies that have breaches, then magically security will get better.
> Human Error ... passwords rely on randomness to be secure, but they also rely on humans to generate them... Humans are very bad at generating random numbers
Use a password manager. This article reeks of a wannabe expert tone with the certainty, finality, and generality (I can speak confidently yet have an out because I used the word "most" or "possibly"!) of its claims.
> Imagine if every time you connected to a website with HTTPS, you had to come up with your own encryption key. Would that be a secure system?
I can't take the author seriously with these arguments. Put your big boy/girl pants on and use your brain, stop using hypothetical straw-mans to easily knock down.
Cool but this (ie pw's) isn't how to steal accounts anyway. Eg when wanting to use AI models for free, just spin up a github dork, no passwords required. Eg, /"Authorization: Bearer xai-.+"/ gives free Grok API key. Try a few until one works and viola.
Plug in the API key and now my app is grokified. or if I'm really wanting that classic experience, ask the free version of grok to spin up a react interface that uses the api key, and then plug in. Wow.
Or if really desperate, make a quick fake NPM package, ask rando dev to npm install it bc its not working with their FOSS project or whatever, say nvm it works now! And it exfiltrates the API key someone wants.
I'd never do any of this bc I'm a latter day saint, but maybe I would if I needed a key in a jiffy who even knows
Plug in the API key and now my app is grokified. or if I'm really wanting that classic experience, ask the free version of grok to spin up a react interface that uses the api key, and then plug in. Wow.
Or if really desperate, make a quick fake NPM package, ask rando dev to npm install it bc its not working with their FOSS project or whatever, say nvm it works now! And it exfiltrates the API key someone wants.
I'd never do any of this bc I'm a latter day saint, but maybe I would if I needed a key in a jiffy who even knows
If I use passkeys, I have to worry about my trusted devices being compromised. According to the article, “as long as you can remember your phone password, you can log in to your accounts.” That sounds like my password manager. The other benefits also sound like a combination of my password manager and privacy focus. I’m not saying this is bad; I just don’t see how it’s different from a security-conscious status quo.