I Stopped Using Passwords. It's Great–and a Total Mess(wired.com)
wired.com
I Stopped Using Passwords. It's Great–and a Total Mess
https://www.wired.com/story/stopped-using-passwords-passkeys/
76 comments
Synced passkeys usually bound to biometrics or some other rate-limited authentication like a pin, and at least Apple syncs them on your keychain, so it never is unencrypted in the cloud.
And the general idea about device-bound passkeys is to enroll them from all your devices (Google encourages you to do so on first sign in from a device), so one surviving device is enough to continue the chain of trust.
And the general idea about device-bound passkeys is to enroll them from all your devices (Google encourages you to do so on first sign in from a device), so one surviving device is enough to continue the chain of trust.
Many people only have one or two devices. Even if someone owns many, they're only one abusive partner or house fire away from losing them all. Even if I were to instill robust self-custody practices in 90% of the populace (an impossibly high bar if mere password hygiene hasn't caught on in 30 years), the remainder is still millions of people who will be locked out their entire digital life permanently.
Can you still access somebody else's phone by showing it a photo of their face, or has that been fixed? Perhaps it has to be a video of their face now.
Face ID never had this issue, it projects a dot matrix on your face and reads back the distortion. The really old Android face unlock did.
So... passwords?
Your passwords will rely on:
* The cloud,
or
* Some specific computer
They can be guessed, leaked, or stolen
Your passwords will rely on:
* The cloud,
or
* Some specific computer
They can be guessed, leaked, or stolen
Passkeys seem to make it harder for you to backup your own private keys to other devices or to paper. Is there an open source Passkey manager yet that allows importing and exporting?
And that I can sync to my other devices. I currently use one of the several keypass managers on my laptop and on my Android devices. As a matter of discipline (not to lose password) I add passwords only on my laptop and I send the db to my mobile devices with syncthing. I don't want to create a new passkey for each site on each device, so syncing is important. Manual export import doesn't work for the same reasons that manual backup doesn't work.
KeepassXC supports exporting, but i don't think it is released in a stable version / to the public yet:
https://github.com/keepassxreboot/keepassxc/pull/8825
https://github.com/keepassxreboot/keepassxc/pull/8825
Bitwarden
Paying a third party to remember passkeys for you should not be the solution, though.
You usually need to pay a third-party for this only if you want/need to backup your passkeys in the cloud and/or sync them between multiple devices (with end-to-end encryption of course, in order for the third-party to not be able to use your passkeys, even if they're hacked). I think that Apple with iCloud Keychain and Google Chrome are doing this for free though.
What form of authentication does one use to log in to the service that stores one's passkeys?
Depends on the service. But that's often a long and random backup key that you're advised to store somewhere safe — can be printed on paper — and is used as last resort if you lose all your devices.
How does this work for people who are homeless or other unstable situations and do not have a safe place to store such a key?
I can't lose a password in my brain to a mugging or pickpocket. With moderate effort it can be copied but deleting the original is beyond the legal and moral limits of most people.
I can't lose a password in my brain to a mugging or pickpocket. With moderate effort it can be copied but deleting the original is beyond the legal and moral limits of most people.
I have a 40-character master password to backup all my other passwords. I've never felt the need to write it down.
I used to do that, but then I realized that a temporary or permanent loss of memory can happen after an accident or a trauma. I'm still on the fence about this (keep this only in my memory, or have a physical copy somewhere).
Do sites generally allow you to have passkeys and passwords set at the same time for the same account?
Do you still use TOTP when using passkeys?
I guess I will try a passkey today and see how I feel about it. Bummer that it won't work with bitward and mobile yet.
If anyone else is curious, I found this site that shows which websites are supporting passkeys. https://passkeys.directory/
Do you still use TOTP when using passkeys?
I guess I will try a passkey today and see how I feel about it. Bummer that it won't work with bitward and mobile yet.
If anyone else is curious, I found this site that shows which websites are supporting passkeys. https://passkeys.directory/
> Do sites generally allow you to have passkeys and passwords set at the same time for the same account?
Typically, yes. You can do this today with Github and Google accounts (and certainly at least a few others). The password option might instead be a link in your email or something similar on other websites, but generally I’ve seen it recommended to have at least one other option to get into your account.
Typically, yes. You can do this today with Github and Google accounts (and certainly at least a few others). The password option might instead be a link in your email or something similar on other websites, but generally I’ve seen it recommended to have at least one other option to get into your account.
> Do sites generally allow you to have passkeys and passwords set at the same time for the same account?
In my experience, yes.
> Do you still use TOTP when using passkeys?
No.
In my experience, yes.
> Do you still use TOTP when using passkeys?
No.
That "no" is not so unequivocal. TOTPs have two use cases... 1) to prevent replay attacks, 2) as a second factor. While passkeys do the same as TOTPs for #1, they don't by themselves address #2. You may still want to use a TOTP that's generated by a separate device (physically different from your primary device) for #2. Of course if you're using the same password manager to handle both passkeys and generate TOTPs and have that on all your devices then your TOTP wouldn't be a real second factor. Ideally here you'd use one of those TOTP-only devices such as those old RSA "credit cards".
The question was "do *you* still use TOTP when using passkeys". I answered "no" because *I* don't use TOPT with my passkeys, but I'm not saying it's not possible or that you shouldn't do it. Personally, as my keys are stored on a physical device, and are unlocked using my biometrics, I consider this as two factors. But I can see how others would prefer two different physical devices.
Isn't the whole point of a second factor to prevent a replay attack / credential stuffing?
What? Passkeys support separate physical devices if you want.
I still haven’t seen a good way to handle multi-device usage, either via syncing passkeys across devices (which is tricky across platforms) or via setting multiple passkeys in the same account.
The biometric capture angle is so blatant. Plus phisher can and absolutely will catch up to this technically. And the added bonus of lose your phone = you don't exist online. Sounds nightmarish.
The biometrics don't leave your device. There is no harvesting of biometric data for other purposes happening.
Passkeys can't be phished, it's literally impossible. It doesn't mean nobody's account will ever be stolen again, but it means attackers will have to switch to other mechanisms (most likely malware, whether it's stealing auth tokens or doing a man-in-the-browser attack). But that's already a win in the current situation, and will only become better over time as platforms become more malware-resistant.
Passkeys aren't any different when it comes to losing your account, it's the same for all authentication factors. People forget their passwords, have their password manager database deleted, have their phones stolen, leave their job and lose their work email, etc. You always need to have a recovery path, the worst you can say about passkeys is that they don't obviate the need for account recovery.
Passkeys can't be phished, it's literally impossible. It doesn't mean nobody's account will ever be stolen again, but it means attackers will have to switch to other mechanisms (most likely malware, whether it's stealing auth tokens or doing a man-in-the-browser attack). But that's already a win in the current situation, and will only become better over time as platforms become more malware-resistant.
Passkeys aren't any different when it comes to losing your account, it's the same for all authentication factors. People forget their passwords, have their password manager database deleted, have their phones stolen, leave their job and lose their work email, etc. You always need to have a recovery path, the worst you can say about passkeys is that they don't obviate the need for account recovery.
The thing about zero day exploits is, no one saw them coming.
The whole notion of "this is perfectly secure trust us" should immediately raise warning flags.
The whole notion of "this is perfectly secure trust us" should immediately raise warning flags.
The technology that passkeys are built on is well understood, and the deployments are building on a tech stack that's been getting deployed in browsers for well more than a decade. I don't remember hearing about any zero-day phishing vulnerabilities in FIDO or WebAuthn during all that time. But even if there had been any, zero-days have both a limited lifetime (these things get fixed quickly after being used in the wild) and a limited reach (only the most sophisticated attackers would have access to them).
There are a small number of people in the world who might need to worry about being the target of a spearphishing campaign that a state-sponsored attacker is going to waste a once in a decade zero-day on. I'm fairly confident nobody in this thread, nor anyone I know in real life, is one of those people.
Even taking hypothetical future zero-days into account, the reduction in specifically phishing risk is going to be absurdly large, the risk will be reduced at least by a factor of millions. That's very different from your original thinking that it was just some minor technical impediment that the attackers would automatically and irrevocably catch up to.
There are a small number of people in the world who might need to worry about being the target of a spearphishing campaign that a state-sponsored attacker is going to waste a once in a decade zero-day on. I'm fairly confident nobody in this thread, nor anyone I know in real life, is one of those people.
Even taking hypothetical future zero-days into account, the reduction in specifically phishing risk is going to be absurdly large, the risk will be reduced at least by a factor of millions. That's very different from your original thinking that it was just some minor technical impediment that the attackers would automatically and irrevocably catch up to.
I might be wrong. But I think the position "this technology is unassailable" is much less tenable then "we might see future ways of breaching it and allowing for mass scale phishing that we are not anticipating".
edit: as someone pointed out elsewhere in this thread, SIM swapping can defeat this, so much for security.
edit: as someone pointed out elsewhere in this thread, SIM swapping can defeat this, so much for security.
Except that your initial claim was actually:
> phisher can and absolutely will catch up to this technically
That's not you saying that "there might be future ways of breaching it". That's you saying that it will absolutely and permanently be breached. And that's not a tenable statement at all.
I already went into some detail on the probability and impact of a zero-day in the technical implementation, and you engaged with none of it, so I don't think there's much point in going to those details again.
> phisher can and absolutely will catch up to this technically
That's not you saying that "there might be future ways of breaching it". That's you saying that it will absolutely and permanently be breached. And that's not a tenable statement at all.
I already went into some detail on the probability and impact of a zero-day in the technical implementation, and you engaged with none of it, so I don't think there's much point in going to those details again.
Wow yeah I didn't write a bulletproof paper in a forum.
You chose 2 tiny details of what I wrote and 100% ignored the fact that you are trying to argue that some technology will be safe against social engineering against the user (phishing) in perpetuity, which is illogical.
You chose 2 tiny details of what I wrote and 100% ignored the fact that you are trying to argue that some technology will be safe against social engineering against the user (phishing) in perpetuity, which is illogical.
I replied to every point you made in the original message, it wasn't cherrypicking just couple of details. That's because everything in your initial post was wrong. (But I also explained why passkeys wouldn't solve all security problems, and why it's still useful to just make things incrementally better rather than solving everything at once). You then tried to argue zero-days. While zero-days are possible, I replied in detail why they would not be a scalable long-term threat, and your response was to start lying about your original claim.
Note that you have provided absolutely nothing to back up your claims about how passkeys will eventually become phishable. Nor have you admitted that your theory about it happening is wrong, just complained that it's unfair to be called out on such a tiny detail. But it's not a tiny detail! Being unphishable is the entire core design goal of passkeys. You're just claiming that they don't actually have that property, while not being able to give any concrete details about why it would be so.
Note that you have provided absolutely nothing to back up your claims about how passkeys will eventually become phishable. Nor have you admitted that your theory about it happening is wrong, just complained that it's unfair to be called out on such a tiny detail. But it's not a tiny detail! Being unphishable is the entire core design goal of passkeys. You're just claiming that they don't actually have that property, while not being able to give any concrete details about why it would be so.
> it's the same for all authentication factors. People forget their passwords, have their password manager database deleted, have their phones stolen
Yes but you can at least remember the important passwords in your head. With passkeys, if you lose your devices you're dead. I don't want to rely on my devices that much.
Hint: if you use passkeys for your personal Google account, do you actually think anyone at Google will be able to help you recover access when you lose them?
If you're thinking of your work passwords yes, you can probably call or visit someone physically and they'll reset your access. Other than that, not bloody likely.
Yes but you can at least remember the important passwords in your head. With passkeys, if you lose your devices you're dead. I don't want to rely on my devices that much.
Hint: if you use passkeys for your personal Google account, do you actually think anyone at Google will be able to help you recover access when you lose them?
If you're thinking of your work passwords yes, you can probably call or visit someone physically and they'll reset your access. Other than that, not bloody likely.
> Hint: if you use passkeys for your personal Google account, do you actually think anyone at Google will be able to help you recover access when you lose them?
I mean, yes, but that's beside the point. What's more important is that I don't think anyone at Google would need to help me recover my account.
- I have multiple trusted devices signed in already, in addition to my phone
- I have a recovery phone number and recovery email set. In a situation where I lose my phone, I can get a new SIM card for the same phone number within hours.
- I have my TOTP key saved on another device besides my primary phone. (Though I have to admit that I didn't turn the backup phone on last year; I used to do it twice per year, so it's possible this doesn't work any more.)
- I have a set of 2FA recovery codes printed, and stored in a place where I'd know to look for them.
Now, obviously basically nobody else has all of that set up. Just having printed and knowing where the recovery codes are is like 99.99th percentile level of preparedness. But most of it is also totally unnecessary. In the last 10 years I've had one phone stolen and one that stopped working suddenly and irrevocably. In both cases just the stuff that basically everyone would have (getting a new SIM in one case, an existing session from a trusted device) was enough to get the account back into a good state.
Look, the people working on this stuff are neither idiots nor malicious. They understand that people lose stuff and forget stuff all the time, and they understand that the accounts can be very precious to the owners. So they try to make sure that as many people as possible have a way to recover their accounts. And as long as you haven't gone out of your way to make sure the account is unrecoverable, it'll work out fine.
I mean, yes, but that's beside the point. What's more important is that I don't think anyone at Google would need to help me recover my account.
- I have multiple trusted devices signed in already, in addition to my phone
- I have a recovery phone number and recovery email set. In a situation where I lose my phone, I can get a new SIM card for the same phone number within hours.
- I have my TOTP key saved on another device besides my primary phone. (Though I have to admit that I didn't turn the backup phone on last year; I used to do it twice per year, so it's possible this doesn't work any more.)
- I have a set of 2FA recovery codes printed, and stored in a place where I'd know to look for them.
Now, obviously basically nobody else has all of that set up. Just having printed and knowing where the recovery codes are is like 99.99th percentile level of preparedness. But most of it is also totally unnecessary. In the last 10 years I've had one phone stolen and one that stopped working suddenly and irrevocably. In both cases just the stuff that basically everyone would have (getting a new SIM in one case, an existing session from a trusted device) was enough to get the account back into a good state.
Look, the people working on this stuff are neither idiots nor malicious. They understand that people lose stuff and forget stuff all the time, and they understand that the accounts can be very precious to the owners. So they try to make sure that as many people as possible have a way to recover their accounts. And as long as you haven't gone out of your way to make sure the account is unrecoverable, it'll work out fine.
> Now, obviously basically nobody else has all of that set up.
Yep, your average hooman only has the one smartphone these days and no access to a printer :)
Yep, your average hooman only has the one smartphone these days and no access to a printer :)
Well, it's a good thing that even those people will still be able to recover their account with just a new SIM or new phone. (Depending on whether they lost the phone completely, or if it just stopped working.)
So those impenetrable keys can be reset with just a SIM clone?
What's the point then?
What's the point then?
Unlike what reading HN comments might lead you to believe, SIM swapping is neither easy nor common. It requires an insider accomplice with limited bandwidth and who is running a very real risk of getting caught. That's expensive. Just trading off the phishing risk against that would be an amazing deal for most people. (Of course not everyone, I know you'd never be fooled by a phishing attack.)
But also, account recoveries are in principle rare events, as opposed to logging in which is common. So you can and should apply very different security policies to the two cases. A very simple solution to preventing SIM swapping attacks on account recovery is to just add a delay to the recovery, and notify the user about the attempt via other channels. That means that not only does the attacker need to hijack the phone number, they also need to keep control of it for days, prevent the real user from seeing the messages and blocking the recovery attempt, etc.
(There's plenty one can do to decrease the friction and to increase the security on top of that, but even that simple solution gets you most of the way there.)
That wouldn't be acceptable in a login scenario, you can't tell the user to wait for three days for the login to complete. But for a once per decade loss of all credentials? That's a lot more palatable.
But also, account recoveries are in principle rare events, as opposed to logging in which is common. So you can and should apply very different security policies to the two cases. A very simple solution to preventing SIM swapping attacks on account recovery is to just add a delay to the recovery, and notify the user about the attempt via other channels. That means that not only does the attacker need to hijack the phone number, they also need to keep control of it for days, prevent the real user from seeing the messages and blocking the recovery attempt, etc.
(There's plenty one can do to decrease the friction and to increase the security on top of that, but even that simple solution gets you most of the way there.)
That wouldn't be acceptable in a login scenario, you can't tell the user to wait for three days for the login to complete. But for a once per decade loss of all credentials? That's a lot more palatable.
SIM swapping absolutely does not require vulnerable insiders.
It is exceedingly easy to impersonate people to corporate employees who are neither trained nor willing to be strict about identity documentation lest a legitimate client get angry and result in their termination.
It is exceedingly easy to impersonate people to corporate employees who are neither trained nor willing to be strict about identity documentation lest a legitimate client get angry and result in their termination.
Two factors are needed: something you have (your device) + something you are (your biometric). If you're concerned about losing your phone (I am), then you can backup your passkeys to the cloud and/or sync them with other devices (with end-to-end encryption of course, so that the backup/sync service has zero knowledge of your passkeys).
> Two factors are needed
If two factors are needed. They are not always. Many (indeed most) security situations do not require two factors given the risk tradeoffs. Useful for your bank. Not so much for pizza.
If two factors are needed. They are not always. Many (indeed most) security situations do not require two factors given the risk tradeoffs. Useful for your bank. Not so much for pizza.
The context was to unlock your passkeys stored on your local device.
Agreed in principle but I'd rather use something I know than let some corporation manage my biometric data.
Your biometric data are only used locally to unlock the secure enclave on your devices. Your biometric data never leave your device and are never shared with "some corporation".
You think that there's data on a networked device that is absolutely safe? I very much doubt that. Besides, if I need a device from "some corporation" to manage my biometric data, I already depend on "some corporation" for my proving who I am online. I'd much rather stick to using a secret only I know and that I can manage with offline databases managed by open source software.
Do you use keep your secrets in an offline database that is on a non-networked/air-gapped device?
[deleted]
That's whataboutism. I'm not claiming my methods are unassailable. I'm disputing the notion that anyone can claim that about their methods.
The key difference is, I know the weaknesses on my approach and I mitigate for them. I'm not reaching for whishful thinking.
Anyone claiming security by "I don't see an attack vector" should be doubted.
The key difference is, I know the weaknesses on my approach and I mitigate for them. I'm not reaching for whishful thinking.
Anyone claiming security by "I don't see an attack vector" should be doubted.
Agreed. But then what is the point you were trying to make when asking "You think that there's data on a networked device that is absolutely safe?"?
Questioning your claim of
> Your biometric data never leave your device and are never shared with "some corporation".
Like I said, I never claimed my ways are 100% safe. I am questioning the claim that biometrics on phones is 100% safe.
You realize you just whatabouted again?
> Your biometric data never leave your device and are never shared with "some corporation".
Like I said, I never claimed my ways are 100% safe. I am questioning the claim that biometrics on phones is 100% safe.
You realize you just whatabouted again?
You're moving the goalpost.
That conversation started when you explained that you'd rather use something you know than let some corporation manage you biometric data.
But it's simply not true that some corporation is managing your biometric. That's why I replied that those systems are designed so that the biometric data don't leave the device. They are only needed locally.
Yes, I shouldn't have used the word "never" because the system is probably not perfect and may be hacked. But this is true as well of using an offline password manager that you unlock using something you know (key loggers, etc.).
To conclude, I agree that biometrics on phones are probably not 100% safe, like most things in life, and computing.
That conversation started when you explained that you'd rather use something you know than let some corporation manage you biometric data.
But it's simply not true that some corporation is managing your biometric. That's why I replied that those systems are designed so that the biometric data don't leave the device. They are only needed locally.
Yes, I shouldn't have used the word "never" because the system is probably not perfect and may be hacked. But this is true as well of using an offline password manager that you unlock using something you know (key loggers, etc.).
To conclude, I agree that biometrics on phones are probably not 100% safe, like most things in life, and computing.
How are you envisioning phishing working here? The credentials are bound to a set of origins. I don't know of any passkey managers that have an option to send a passkey to the wrong origin because it just doesn't make sense.
I'm sorry but "I don't see it" is not a good argument in security. Hailing a technology as "exploit proof" should be considered a non-starter.
Any security evaluation should be about thread models, attack surfaces, mitigation and trade-offs. Never "trust us".
Not knowing how a technology could be exploited is not a feature, is a liability.
Any security evaluation should be about thread models, attack surfaces, mitigation and trade-offs. Never "trust us".
Not knowing how a technology could be exploited is not a feature, is a liability.
I think I am seeing a real clash of mind-sets in this thread.
People from a security mindset like you and I meet a lot of friction with developers who are chirpy and optimistic (and also more generally with people who want technology to be fluffy and "just work")
Not that chirpy optimism is a fault at all, we all need a little more of it, but when it crosses borders into strong beliefs that actually put others at risk I feel discomfort, and a need to challenge those ideas.
Now, not understanding complex and subtle security issues is nothing to be ashamed of, and it's wrong (arrogant) if we decry that. What is unacceptable though, is "reckless and dismissive optimism", whether that's in systems, ostensible authorities, technologies or whatever.
People from a security mindset like you and I meet a lot of friction with developers who are chirpy and optimistic (and also more generally with people who want technology to be fluffy and "just work")
Not that chirpy optimism is a fault at all, we all need a little more of it, but when it crosses borders into strong beliefs that actually put others at risk I feel discomfort, and a need to challenge those ideas.
Now, not understanding complex and subtle security issues is nothing to be ashamed of, and it's wrong (arrogant) if we decry that. What is unacceptable though, is "reckless and dismissive optimism", whether that's in systems, ostensible authorities, technologies or whatever.
Well put. I face a lot of emotional push back when people claim "this is perfectly safe because I don't see how it could be breached".
There's probably a component of pride in that people assessed the situation and decided to put trust in what they believe to be sound reasoning.
In adversarial dynamics, sound reasoning, as perfect as one can make it, is never enough. Defense takes trade-offs in convenience and imposes costs that people are more then willing to forego by depositing trust in an entity they can hold liable in court later.
There's probably a component of pride in that people assessed the situation and decided to put trust in what they believe to be sound reasoning.
In adversarial dynamics, sound reasoning, as perfect as one can make it, is never enough. Defense takes trade-offs in convenience and imposes costs that people are more then willing to forego by depositing trust in an entity they can hold liable in court later.
Biometric capture?
The endgame here is big tech wants to own identity. Tying our online existence to biometrics managed by their devices is the path towards that future.
This comment needs to be higher up.
So there's a high degree of complexity and subtlety to Passkeys. I wrote a paper about this, some key things:
● Passkeys improve security significantly, and while they make some trade-offs concerning security versus usability, they do not introduce any new attacks; they also make many existing attacks much harder or impossible (e.g., brute forcing attacks or credential stuffing)
● Passkeys will bypass the hurdle of getting people to use password managers, and will likely result in the widespread use of biometrics to secure their Passkeys
● Passkeys can potentially make account sharing harder once attestation is supported, something a lot of service vendors are in favor of. Passkeys are also easier to deploy at scale and more reliable, thanks to supporting device synchronization. Passkeys should also reduce the need for account recoveries and lower support costs when compared to passwords
● Passkey client support in both software and secure hardware tokens is widespread and available now on most platforms, browsers and many third-party password managers
● Passkeys are being supported by major vendors (e.g., as of October 10, 2023, Google announced: Passwordless by default: Make the switch to passkeys, for Gmail users, and Google Workspace administrators can enable it)
https://cloudsecurityalliance.org/artifacts/beyond-passwords...
And if you want to quickly check what the passkeys-related capabilities of your preferred platforms are:
https://passkeys.dev/device-support/
And to see what the state is of the services you use:
https://passkeys.directory/
The TL;DR: there's a LOT of good stuff with passkeys, but there are some concerns a lot of people aren't thinking about, e.g.
Passkeys as a Requirement vs. Option
Implementing Passkeys, as a provider, does not mean that all authentication must be done via Passkeys. For example, the Cloud Security Alliance generally supports SSO via Apple, Google, Linkedin, and Microsoft, and we support a “classic” username and password-style login. The reason for this is simple: not everyone has or can get an account with one of the SSO providers listed. This is also why we do not require 2FA/MFA: you can choose to use 2FA/MFA with your SSO provider, but the Cloud Security Alliance does not require 2FA/MFA to ensure that people who do not have access to a device that supports 2FA/MFA are also able to access and use our systems.
However, for many providers, at scale, it is viewed as a better option to get rid of passwords entirely and move people over to Passkeys wholesale. Many also feel that users cannot be asked or given the option to move to Passkeys as they will simply ignore it (and based on seeing multiple 2FA/MFA rollouts, this is true). Requiring Passkeys in favor of passwords will, of course, largely put an end to phishing and credential stuffing against accounts. Phishing and credential stuffing attacks would still be possible against account recovery processes, but as previously discussed, this is not a new or significantly increased vulnerability. Requiring Passkeys also has the ugly possibility of effectively locking out people who do not have access to a device that can use Passkeys (there are still people who do not own a smartphone or computer but instead rely on public access computers, for example).
Balancing the overall security health of a large group of users vs. adversely affecting a disadvantaged group is something that vendors deploying Passkeys will need to consider, especially for “free” services that many people rely upon (like email).
edit: formatting.
● Passkeys improve security significantly, and while they make some trade-offs concerning security versus usability, they do not introduce any new attacks; they also make many existing attacks much harder or impossible (e.g., brute forcing attacks or credential stuffing)
● Passkeys will bypass the hurdle of getting people to use password managers, and will likely result in the widespread use of biometrics to secure their Passkeys
● Passkeys can potentially make account sharing harder once attestation is supported, something a lot of service vendors are in favor of. Passkeys are also easier to deploy at scale and more reliable, thanks to supporting device synchronization. Passkeys should also reduce the need for account recoveries and lower support costs when compared to passwords
● Passkey client support in both software and secure hardware tokens is widespread and available now on most platforms, browsers and many third-party password managers
● Passkeys are being supported by major vendors (e.g., as of October 10, 2023, Google announced: Passwordless by default: Make the switch to passkeys, for Gmail users, and Google Workspace administrators can enable it)
https://cloudsecurityalliance.org/artifacts/beyond-passwords...
And if you want to quickly check what the passkeys-related capabilities of your preferred platforms are:
https://passkeys.dev/device-support/
And to see what the state is of the services you use:
https://passkeys.directory/
The TL;DR: there's a LOT of good stuff with passkeys, but there are some concerns a lot of people aren't thinking about, e.g.
Passkeys as a Requirement vs. Option
Implementing Passkeys, as a provider, does not mean that all authentication must be done via Passkeys. For example, the Cloud Security Alliance generally supports SSO via Apple, Google, Linkedin, and Microsoft, and we support a “classic” username and password-style login. The reason for this is simple: not everyone has or can get an account with one of the SSO providers listed. This is also why we do not require 2FA/MFA: you can choose to use 2FA/MFA with your SSO provider, but the Cloud Security Alliance does not require 2FA/MFA to ensure that people who do not have access to a device that supports 2FA/MFA are also able to access and use our systems.
However, for many providers, at scale, it is viewed as a better option to get rid of passwords entirely and move people over to Passkeys wholesale. Many also feel that users cannot be asked or given the option to move to Passkeys as they will simply ignore it (and based on seeing multiple 2FA/MFA rollouts, this is true). Requiring Passkeys in favor of passwords will, of course, largely put an end to phishing and credential stuffing against accounts. Phishing and credential stuffing attacks would still be possible against account recovery processes, but as previously discussed, this is not a new or significantly increased vulnerability. Requiring Passkeys also has the ugly possibility of effectively locking out people who do not have access to a device that can use Passkeys (there are still people who do not own a smartphone or computer but instead rely on public access computers, for example).
Balancing the overall security health of a large group of users vs. adversely affecting a disadvantaged group is something that vendors deploying Passkeys will need to consider, especially for “free” services that many people rely upon (like email).
edit: formatting.
> login details for the 337 accounts I've made—from pizza delivery and
airlines to social media and online shopping over more than a decade
online.
That's a pathological lack of account management and pruning. Likely less than 100 of those are still active and the author will probably use less than 50 of them ever again. A better strategy is to simply not use services that request you "set up an account", or treat them as disposable and set up a new one each time you need an obstinate online service.
Edit: Do please have the good manners to make a cogent argument instead of down-voting what you merely disagree with. Is it not apparent that simply having so many accounts is, in itself, a serious security problem you could be addressing?
That's a pathological lack of account management and pruning. Likely less than 100 of those are still active and the author will probably use less than 50 of them ever again. A better strategy is to simply not use services that request you "set up an account", or treat them as disposable and set up a new one each time you need an obstinate online service.
Edit: Do please have the good manners to make a cogent argument instead of down-voting what you merely disagree with. Is it not apparent that simply having so many accounts is, in itself, a serious security problem you could be addressing?
The reason you're getting downvotes is because your comment is irrelevant. The point of the article is the transition of passwords to passkeys. Minimizing the number of accounts you have has absolutely nothing to do with that. If the point of the article was about optimizing your online security posture, and passkeys as a method for that, then your comment would be more relevant.
The reason no one replies and just downvotes, is because we don't want to clutter up the discussion with even more irrelevant comments. Usually I'd do the same, but for the chance that you are really commenting in good faith and not a troll, I thought I'd present you with a learning opportunity.
The reason no one replies and just downvotes, is because we don't want to clutter up the discussion with even more irrelevant comments. Usually I'd do the same, but for the chance that you are really commenting in good faith and not a troll, I thought I'd present you with a learning opportunity.
> The point of the article
It's fine that you found that to be the singular "Point" of the article. Discuss that if you like. But no, sorry, articles do not come stamped with "This is the point from which you will not diverge". My remarks are both relevant and valid and I do not wish you or anyone else to tell me what you think the "Point" of the article is. These comments are made in good faith (please don't bandy specious accusations of trolling) to address what I and many others consider a widespread misunderstanding around password security.
It's fine that you found that to be the singular "Point" of the article. Discuss that if you like. But no, sorry, articles do not come stamped with "This is the point from which you will not diverge". My remarks are both relevant and valid and I do not wish you or anyone else to tell me what you think the "Point" of the article is. These comments are made in good faith (please don't bandy specious accusations of trolling) to address what I and many others consider a widespread misunderstanding around password security.
I agreed with you, but I kept quiet because I am not a sensible person and I didn't want to make you look bad. But yes, my immediate reaction to the article was "just don't sign up for things, have a small number of passwords for a small number of vital things, no problem."
Somewhere I have a page in a notebook with 20 or so passwords written down (in the basic cipher I've used since I was 12). If this was stolen, after some effort, the thief would be able to access things like ... a forgotten Github account, my abandoned efforts to learn from Duolingo, and a Reddit account I haven't used for two years. I would be mildly irritated. I am happy with this arrangement.
Somewhere I have a page in a notebook with 20 or so passwords written down (in the basic cipher I've used since I was 12). If this was stolen, after some effort, the thief would be able to access things like ... a forgotten Github account, my abandoned efforts to learn from Duolingo, and a Reddit account I haven't used for two years. I would be mildly irritated. I am happy with this arrangement.
> my immediate reaction to the article was "just don't sign up for
things, have a small number of passwords for a small number of vital
things, no problem."
I recently interviewed a bunch of people in the age range of 30 to 70 on "personal cybersecurity". A surprisingly large number, no, in fact the overwhelming majority though the same way as you... once you get to the limits of your memory with passwords it's dangerous and counterproductive to reach beyond that and it's time to cull and prioritise according to "attic theory" :)
Unfortunately many online services don't make it easy to delete accounts, nor do they time out after a sensible period like one year.
> Somewhere I have a page in a notebook with 20 or so passwords written down (in the basic cipher I've used since I was 12)
Before anybody tells you that "using a basic cipher" is weird or eccentric, maybe half of the over 50s I spoke to, all regular folks, told me they use the same paper notebook kept in a safe place at home plus some obfuscation. Also about "two dozen" (24) accounts seems the average pool.
Any more than that and I think the system is working backwards, placing an undue security onus onto the person and not the service.
Passkeys have their use (I keep some super important pass phrase protected ssh keys somewhere physically safe). And some people need to maintain a very large collection of access tokens, like if you're a system administrator and that's your job.
But I think creating a tower of cards that enables people to maintain over 300 accounts for casual, personal use, is a disservice and actually encourages bad security practices.
I recently interviewed a bunch of people in the age range of 30 to 70 on "personal cybersecurity". A surprisingly large number, no, in fact the overwhelming majority though the same way as you... once you get to the limits of your memory with passwords it's dangerous and counterproductive to reach beyond that and it's time to cull and prioritise according to "attic theory" :)
Unfortunately many online services don't make it easy to delete accounts, nor do they time out after a sensible period like one year.
> Somewhere I have a page in a notebook with 20 or so passwords written down (in the basic cipher I've used since I was 12)
Before anybody tells you that "using a basic cipher" is weird or eccentric, maybe half of the over 50s I spoke to, all regular folks, told me they use the same paper notebook kept in a safe place at home plus some obfuscation. Also about "two dozen" (24) accounts seems the average pool.
Any more than that and I think the system is working backwards, placing an undue security onus onto the person and not the service.
Passkeys have their use (I keep some super important pass phrase protected ssh keys somewhere physically safe). And some people need to maintain a very large collection of access tokens, like if you're a system administrator and that's your job.
But I think creating a tower of cards that enables people to maintain over 300 accounts for casual, personal use, is a disservice and actually encourages bad security practices.
I think people are reacting to what seems like an attack: the implication that having hundreds of accounts and not studiously pruning them is ‘pathological’. But I think your point is actually a valid one - yes, you can over time accumulate vast numbers of logins, but do you really need to hoard the login details? The majority of the passwords I have in 1Password are in the ‘Never Used’ section. I am definitely not going to spend the time to delete these accounts with the provider, but some I probably could have avoided creating in the first place and it’d probably improve my quality of life if I just delete the entry in 1Password and rely on email recovery or a new account if I ever went back. But, I’m not going to do that, because it’s really not much hardship and to be honest I appreciate the breadcrumb trail of my life on the internet for the past 30 years.
As for the security implications, if you want to hack the account to some magazine I was subscribed to 10 years ago, supply new payment details and reactivate my subscription, go wild. If you’re losing sleep about that sort of thing then it really _is_ pathological.
As for the security implications, if you want to hack the account to some magazine I was subscribed to 10 years ago, supply new payment details and reactivate my subscription, go wild. If you’re losing sleep about that sort of thing then it really _is_ pathological.
Sorry I should be more careful with my words.
"Pathological" is one of those words that lives in both technical and psychological space and I was careless. I meant the security situation was pathological, not that the poster "is a nutter". My apologies to OP.
If I am "attacking" anything it's this casual normalisation of over-extending, invoking more complexity and solutionism and misplaced trust in elaborate systems when simple everyday methods actually work well enough for 99% of cases.
"Pathological" is one of those words that lives in both technical and psychological space and I was careless. I meant the security situation was pathological, not that the poster "is a nutter". My apologies to OP.
If I am "attacking" anything it's this casual normalisation of over-extending, invoking more complexity and solutionism and misplaced trust in elaborate systems when simple everyday methods actually work well enough for 99% of cases.
> As for the security implications, if you want to hack the account to
some magazine I was subscribed to 10 years ago, supply new payment
details and reactivate my subscription, go wild.
Here. I suggest think again. There are many threat models where your innocuous grocery account from 10 years ago is a useful stage to a bigger hack. Can you remember all the details you entered there? Past addresses, phone numbers, shipping addresses?
Here. I suggest think again. There are many threat models where your innocuous grocery account from 10 years ago is a useful stage to a bigger hack. Can you remember all the details you entered there? Past addresses, phone numbers, shipping addresses?
If you want my address you can just google it, I'm not going to spend any time worrying about it.
I disagree, I also have a large number of accounts (in online shops for example) that I forget about and 3 years later when I make a purchase in the same shop my password manager reminds me I already have an account there.
Just to be clear, you're disagreeing that having a huge number of
dormant accounts is untypical, or disagreeing that a huge number of
dormant accounts you've forgotten about is a security risk in itself?
Both. I don't mind creating accounts for shops that have what i want, and maybe buy once every three years (e.g. clothes, photo gear...). So I end up having a couple hundreds of accounts.
Are they a security risk? Don't think so, as I use a different password for each one, and a different TOTP. And always pay a single use card.
What you seem to be suggesting is "buy everything on Amazon, and don't use small shops". (Incidentally I don't use Amazon at all because they don't support single use cards, and they are always trying to sell me the Prime in sneaky ways).
Are they a security risk? Don't think so, as I use a different password for each one, and a different TOTP. And always pay a single use card.
What you seem to be suggesting is "buy everything on Amazon, and don't use small shops". (Incidentally I don't use Amazon at all because they don't support single use cards, and they are always trying to sell me the Prime in sneaky ways).
If a secure passphrase was used originally what is the security risk? I have 800+ accounts in my Bitwarden and I fear not as each password is long and randomly generated.
> Passkeys replace passwords with cryptographic key pairs [...] synced between the user’s devices via a cloud service. [...] stores an encrypted copy [...] Passkeys can also by design be available only from a single device from which they cannot be copied.
> "single-device passkeys” [...] a physical security key could contain multiple single-device passkeys.
> [...] generally referred to as “synced passkeys”, and those that never leave a single device are referred to as “device-bound passkeys”.
So, your keys will rely on:
* The cloud,
or
* Some specific phone,
or
* Some specific USB key.
> They can’t be guessed, leaked, or stolen
So, they can be lost. Also, stolen.