Microsoft Confirms Password Deletion for 1B Users
forbes.com
forbes.com
Imagine you're on vacation and have lost your phone. You want to go to a cafe and log into a chat app, an email service, whatever to contact your family. In the world that passkey advocates want this is impossible via the passkey flow. If you can't authenticate via a primary device that contains your private key, you're f-ed. Service providers know this so of course they will provide recovery mechanisms. (Not consistent recovery mechanisms of course, each will have their own convoluted and likely to be broken ones). If the recovery mechanism allows for knowledge based recovery (challenge questions) then you're basically telling people that they need N passwords rather than one password. Maybe that challenge question is just a long password (recovery key). Maybe it requires access to another system, which you likely don't have in this circumstance. So you're either back to having passwords, or you're f-ed. Security theater or a disaster.
A service only has value if I can access it. I should be able to sit down at any computer in the world with the knowledge in my head and get access to any online service to which I subscribe.
The big benefit to a passkey for a service provider is that when you see a user using one, you can assert things about that session—that this is the users device, that the session isn’t likely to be spoofed, etc. These are useful things to know if you want to implement any kind of context-aware access!
Passkeys certainly aren’t a silver bullet, and I don’t think they’re really marketed or implemented well a lot of the time, but I’d caution against writing off the tech as a whole .
Next up, cloud based passkey proxy services. Store your passkeys there they auth for you after you give them some other damn auth method.
Garbage standard, terrible implementations everywhere, my favorite is when logging in with a passkey they still demand SMS 2FA.
Laypersons probably don't see ATOs at scale. I worked at a fintech and it was a relentless uphill battle to protect our users. We saw massive distributed login attempts daily and constantly bought compromised passwords on the gray market to run against our users' accounts. We tried to encourage better password hygiene, 2FA, Fido, etc.
You have to protect users from their own misunderstanding. When it comes to their bank accounts, improper security can be life-changing.
The term "security theater" itself is often thrown around to criticize when it's completely undeserved. Lots of people use it to poke fun at the TSA, but the term totally dismisses the fact that hijackings have plummeted [1,2]. The TSA does its job.
[1] https://www.statista.com/statistics/1240246/aircraft-hijacki...
https://www.nbcnews.com/news/us-news/investigation-breaches-...
Hijackings are down because pilots lock the door to the cockpit now
Your graphic shows 'worldwide' data rather than US data. How would the TSA be involved in reducing hijackings on flights outside of the US? The connection seems spurious at best.
We could just as easily argue that hijackings correlate with other violent crime and the reduction in violent crime worldwide has led to their decline. Or that increased prosperity worldwide mitigates hijackings. There's very little basis to believe that TSA has anything to do with it.
Would you be interested in buying my rock that wards off tigers? Ever since the great Tiger apocalypse where the premier military power in the world went on decades long quest to kill all of the tigers and everyone learned of the dangers of tigers, my rock has been extremely effective at warding off tiger attacks. For just 12 billion dollars a year (adj for inflation annually) (https://www.tsa.gov/news/press/testimony/2024/04/16/fiscal-y...), you could have this extremely effective rock.
edit: I'm pretty sure I clicked reply on GP's comment. Weird.
People do need protected from themselves (that's generally the point of regulation, lobbying aside)
Do you use single, easy-to-remember plain-text passwords for all of your accounts and services? If not, you need to understand what the recovery process is when your passkey/2FA/pw-manager is unavailable or lost.
The problem with passkeys isn't the concept, it's the lack of flexibility in implementation.
It works ok!
https://developer.android.com/about/versions/14/features#cre...
https://www.dashlane.com/blog/dashlane-passkey-support-ios#:...
Perhaps passkeys are more viable now with these changes? I'll need to give it another go and see. Thanks for the tip!
It’s a pretty powerful/complex spec allowing various use cases, from a modern way to store SSH keys on hardware credentials to a more usable and less phishable password replacement backed entirely by software.
I think I've heard that the passkeys providers have an option to force it to be hardware, but I've yet to encounter that, and it would also make me quite cross without a very good reason. I, personally, do not want my accounts tied to any particular bit of hardware, I want it tied to the single (very!) strong password I use for everything.
Edit: Browsing through the rest of this HN conversation it seems the password managers have some PR to do. Many HNers are not aware that password managers, even perhaps the one they are already using, have the ability to store passkeys in them. If HNers don't know, certainly outside of the HN bubble it must be even less well known.
If the functionality is built in, don't be surprised when they alter the deal and force it on you. What are you going to do if no one lets you use or migrate back to a username / password at that point?
We've seen the same thing thousands of times from big tech. They give us a system that's tolerable, but designed to leverage us into a bad position in the future. Once there's a critical mass, they'll flip the switch and we'll all get screwed.
(Also, be sure to understand that being forced to hardware is not "you must use a phone"... it is specifically "this passkey is locked to this Yubikey and can not by any means be moved to any other device". I don't think we're going to be stuck on that. Plus I haven't dug into the protocol but I'm not sure anything stops BitWarden from just claiming to be hardware.)
That said, my eyes are peeled, and at the moment the momentum is in the other direction, in that they actually headed away from that.
I think this is because it's so new with these apps. 1password acts really strange with them sometimes and my chrome extension will lock up or not actually push the passkey through or whatever it does. Sometimes I just get annoyed and throw it wherever worked.
When they're flawless they're awesome. I don't mind the quirks right now.
Knowledge-based access is inherently problematic: if you don’t police passwords, most people will be compromised because they use weak and/or shared passwords. If you use strong passwords, you’re also screwed if you lose your phone so you’re in the same reset game with trivia questions which are increasingly weak because they can be answered from information on Facebook/LinkedIn or from breaches from other companies which used the same question. New logins from previously unused devices in a new part of the world shouldn’t work anyway because that’s indistinguishable from a successful attack.
Passkeys avoid all of that, but you need backups either in the form of a Yubikey or a recovery code in your wallet. Yes, that’s annoying but there is no world where nobody is annoyed, so it should be a question of whether more people are inconvenienced by their accounts being breached versus traveling and losing all of their devices but still being able to remember their strong passwords.
I have the NFC enabled variant so it can be used with a mobile phone
Why should I be forced to pay for a YubiKey? €60 is a fair chunk of money.
Maybe buy me one I'll consider it otherwise I'm not convinced. I will once corporate gives me free open-source hardware.
The fact that this user thinks the average person would be happy to have to cary one around is wildly out of touch.
That's my point.
Yubikey doesn't pass the grandma test. Your everyday user isn't going to be carrying one around anytime soon.
With passkeys via yubikey it's insert key, enter pincode (just like at the atm), touch and go. You don't even have to enter your account name or email because that's derived automatically.
Anyone who can get cash out can use a yubikey. Very different for MFA apps.
I still stand by the idea that most users wouldn't be happy having to cary it around. We can't even get most users to use password managers which are built into their phones (1 in 3) and there was a collective meltdown when Apple removed the headphone jack which required people to cary a dongle for wired headphones. Telling people they need to cary around a yubikey for anything they want to log into just isn't going to fly.
https://www.security.org/digital-safety/password-manager-ann...
I think you’re right, any change has to fight against the “this is how I do it already” inertia.
The problems are the "corner" cases: enrolling new keys, removing old keys, handling unintentional destruction of the key. The last one, in particular, is really problematic.
Some of the security mechanisms that a YubiKey provides are an extreme inconvenience. For example, I want to be able to clone my key via some mechanism in case it gets destroyed. I don't want to have to enroll 3 separate keys in every service on the planet just in case I put one in the wash accidentally. That's not possible with a YubiKey--for good reason--but it's a significant annoyance.
We consider "duplicating a physical key" such a common need that we have automated machines to do it at 7 Eleven. The fact that we don't have the same consideration of digital ones is problematic.
It's a real shame, as I'd also love "Yubikey twins" of which I can put one in a safe deposit box and have the other one always with me, without needing to periodically synchronize them to all services I'm using them on.
Password managers have the added complexity of still needing a password themselves and all the quirks that come with auto filling and programmatically reading forms.
I'm not sure Apple head phones are quite a fair comparison. Outrage was also due to proprietary connectors that were patent encumbered.
1. Not everyone caries keys (I don't and haven't for years)
2. Because every other existing alternative doesn't require you to cary something extra. Asking people to cary something with them to be able to sign into accounts will feel like a step backwards to most people.
3. Because most people only need to pull out their keys a few times a day. Requiring a Yubikey for every sign in means you'd now need to constantly be pulling your Yubikey out to sign into things.
> Password managers have the added complexity of still needing a password themselves and all the quirks that come with auto filling and programmatically reading forms.
I don't buy this. I use Lastpass which is arguably the most widely used password manager. I sign in using the master password maybe once a month and it works seamlessly on my phone. Apple and Google both have their own native solutions as well and still only 1/3 of people use them.
> Outrage was also due to proprietary connectors that were patent encumbered.
I think you're living in a bubble. Just go look back at the headlines from when that was announced. Almost no one gave a shit about it being a proprietary connector. People were upset because they were being forced to buy and cary a bunch of dongles. Just look at the comments on these reddit posts:
https://www.reddit.com/r/funny/comments/5a6lbd/it_just_works...
https://www.reddit.com/r/funny/comments/5j66d4/the_world_isn...
https://www.reddit.com/r/dankmemes/comments/ox3s26/apple_do_...
I just leave it connected to my computer. It requires a physical touch for every interaction so it can't be 'milked' for tokens like old fashioned smart cards.
Physical keys work in one (or rarely in several, but basically unchanging set of) locks, and I carry around about 2-3 of them.
Hardware security keys, by contrast, work in many different places/accounts, potentially even for multiple accounts on the same service, but only after registering them there.
That's not how people experience physical keys: You don't, for example, move apartments or visit a friend, and the landlord/friend "registers/adds your key for their lock". If you lose your physical key, you can't "quickly revoke it from all doors" that it locks (without kicking everybody else out).
Now I only have the Yubikey as a backup authenticator for my most valuable accounts and use a software solution for most low-value things.
Yubico had some ideas around "paired Yubikeys" which shared the same root secret, but I believe that model won't work anymore with FIDO/CTAP2 due to some counter value that was added there over U2F. (It might be possible for them to just not have a security counter; I'm not sure.)
The bigger issue with yubikeys is that you need more than one in case you lose one. And most sites only allow one passkey per account because all the mobile implementations can sync the private key. Yubikeys can't and that's actually a good thing because it makes them unique and eliminates the whole sync mechanism as an attack plane.
Even when/if sites do allow multipe passkeys per account, the fundamental contradiction remains: Your backup key(s) are supposed to be kept somewhere secure where they won't get lost, stolen or destroyed, which ideally means some sort of off-site backup (at your bank or whereever), but at the same time every time you register for a new service you do need to register all your backup keys, too.
Not that I worry about that, but it is worth pointing out that you may lose some legal protections when you use physical things rather than your knowledge.
More to the point, this is also not what the average computer user is worried about. It assumes that they’re targeted by police, have something they need to keep secret, and that those police can compel physical access but scrupulously obey civil rights protections.
Additionally, it's a bit silly in the context of email since the authorities will obtain it from the service provider anyway.
That said, you can still add an encryption key to your phone and you're back to "knowledge based" with the additional caveat a thief would also need the hardware as well.
[1] https://news.ycombinator.com/item?id=33550824
[2] https://www.selectlawpartners.com/faqs/do-you-have-to-give-p...
There's nothing preventing you from password-protecting your YubiKeys.
Exceptions do exist; two I can think of are passkey-based cryptocurrency wallets and the so-called "PRF extension" that allows using a passkey as a source of entropy for e.g. locally encrypting a password manager's database.
We're not talking about annoyance here, we're talking about data breaches on the one hand and permanent account lockouts on the other. There is no world where the majority of people remember distinct passwords for each service, and there's likewise no world where the majority of users carry a Yubikey or even download their recovery codes at all, much less carry them with them.
So we're left really with two choices at the extremes: do we go for the failure mode where people reuse passwords and lose money and data that way, or the failure mode where a company is physically incapable of restoring a customer's account? Given the choice between these extremes, companies will always choose the former.
Now, these extremes aren't the only choices, but then you get to the crux of OP's argument: passkeys stored in a password manager aren't any more secure in practical terms than random passwords stored in a password manager. Your auth system is only as secure as its recovery mechanism (which is the observation that led Slack to initially not bother with passwords at all).
There's one way in which I disagree with op, which is that passkeys prevent users from typing in a password and storing it in the password manager, which many users do—they effectively enforce random passwords rather than it being just a best practice that needs to be taught.
Are you sure that Microsoft’s solution means that they are “physically incapable of restoring a customer’s account?” Apple’s system keeps copies of recovery keys in their cloud [1], unless you explicitly tell them not to do this. It seems like a reasonable compromise for most people’s security needs.
[1] Or effectively something like that.
And this is an important distinction to make—if passkeys have a terrible UX (which right now they absolutely do) and are only marginally better at phishing protection than a password manager, they could actually be a less secure solution overall by encouraging lazy workarounds.
It is my contention that this statement is:
1. Categorical,
2. False, and
3. Categorically false
From the questions and comments across the rest of this thread, the misunderstanding here seems clear: the person I'm responding to did not realize that FIDO2 cryptographically binds credentials to sites.
If my password manager running on my desktop can provision and access the passkey for use on another device like my phone, then so can malicious code running on my desktop, and exfiltrate it to hackers. The original design, where the private key only exists on a TPM and the private key never leaves the TPM doesn't have that flaw.
I think there’s a place for both of them in WebAuthN based on the security/availability/convenience tradeoff which will be different for every application.
If you care about your users only using the trusted hardware, non-synchronizing kind, you have to use attestation anyway (or malware running on their device could create credentials that only appear to be backed by secure hardware).
Unfortunately both Apple and Google seem to have unshipped their attestation support without replacement (they used to support hardware backed credentials in their devices too for a while) in the interest of not confusing users about what is and isn’t synchronized – now everything is.
PayPal does this already by only allowing safari or chrome. With bitwarden on Firefox I'm locked out.
> PayPal does this already by only allowing safari or chrome. With bitwarden on Firefox I'm locked out.
It works for me! However I do vaguely remember having to set them up on Chrome initially, but after that, they now work well even in Firefox. (Only on my computer; on my phone, I get an absurd non sequitur of "security keys only work on desktops").
Oh ok, I haven't tried that. I don't even have Chrome installed anymore.
And yeah I get that message too on my phone, even with standard FIDO2 MFA (not full passwordless Webauthn). Stupid because it does work just fine with other sites.
Attestation is already coming. Why do you think Microsoft is pushing TPM2.0 so hard?
Apple and Google very intentionally threw FIDO attestation out of the windows without replacement, and Microsoft frankly doesn't matter enough for non-corporate contexts at this point. (Imagine your bank only allowing passkeys on Windows, but not iOS, Android, or macOS.)
And yeah I moved away from Mac for this reason among others. My devices should answer to me and me alone.
But I think the upheaval in the 2000s helped to make the TPM not the horror scenario it could have been. I don't think the ruckus was overblown at all. Don't forget Microsoft still wanted to kill Linux back then.
And yes Apple has tpm. It's just built into the cpu and called differently.
Yeah, so does Google. But as mentioned before, even though they were both using it for WebAuthN in the past, they both stopped doing so.
What stronger proof for attestation being dead in the context of WebAuthN can you possibly get than the two largest implementers actively discontinuing it?
There are many good reasons to be cautious of how attestation is used and critically examine who it serves – a company you're doing business with, you, or both – but in this specific context, it's arguably no longer relevant.
This really embodies what's wrong with the world in 2024 — people believing in their world views so strongly that they ignore actual real world evidence that is directly contrary to their very strongly held but incorrect world view.
Every release macOS got more closed and removing features I cared about. At the same time introducing stuff that only works if you're all-in on Apple. Half the new features of every release didn't apply to me because I use so many different systems. I use every OS under the sun. So that didn't work for me. Because all Apple's cloud stuff works on Apple alone (with a handful of exceptions on windows).
The lock-in of passkeys was just one of the things that bothered me. Not really the attestation per se, I'm aware it doesn't currently have it though I wouldn't be surprised if they introduce it if passkeys actually take off.
But like I said, Apple does have hardware control over other features. They do have a secure element which is just like a TPM which blocks you from changing certain files on the system and if you disable system integrity protection they turn off some of the features of the OS, like the ability to use iOS apps on macOS. It's basically DRM. That was the other thing that bothered me. For example, I used to simply boot into recovery and make a 'dd' image of my laptop. I can't do that anymore on an Apple Silicon mac. I used to change my sshd_config to block password auth but since SIP the file got reverted back with every system updated and dumped on the desktop in a passive-agressive move. I just don't want Apple to have more control over my system than me.
This was really what got me to hate macOS, it's just not fit for purpose for me anymore. I have never liked opinionated design but in the beginning of macOS X my opinion was much more aligned with that of its developers.
Android calls it the Play Integrity API now. Hardware-backed enforcement isn't reported from the attestation servers to 3rd-parties yet because there are still a few old devices with broken implementations, but that switch can be flipped at any time.
The only remaining gap is Windows.
You can't read out a passkey, nor can you read out a challenge to somebody that they are to sign with their passkey, because it's not possible by design.
This isn’t true, and that’s where your confusion comes in. Passkeys cannot be phished because the protocol includes the server name and does not expose the key to the remote server. The past decade of U2F/FIDO/WebAuth deployment has used that as the marquee selling point because it’s a very common exploit which cannot easily be prevented with traditional passwords and MFA.
the only difference is maybe in-app browser where the passkey integration might work more easily but even so:
1) it is still a matter of integration and/or using an actual browser
2) in-app browsers are inherently insecure anyway (at least on android)
No, it doesn’t. Most password managers allow you to fill passwords for other domains and all of them allow copy-paste. The people who support those users know that phishers can convince people to do that which is why they’re encouraging adoption of WebAuthn.
Another factor here is the number of logins that a user is required to perform. Anecdotally this seems much higher in a corporate setting than personal. I might login to Microsoft SSO 15+ times per day for different services. Signing in to apps on my phone is rare.
“Secure, comprehensive backups” sounds scary until you remember that it’s only ever meant not disabling a checkbox for iCloud, Google, or Microsoft users.
Any solution which does not allow me full autonomy to maintain a backup is not acceptable.
Not from the company's perspective, from the individual's.
Right: it's on the small device I take everywhere and use for everything. The one most likely to get lost, stolen or completely destroyed, and absolutely has to be replaced in about 5 years.
That device. You want to permanently lock data to that thing?
(My phone is basically disposable in terms of my expectations for it's future survival, and man do I not like the Android recovery options still)
This is why no passkey implementations do this: the mainstream implementations all require synchronization and if you read e.g. Apple’s iCloud documentation note that the offline recovery mode is designed for the case where all of your devices are lost:
Passkey synchronization provides convenience and redundancy in case of loss of a single device. However, it's also important that passkeys be recoverable even in the event that all associated devices are lost. [...] To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number. After they authenticate and respond, the user must enter their device passcode.[...]"
And we get back to knowledge based auth in the end.
So don't put it on only your phone, put it on your phone, your laptop, your desktop, and maybe a physical hardware token. Lose all but one and you're still fine.
I lost my phone. I don't bother with the cloud sync'd passkeys. I didn't lose any of my identities, because I had access through other devices.
If the giant meteor comes crashing down to destroy everything around me, I don't think I'll be that concerned about getting locked out of a video streaming site.
Even if I have a house fire. Small chance it'll actually destroy all my devices and paper recovery codes. And the odds of having that house fire is also pretty low.
If a tornado destroys my house, chances are my hardware tokens will survive. More of a question of where they ended up. A tornado destroyed my brother's house, his iPad ended up just fine.
I don't really live in an area where landslides are possible. If I did I'd probably want to plan around that with the passkeys. But that's true for a number of things at that point though.
What if every device hosting a password safe breaks?
A password safe, I can trivially backup however I wish. The cloud, a USB I keep at mom’s house, print it out, whatever (in fact, I do maintain encrypted offsite backups in a couple of locations).
Boy do I have good news for you then. Passkeys can often be stored in many available password safes. Bitwarden, KeepassXC, LastPass, 1Password, Dashlane, and more all support passkeys. Make one on whatever device, one in your password safe, and you'll have redundancy.
And I'm not talking about people needing to carry two $1,000 phones or a $1,000 phone and a $1,000 laptop. You could have your second key be a small, cheap (<$40), durable authenticator. Another thing on a keychain, another card in a wallet. Really that big of a deal?
And if that's truly impossible for you, then sure I'll agree passkeys might not be for you. I agree, some people like those who are homeless have a hard time keeping any material goods safe. I'm not arguing every account for every person needs to be only passkeys. But people here are acting like it's something impossible for nearly anyone to use safely. And I don't think that's based in reality. I think a lot of people could use them safely if they wanted to, but there's a massive amount of FUD about them.
See the section titled "Recovery security" in this support article:
We just consolidated everybody's login into one platform. One monolithic database that contains the PII of EVERYONE.... What could present a bigger, better target than that? It's literally too good to pass up. Previously an attacker would have to compromise half a dozen vendors in order to completely pwn someone. Now they just need access to one.
Additionally, password managers are dangerous. Not a single one or them has been able to go more than 12 months without reporting a significant hack. Just another consolidated attack vector.
Like VPN providers. Why would I scourge the internet to gather browsing history of a target when the user has already consolidated that information into once place for me?
So no, please don't blame people, blame bad authentication mechanisms (including passwords) and those that hang on to them despite better alternatives.
> There is no excuse for using weak passwords anymore.
Weak passwords are only a small part of the problem. You can get phished with even a 256-bit equivalent random string.
https://www.infosecurity-magazine.com/news/nist-scraps-passw...
Because taking a holistic look at an entire system and attempting to improve it is better than relying on each and every individual. Take aviation for example. If there is a plane crash and it is found that the pilots ignored a warning indicator, they look and see if the warning was prominent enough, if it is properly prioritized, and if it is something that can be corrected at the system level. Pilot training is only one of many factors they look at, and human error is taken as an inevitability.
In aviation, pilots are highly trained and highly regulated. With accessing services online, it is basically universal access by all people of all skill and intelligence levels. Making a system more inherently secure is the only reasonable solution.
I don't like it that the solution is to usurp control from the user and gate authentication through what will, in my opinion, ultimately be a small number of big tech companies. We'll eventually be dependent on having an Android phone, an iPhone, a Microsoft account, or similar. It'll be a world of "trust me bro" credential managers and you'll have to hope you never get banned by the big tech companies because it'll have a life altering impact if that means losing access to all of your accounts.
The reality is that big tech has proven we can trust them because we're nothing more than 1 of a billion customers as far as they're concerned.
> Passkeys avoid all of that, but you need backups either in the form of a Yubikey or a recovery code in your wallet.
Passkeys create a huge burden in the context of managing devices and recovery codes.
To start with, I'm not a fan of recovery codes. I have so many accounts that it's almost impossible to keep track of all the recovery codes. I have to organize them well enough that anyone who would happen to get access to my file cabinet would own my life.
To mitigate that, I need a system for tracking which recovery codes I have in my file cabinet and I need a plan for rotating / revoking them if anyone gains access to them. Even worse, printed recovery codes are observable without altering the owner (aka me). Someone could photocopy all my recovery codes and I wouldn't know I've lost control of them.
As for devices, I use Yubikeys for my high-value accounts and managing them is a huge pain in the ass. I have 5 sitting beside me. One is old, two are v4, two are v5. I didn't keep a list of all the accounts I used them for from day 1, so now I have to keep all of them. Forever. Just in case.
The only way Passkeys will solve those problems is by taking complete control of authentication and treating it like a managed service. You'll be giving up control of your ability to prove your identity and, eventually, you're going to be paying a subscription fee for it.
In my opinion it's almost a guarantee that Passkeys are going to be used as leverage against users, not to benefit them. The sad thing is that once 99% of oblivious users are fooled, the rest of us are going to get the choice of using them or being shut out of everything.
This is so incredibly wrong that it makes me think you've never actually experienced signing in with a passkey.
Passkeys would eliminate all the text message codes, email codes, and passwords. The flow is literally just: Face ID or Touch ID (or equivalent on Android/Windows), and you're done. It's both a faster/easier user experience than what you're describing and it's way more secure than any of the things you described, because the resulting credential is domain-bound and therefore can't be phished.
You have lost 99.99% of the population.
Personally I like the benefits passkeys offer but some work still needs to be done around management of enrolled devices
If a user's device is compromised, an attacker can also install a keylogger and steal all their passwords, or better yet steal all their cookies/sessions.
Once a device is compromised, it doesn't really matter what type of credential you're using to authenticate/login with.
But also, if device compromise is what it takes to steal a user's credential, then that would be amazing becuse it would mean that the goal posts have been moved dramatically in terms of attacker effort. Today, attackers only have to focus on either hacking/attacking 1 service or spin up a single phishing page, and they can mount attacks targeting hundreds of thousands of users with minimal effort.
If passkeys mean that all of a sudden the attackers need to try to compromise hundreds of thousands of unique endpoints/devices, then the amount of resources and effort they need to expend to compromise the same number of users will be raised astronomically. That's a win.
Maybe more succinctly put, how a credential is initially enrolled, managed and finally removed is an implementation detail which leaves room for funky implementations like the above.
I do agree that it is an improvement over passwords though. Furthermore I guess the same applies to password based logins where everybody just kind of wings it anyway.
A few years ago when SMS tokens and Authenticator apps where less common, I was able to do work without having my phone on the same room as my computer. Now I need to have it on my desk most of the time for logging in.
For TOTP yes, but AFAIK not for the push-based proprietary authentication systems used by Microsoft/Duo/etc.
That's incorrect. I use passkeys to login automagically with many services, but nothing precludes me from logging in with my (20 character) passwords.
> If you can't authenticate via a primary device that contains your private key, you're f-ed.
That's also incorrect, for multiple reasons — accounts support multiple passkeys, those passkeys are securely sync'd across multiple devices, recovery and backup mechanisms exist, etc.
That is not the world which passkey advocates envision. In the case of those services you mention, passkeys are nothing but convenience; they provide no extra security. In the world passkey advocates envision, passkeys improve security, meaning the removal of password authentication options.
I've already been temporarily locked out by one such service, because a Firefox update made the passkeys I store in Bitwarden inaccessible (Firefox would pop up a macOS Touch ID modal rather than the Bitwarden passkey). That is the world which passkey advocates want, because it "improves security".
Okay, you don't have to take the hyperbole so far it's obviously wrong.
They don't want your login to break, and a password vault could also break if you only had a password.
And a world where people only use passwords has the same problem if you can't log in with your password.
Moving from one single point of failure to another isn't great, but it's not a downgrade.
(And just like it's possible to back up a password, it's possible to back up a passkey. And I know passwords can be memorized, but in practice it's bad passwords that get memorized.)
If you specifically want a file you can control you need to use other passkey software, like bitwarden. Which you already mentioned? Huh.
It's a really ineffective gotcha. And extra transparent because you talked about bitwarden first.
I'm not super worried.
Just enroll a second device like a hardware token. Then plug your hardware token into your friend's computer and you can log in to sites on your friend's PC without having to copy over and unlock your entire password safe.
Can you point me to a citation or two where passkeys advocates claim that passwords must go away and/or account recovery mechanisms must be abolished?
• Passkeys stop phishing. Using your passkey instead of a password (when both are available) ensures you're actually signing in to the site/service you expect.
• Passkeys have zero value when leaked. Users' private keys remains secret and safe even when public keys are stolen and distributed.
That said, passwords aren't going extinct anytime soon. It will likely become more popular to require 2FA for password users in the meantime, as it should.
A lot of folks/services/engineers mistakenly think that layering 2FA on top of passwords will help defend against phishing attacks.
But attackers have been phishing 2FA codes since at least 2012 and it's gone from an advanced attack to bog-standard. The only way to defend against phishing attacks in 2024 is to use phishing-resistant credentials like passkeys.
They do provide extra security, in that they ensure that you're on the correct domain instead of a phishing site.
Additionally, “the kind of person who's prone to non-targeted phishing attacks” is actually everyone — including infosec professionals spending lots of time on phishing campaigns for red team engagements. You just need to be lucky enough to reach them at the right (emotional, stressful, …) moment. Getting grammar and spelling correct and even potentially even slightly customising each email is made much easier by AI. Knowledgeable users might, however, stop once their passkey doesn’t work and try to understand why.
You can use passkeys across devices. I've logged into sites for people using passkeys on other devices several times. I just tap or plug in my device to theirs when it asks for the passkey and it logs in.
If you need to do this, it works the same for a passkey: if it’s a very close friend, you can share the passkey with them. If not, you can use the same login you’re now with the same MFA. Passkeys don’t need 100% adoption to be effective: the big win is blocking phishing attacks and that works as long as you’re not using passwords by default.
The problem with that is you have no way to be sure that the knowledge in your head won't somehow make its way into someone else's head. There's a reason that phishing is a thing.
This is a solved problem.
a) you can make a phone call b) you can print important travel documents ahead of time c) you can bring a backup device on your travels. I leave a Yubikey with my house keys in the hotel or sleeping accommodations and carry my phone
The Yubikey is greatly held back from wider adoption because of its stupid name.
While I remain on the fence about passkeys, I often see this argument from advocates when things go wrong along the lines of: "why didn't you securely store your backups and keep them with you at all times"
Firstly, it's annoying when a user is already in that situation, it does not help them solve the problem right now.
Secondly, it clearly faces a scalability issue, a significant proportion of passkey users right now tend to be well informed on the authentication model and threats, but when it scales to billions of users many of them will not be well informed and will not think about how to be prepared for when things go wrong, potentially locking them out of everything they would need to fix the situation.
While I appreciate the advantage this model gives, I struggle to imagine it will work well on the unsuspecting public.
Right, that's because there's a 0% chance we end up in a world where everyone who uses the internet reliably carries a Yubikey or similar backup on their person. It's wild to me how many people here are seriously proposing this as a solution. That might work fine for a typical HN poster, but expecting it to scale to the general public is some insane tech bubble myopia.
In reality companies will either provide enough workarounds to negate any security benefits or a whole bunch of people are going to lose access to accounts they own. If passkeys ever get widespread I'm guessing we'll see more of the former option, leading to a lot of unnecessary confusion and very little practical benefit.
You claimed that but didn‘t support it. They may be a bad idea (and I disgree), but how are they „security theater“, which means they are insecure?
Downthread, you claim that Passkeys (if stored in a password manager) are no more secure than a random password stored in that password manager. That seems obviously to be false; Passkeys are phishing-resistant, and stored passwords are not. So that might be where your misconception comes from.
Statistics are hard. People have a bad habit of seeing 'not 100% fullproof' and thinking that said something is therefore worthless. Same senseless argument people made in the 80s against wearing seatbelts, and 4 years ago thinking it was a legitimate argument against wearing masks in the middle of a pandemic.
passkeys imho are being pushed because:
1) a lot of people will not use a (good) password manager
2) it allows more lock-in for the providers (ios/android/1password/etc.)
They don't
> have less lock-in
I have physical security tokens from multiple vendors which support passkeys. I have Windows machines with passkeys. I have Android devices with passkeys. Tell me again how it is a vendor lock-in? I'm not seeing it.
(You should use a Google account as your primary online identity, unless you have religious reasons not to. Back up your authenticators, set up back up accounts, all that stuff; Google doesn't want you locked out any more than you do, because that requires them to attempt customer service, so they have a bunch of tools here.)
People that by into systems they don't control are shooting themselves in the foot because, when push comes to shove, a for-profit company will always chose profit over individually choice. It's short sighted to think otherwise.
Either way: Passkeys themselves don't require you to use Google, or any particular big tech firm. It's an open protocol.
https://news.ycombinator.com/item?id=32538805
This was more than two years ago. Despite the title, many parents are victims to this. To this very day, Google continues to defame them and deny access to their accounts. Long after the police cleared these victims' names. Long after the NYT confronted Google about this.
So is this what "normies" should be subject to? A digital totalitarian hellscape in which a trillion dollar advertising giant rummages through people's digital lives, randomly takes away their entire digital identity every time their flawed cyber-oracle tells them to, and uses their vast corporate resources to harass and defame?
That's not a world I want to live in. I don't want anyone to be subject to that kind of tyranny. It's not about any "religious belief," but rather basic human decency.
Your whole argument is a misunderstanding of how they work.
> Yeah that's great, I don't subscribe to that particular religion but respect your beliefs. I think most people are best served having their primary online identity be a Google account, for multiple reasons. I'm aware that a vocal contingent of technologists on HN find that take appalling, but I assure you, my take is a normie take, and also the modal take among security people.
Also, Richard Stallman? Where did that come from? This has nothing to do with free software at all. I'm also capable of drawing my own conclusions without someone else whispering in my ear, if that's what you're suggesting.
It's not honest discussion.
I don't have any control how any site I didn't build actually handles my password.
And the real independent implementations like bitwarden are often blocked by sites like PayPal does.
Often repeated. Doesn't make it true. As mentioned, I've got passkeys for services registered on multiple brands of physical authenticators and several platforms.
Other implementations are often blocked, eg on paypal I've never been able to do it and they also only allow one.
The big tech ones don't have these issues but I won't use them because I want to keep control.
About the only site I've come across that still only limits a single authenticator is the only one you've already mentioned. If I pointed out a site that only allowed five character upper case passwords with no lockout policy and really fast responses is that also proof passwords are completely untenable? Or just one actor with poor policy decisions And in the end one can just choose to not use passkeys with sites like PayPal. But the extreme majority I've used allowed multiple, as that's what the specifications recommended.
In the end you can use passkeys without involving Google or Microsoft or Apple at all. Any argument that passkeys lock you into their platforms isn't based in reality and are repeating untruths. You don't need to use them to use passkeys.
https://aws.amazon.com/blogs/security/you-can-now-assign-mul...
It's entirely possible that many sites shared this flaw.
Adoption is really slow. But yeah ok, if multiple are allowed then yes it's no longer a problem. I'm sure I read of more sites that had this problem but it is indeed possible they're fixed now.
By far the most common phish is "click this link or your account will be shut down" which brings you to a fake Microsoft/Google sign-in page, where they say "please enter your credentials" (or some variant of this). This flavor of phishing is eliminated by passkeys.
Phishing schemes will try to adapt, and some may still be successful. That is why it is not called "phishing-proof".
Ultimately the point of phishing is to attack the user instead of the technology. If the user has any control over access to their account, phishing is largely unaffected.
I can give a better answer than the sibling:
The passkey is domain bound, so the UI won't show up on the phishing site before the passthrough can even happen.
Password managers are also domain-bound though.
are also --> can be
Often they allow picking an entry for arbitrary domain names, made necessary by firms (such as Microsoft) randomizing their login domains to look like phishing domains.*
* Not what they are doing, but to the casual user, logging into xbox.com, office.com, or even microsoft.com through something like microsoftonline.com may as well be phishing.
This would require compromising the website as a whole
... and also eliminated by password managers that use autofill based on the domain name.
The important point here is that there is no way for you to have your browser sign an arbitrary (e.g. an attacker's) challenge, since you can't input the challenge at all.
This makes WebAuthN strictly better than static passwords, TOTPs (which are "unidirectional" in nature), and even "enter code 123456 into your authentication device and provide the code it displays"-like flows (which is a bidirectional challenge-response, but a MITMable one).
But also, in the end the attacker site isn't really getting anything that would let them then turn around and authorize as you.
Think of it like SSH keys. A public key and a private key. The site holds the public key, you have the private key. When you create a new passkey with the new site, they're holding your public key. They can't go turn around and start logging into to other places with your public key, they can't sign the challenges. So if you make a passkey for bank.com and an attacker at baank.com had you enroll a key there, they can't take the public key at baank.com and use it anywhere to act as you. They only have a public key, and one tied to baank.com at that.
In the end you never actually transmit your actual credential even in the original setup. You're just signing things, the private key stays on your device. And its a different key for every service.
In any case, if you have a KBA recovery mechanism, then anyone who would go dig through their saved passwords to put into a phishing site will also just enter the recovery info into a phishing site and enroll an attacker's passkey.
In Sweden no bank has used passwords online.. ever I think? It has always been 2-factor of some kind.
For me it was always some kind of PIN - and then they built their own proprietary second factors which is also a bit insane imo
That's why they are so much more secure than passwords and even TOTP or "click approve to authenticate" flows!
You'd really have to be a state actor to be able to generate a phishing site on the original url with a valid certificate as well.
Fingerprints can be lifted from photos where your hand is in frame. And no, you can't change fingerprints after they are compromised.
Or used with your own fingers while you have been drugged or you passed out being drunk.
Reducing your attack surface to the people who can/are willing to gain physical access to your device to use a passkey is orders of magnitude smaller than a password that can be taken and used from anywhere in the world, without having to get up from their computer.
If someone really wanted to gain access to something of yours, they could take you and your family hostage and force you, but that is an incredibly small attack surface. "What we have accomplished" is shrinking the attack surface, not perfect security.
Angela Merkel and Ursula von der Leyen are examples of this, fingerprints and iris scans lifted from mere photos.
In some countries even it is mandatory to store the fingerprints and photo from citizens, or at airports, what makes biometrics almost public.
Besides having all the logins under a single pin on a device that can be lost or stolen sounds just as bad, soon the people will be aimed to store them online to avoid it (trick-or-treat).
In any case, nobody is stopping you from using a password-secured implementation! I do that myself on some of my devices.
What’s the best resource in your opinion for learning enough about passkeys for a lay person to make informed decisions on them?
https://securitycryptographywhatever.com/2022/08/11/passkeys...
(I'm not being totally serious).
If you can explain how, in a phishing resistant way, passkeys can grant access to a user’s account in the absence of any devices they own, I’d like to hear it.
You can never make this mistake with a passkey or FIDO authenticator.
If you mean the password manager password, then it is entered in a different place and really hard to confuse it with a website. Also, 1Password requires extra info to login account and that is only used, usually copying from another device, when setting up device.
Oh no, you have its PIN! Can you now log in to $service as me?
Not without that hardware module.
My password for $service is hunter42.
Now you can log in as me.
See the difference?
Is it fine if a waive my hands around and say "complexity"?
Normal users aren't going to keep a backup device, let alone keep track of which accounts are associated with which devices they own. Normal users need something in a portable format that can be backed up. Anything that can be backed up can be stolen and anything that can be stolen shouldn't be used for single factor auth like Passkeys are promising.
Thankfully I was logged in on a PC and was able to get past it.
The main downside to passkeys currently is that I cannot be my own service provider. Having that I don't see a big downside.
Or, maybe they won't. Are Google and other free-as-in-facebook services going to suddenly open customer service departments?
I got permanently locked out of Facebook because during a phone OS update, the 2FA app somehow lost my Facebook information. I can't log in to Facebook because the 2FA app can't authorize it. I can't add my Facebook account to the 2FA app without first logging in to Facebook. I've sent my photo ID to Facebook a number of times, but it just goes into a black hole and I never get a response.
On the plus side, I have a lot more time to do meaningful things, and not scrolling my life away like a drug addict.
Specifically, recovery keys are designed to be so long and complex that no human could possibly memorize them, ensuring that they’re written down / printed instead of memorized — thus making them a “something you have” credential rather than a “something you know” credential.
Passkeys are highly secure compared to passwords. All problems I know of (and there are quite a few!) revolve around availability, not security.
All problems you do write about after this are indeed related to availability, but then you shouldn't call them "security theater".
Basically almost every single auth method is flawed by that because it gives way to social engineering attacks. Also once your email is taken over everything else is.
Passkeys are not going to happen, and its the industry's fault. Its a bad standard that solves some problems the industry itself has, by creating more problems for consumers. If you force consumers to move to only-passkeys, you're going to lose customers, and it might not even be their choice, you're just making the decision to lock people out.
Then you register multiple passkeys for the website, just like you would register several Yubikeys.
It’s a 1-click process, and no HW-token required. Most people will be fine.
Passkeys do not (and are not intended to) solve the problem of lost credentials.
So just like Yubikeys, when you lose one of those keys you'll need to go to the 100's of sites where you registered that key and change it. This is not a good plan.
this assumes majority of population has the means and discipline to purchase, register and maintain multiple pass keys and/or devices.
There's a world outside the developed countries where a typical yubikey can cost 10-20% of a family's monthly income.
A family where phones are the only tech devices in the household and the phone is typically in a 100-150 USD price range and costs about half of monthly income.
By making passkeys mandatory we are asking them to get multiple of yubikeys/phones per person in the family ?!
They cannot afford to and will not maintain multiple passkeys or backups.
Orgs will have to build a way to help them recover their accounts easily without further costs or just ignore them as "edge cases".
They replace passwords, after all.
But, its like I said: You have zero concept of the struggle that is already happening and will continue to get worse. That's what I mean when I say that the software industry has zero concept: You think you have the solutions, but you actually haven't even grasped the full scope of the problem.
passkeys are not serious until they actually address backups in a way that isn't just "we'll copy the secrets around in our cloud services just like passwords lol"
(And it's not like there's no solution here: firstly make it mandatory in the spec to allow enrolling multiple keys, then standardise a means to enroll a device from another device, automatically, across all devices that other device is enrolled in, and then also it would probably be a good idea if that also offered a way to revoke the other keys)
One example: Large organizations often spend $1m/yr on password resets alone.
I suppose corporate gets to overnight you a yubikey in 2-3 days?
It's clear that you are making assumptions without doing any research...
Yes you can. See "Recovery security" section of this article:
https://support.apple.com/en-us/102195
>No, I can't restore my iCloud keys onto my Windows laptop.
Yes you can — see this article:
https://support.apple.com/guide/icloud-windows/set-up-icloud...
1. Your windows pc doesn't have a SecureEnclave (tpm2.0 doesn't count!) so no, you can't do PassKey recovery only password recovery.
2. You can only do iCloud recovery to another Mac/iOS device. In other words, not your windows PC. Hope you have a spare Macbook hiding out.
Our industry was done writing reliable, quality software years ago, so it shouldn't come as any surprise that we want to keep going in that direction. Passwords have such an obvious, fantastic, beautiful quality in how when all else fails you can verbally say out loud "my password is X C J 5 4..." Its the ultimate form of reliability: non-digital, spoken or written language.
Passkeys throw that away. I don't care about any of the other arguments. Our industry wants to build less reliable software, so we built passkeys. I don't know why we're obsessed with building things that are less reliable instead of more reliable, but we are. Its sad, its insane, and frankly I'm getting so damn tired of trying to push for reliability every day and instead seeing Microsoft just throw weight around, get hacked, throw weight around again, get hacked again, and somehow still reap respect for their position in matters of security.
Also, there are mechanisms to use a passkey from another device (over Bluetooth I think?)
https://www.corbado.com/blog/webauthn-passkey-qr-code
(Not sure how the "cloud assisted" part of caBLE works)
iCloud Passwords don't run on an iPhone that is an electronic device that you need to carry?
Those electronic devices that you mention don't each store the keys in a proprietary format and you can't access them without the vendor's cooperation - i.e. vendor lock in?
Passkey portability is being worked on. Here is the draft of the open standard:
https://github.com/fido-alliance/credential-exchange-feedbac...
News article: https://www.theverge.com/2024/10/15/24270875/password-manage...
And, also, it barely works, if the wind is blowing in the right direction; was clearly built by a long forgotten team to check a box.
They've also released a Chrome extension, but no Firefox extension (actually, they did release a Firefox extension, but it only works on MacOS). Again, you have to know to install this.
The Windows Hello bluetooth system for passkeys has never worked for anyone I've seen try to use it. The display & scanning of the QR code works better. But, that only works if the passkey was generated on iOS and is being used on Windows; if the passkey was generated on Windows and needs to be used on iOS, you're probably screwed (I've never seen Windows try to pop open its webcam, if the device even has a webcam, to scan a QR code on another device.)
The problem is that the UX for this is extra super confusing, and people will end up with passkeys that aren't backed up anywhere and get locked out of their accounts.
Scanning a QR code: https://support.apple.com/en-us/102680
The time investment could even be worth it, since "Signing in with a passkey is three times faster than using a traditional password and eight times faster than a password and traditional MFA", according to the article.
-> I have that turned off
Scanning a QR code:
-> My back-camera lens is shattered. Using the front is dodgy at best. I don't feel like I need fork out for an to upgrade as I use a digital camera if I want to take pictures.
What about those don't use smart phones?
Have a broken phone camera? Cannot scan qr codes.
Lost the phone? Cannot log into vital modern day accounts like email.
Your house burned down, and the passkey device with it? Say goodbye to literally everything.
Homeless (temporary or otherwise) persons, random local government sweep just trashes everything you own. Bye bye to the passkey again.
If my phone explodes like a Samsung surprise, and my laptop turns into a spicy pillow;
I can in the worst case scenario, still log in via the local library PC.
I could borrow a device from a friend, or buy a second hand Thinkpad and use that.
That is to my knowledge, not possible with a passkey device.
If you’re remembering all your passwords there’s a good chance they’re terrible, you frequently re-use them or both. That really helps attackers e.g. when they use leaked passwords to run credential stuffing attacks on your employer.
You just wrote two comments bashing a technology you admit you didn’t properly educate yourself about.
For android, the passkey is clone-able iirc, but again, it's an expensive smart device.
So now I am expected to have at a minimum, two use-able smart phones, per family member. Iphone? Frankly, fuck that shit. Too expensive.
Android, I can manage it. But doing that for all family members is not financially viable.
Also I do use a password manager and an encrypted text file. (Not smart, I know. The file is basically a backup)
But I really cannot expect people like my mother to understand how to set up a passkey. Much less, how to setup multiple for the off chance one is lost. Add onto the fact that Yubikey does not support twins, and many services do not support multiple passkeys.
In terms of computer literacy, using my mother as a baseline (Age:Mid50s) the current passkey system is non-viable.
So just make multiple passkeys on the different platforms/devices.
> So now I am expected to have at a minimum, two use-able smart phones
No, you can have passkeys on laptops and desktops. It doesn't need to be a phone. Hardware tokens can be had for like $20.
Something I know is the only authentication method that can't be physically destroyed. When your customers are the masses every failure mode that can happen will happen, usually at the most inconvenient time.
What sucks about passkeys in abstract is that you want at least two failure modes that are uncorrelated— you're unlikely to forget your password and have your house burn down at the same time. Passkeys consolidate everything into to physical possessions which can be and are destroyed all at once.
In your sleep, your house has burned down. You have zero devices, and your backup keys are stuck in a building you do not have access to for another several hours. You have made it out of your home with: Your wallet, containing $20 cash, a handful of slightly melty credit cards, an ID that is almost readable, and your keys. The credit cards are fucked and will need to be replaced. Your ID is mostly readable.
This is the situation that I pose for most people to try and get undone from. I then amp it up another notch:
you have no job and are unemployed currently. You cannot make use of any insurance system as you have been deemed "impossible to insure" due to your status. You currently live in a cardboard box behind a restaurant in downtown.
And before you go "why would a homeless person need email", it's required for lots of services, as is a phone number that can at least have voicemail at it (this is a service that Futel^1 provides in some places). You can't assume that physical artifacts will continue being in the possession of a dishomed person. One of the common reasons for losing all your personal effects in this situation is the state literally taking everything down to your clothes away^2.
^1 https://futel.net/ ^2 https://www.realchangenews.org/news/2024/06/05/sweeps-triple...
I have tested this process with my partner. the only thing that I cannot replace is the TOTP token to add new devices (however this is bypassed when recovering from paper). I have legitimately considered etching the recovery data into a small glass (borosilicate) dish using selective laser etching.
Thus, "password recovery material, TOTP QR code, and an SD card with essential documentation" can be passed to next of kin easily.
Ah, so no worries then. I've still got a passkey for all the services I really care about.
If I'm not supposed to have cloud-synced credentials like so many here dislike with those implementations of passkeys, chances are the copies of my password safes and my SSH keys to the VPS are all cooked as well.
You're traveling in a foreign country without your laptop when your wallet and phone are stolen. You can probably get to a public computer, but how do you get into your email?
This situation strikes me as much more likely than getting hacked. Hence I will never use passkeys unless forced, and if forced I will do everything in my power to switch to another service. Same for forced 2FA as far as I'm concerned.
Just install a webcam on it and scan the qr code iOS displays.
/s
I don't know why this is such a common misconception about passkeys.
Account recovery flows are generally entirely unaffected by moving from passwords to passkeys. If a user forgets their password or passkey, they generally go through an email recovery flow and generate a new one.
...this is sort of a rhetorical question, but also maybe not? Slack does it, as do some other services I can't think of off the top of my head. I feel like a lot of normal people who don't use password managers basically always use email resets when logging in from a new computer.
The thing is, email was never designed for this purpose. Password managers are. I stay logged into my email client on my computer, but I have to retype my password to open my Bitwarden vault.
Really, not being snarky here. If I asked my dad to install a browser extension he would drive his laptop to my house and ask me to install it for him. If I wasn't available - then it just wouldn't happen.
My mom can't see, so maybe she's okay?
The title is inaccurate. Microsoft doesn't actually "confirm password deletion for 1B users". They confirm it for millions. They have a concept of a plan for getting >billion people on passkeys as an auth factor, and will be able to get some of them to go passkey-only.
Really? I somehow doubt that.
> If they don’t enroll when you first ask, don’t assume their decision is permanent
No is supposed to mean no
"If it works for Google, it shall also work for us". Regards, Microsoft /s
I think it's a phrase that is often applied in sexual situations, but not intended to be exclusive to them.
It's predatory behavior pure and simple. Call it what it is and stop apologizing for abusers.
One counterargument is that nobody forces you to use their services.
I think the root problem is that nobody produces personal hardware over which the average person could conveivably assume full control. I'm not even sure it's possible, given how advanced the computer technology is.
Not specifically Microsoft, but more and more government services are accessible only through apps that are only offered through Apple's App Store or Google's Play Store. (Either directly, or because a generically eID app is used.) So in this case, I am absolutely forced to agree to either Apple's or Google's ToS to interact with my government.
My job forces me to use Google and Microsoft because that's what the entire industry is built on. Should I uproot my entire family's lives so I can move across state to find a new job? Is that a reasonable compromise to make so I don't have to complain about windows?
Microsoft only started supporting webauthn in the last couple years so it's surprising they're actually rolling out passkeys. Maybe they finally gave up on smart cards
I'm a developer, yet for some odd reason I'm having a hard time understanding passkeys. Are they synced between devices? Do I need to set up a passkey per device? What happens if I have a single passkey on my phone and it gets lost? Do I lose access to that service?
So many questions that need a clear and concise answer.
So, in the end, the old Microsoft mantra: "Your security is very important for us". Besides Microsoft, NSA, CIA, the five eyes and friends, no one has access to your passkey, this means is secure.
For example you can have a passkey where the private key is on a security token protected with a PIN or biometry.
You can have a private key live in a secure element on an endpoint too.
You could make a browser plugin that requires no auth whatsoever if you wished.
In your analogy terms it is akin to an SSH key stored on a hardware device like a Yubikey that you have to "push the button" to unlock. It is more secure than just an SSH key without a password, but depending on a lot of factors, including your personal threat model, may be more or less secure than an SSH key with a strong password. (You'd assume the Yubikey's unexportable hardware key is a lot stronger to break than any password, so it is potentially far more secure from brute force attacks, especially remote attacks with no physical access to try to export an unexportable key. It's reliant on physical device security so it is far more weak to "in the room"/"over the shoulder" attacks. At the end of the day most people's threat model is somewhere in the middle of the two extremes.)
Of course if you decide to use a password manager like 1Password or BitWarden those passkeys are going to be locked behind your "master vault password" in a similar way to your other passwords.
And what if that cloud account decides to cut off my access?
It's an alternative place to store webauthn credentials, if you're worried about being locked out.
> What does enrolling multiple credentials even mean?
You register multiple passskeys for your account on a service. So if you lose access to one (because you yoinked your phone into orbit), you can use the other one.
It's as complicated as you want to make it.
If the user is, what's the point of having passkeys? One using a password manager has (strong) passwords generated for them...
First time I'm hearing about removing passwords and it sounds like they're implementing an even worse idea.
I store all my passwords in Bitwarden. One reason I use Bitwarden (as opposed to e.g. Keypass) is because it has cloud syncing. All of my passwords are synced between all of my devices.
Critically, however, if Bitwarden's server was to disappear tomorrow, it wouldn't destroy my life. My passwords would still be stored locally, so I could open Bitwarden and export them, then import them into another service.
Passkey by design have no solution this! That means I can't trust them! I need to be able to export all of my credentials to some type of local file, which can be transferred to a new machine or service without the cloud, as a failsafe. I don't care if this is less secure, because my Bitwarden setup is already very secure, and I am much more scared of being locked out of my own accounts than of someone else getting in.
I think I understand it's a bit like a "my public SSH key + website's public SSH key merged together", so that each website can verify the passkey we created together using their private key. The basic mechanism is more or less straightforward.
What I do not understand well is the "how to store and manage 100s of passkeys", and how to migrate my family (including my parents in their 80s, who are far away and I am the main tech guy when the closer "basic tech literate" family members who live closer can't figure things out) to them. We use Linux and Windows boxes at home, and Android phones (for now).
I can easily log into any accounts from any of these, even from my work laptop if needed, some requiring SMS 2FA (let's leave that for another discussion). If I created a passkey on a linux desktop and stored it in a yubikey, can I re-use it on someone else's windows laptop? Would I need the bluetooth version of the Yubi to sync with my phone? Or would I have to create a unique passkey from each device to each website, using my existing password?
Basically: I don't have "one phone" and "one computer", both running the same OS. What are some usage models, including some that don't require yubikeys, because no way could I get my parents in their 80s to understand those.
One issue I found recently was changing my GPU clearly changed the definition of my "device" in Windows and invalidated all my passkeys. But the passkeys are still there, the sites I access still try to request them, but Windows can't provide them, so it basically just errors out. Not found out how to clear this all out yet.
I can't tell you how many times I've ask my father "what's your google password" and he says "I don't have a google password". I like the idea of eliminating passwords, but inevitably his phone is going to break or his computer is going to crash and he needs a way to recover.
I hate password books. I don’t have a better solution though.
For now, I teach them to use chrome password manager for now and log in their chrome account when they need help. It sucks too. But at least I don’t get angry with their notes.
But it's a small step.
This has several problems though, one of them being that they assume you have at least two mobile devices (let's say a phone and a tablet) and another that they assume the OS you run on both your devices is the same. They do not support migrating you passwords between Android and iOS for example!
1Password and the like encrypt data before it leaves your computer, stores it for however long you want, and then decrypts it when it the data is copied to your computer.
This isn't true of webauthn/passkeys. The number of use cases where you need to "make a copy of " or "backup" your passkeys is zero. I get that some providers let you do this for some level of convenience, but you can opt out of this and just enrol multiple distinct credentials with each service.
> The number of use cases where you need to "make a copy of " or "backup" your passkeys is zero.
That just tells me you haven’t thought about the problem at all.
Then, it's a case of installing BitWarden on any devices you want to use to login, protected with a strong password and 2FA.
If the password manager is unlocked, I get logged in automatically anyways.
2. Passkeys can't be to short, in contrast to passwords
Passkeys essentially remove almost all risks for websites and moves them to the user (lost passkey, attacks on their password managers). It is not perfect, but it removes a lot of problems that we have right now (like more than a billion leaked passwords in the wild)
And it does provide some benefits: phishing protection (no shared secret that can be intercepted or given to the wrong party) and the service does not need to store as much sensitive information (don't need password hashes that could be leaked and cracked, just a public key).
The main difference I see with passkeys from a usability standpoint is that Firefox doesn't have built-in support for a software implementation, making them literally unusable for me.
For example 1Password can be used for passkeys in Firefox.
No ability to export your credentials.*
Device attestation to allow blocking "undesirable" devices from authenticating and lock in purposes.
*keypass was working on an export feature and there were already threats to use the attestation club to ban them from the landscape for not falling in line
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
That attack on KeepassXC is despicable.
They can: 1. Impersonate you, gaining access to anything your keys unlock 1.a. Impersonate you, claiming to be you in a violation of “key use enables non-repudiation” 2. Deny you the ability to use your keys 2.a. Change any of your keys, locking you out of things 3. Deny you the ability to transfer your keys to anyone they “don’t like” 3. Provide your keys to anyone else, e.g. “with a court order” 3.a. Anyone “benefitting” under (3) can then do (1(a)) …and surely more Bad Things.
Every single time “passkeys” seems to like “okay, maybe”… some fucktards pull another one of these.
Then I go, “okay, ssh keys, PIV, or whatever else is Just Fine, and these people who are either state agents, idiots, or power hungry idiots working to advance total control over humans with lack of freedom and no way back can go die, or as an alternative be sentenced to serious computer-things-reeducation”. …and I kinda mean it. There are certain things you just don’t come back from, as a society, etc. and I just won’t support it. You only get one chance not to.
timcappalli from FIDO Alliance mentioned in that above thread that plain text exports shouldn't be allowed, and that password managers/providers should be blocked if they implement plain text export.
Since that thread, there's a new spec that allows users to securely migrate passkeys from one provider to another, but no way to export to plain text (for debug purposes, or if there's a bug in the export/import and you need to troubleshoot, etc).
For me, threatening to block providers for implementing a feature that I desire is a great way for me to lose all interest in passkeys completely. I don't trust FIDO Alliance to make the right call nor do I trust big tech companies to produce bug-free software.
A passkey doesn't transmit your actual, full, repeatable credential over the wire. It's a challenge-response protocol, so only that one authenticated session would be intercepted. Kill all questionable sessions and you're good, they're not reusing it.
are impossible to enforce. If you present users with password field, a sizable percentage of them will just manually type in the same weak, compromised password that they've used on every other site they've ever created an account on in their life. Passkeys are much harder to misuse. That's where 99% of their value is.
Yes there are also other advantages, like the fact that passkeys use public key cryptography, but those are tiny compared to the human factors improvements.
Just like passwords. What is the difference ?
> Passkeys can't be to short, in contrast to passwords
So a "long password" is a "passkey" ?
> Just like passwords. What is the difference ?
>> Passkeys can't be to short, in contrast to passwords
> So a "long password" is a "passkey" ?
Of course not.
Passkeys are effectively just key pairs defined by a FIDO standard. It’s much more productive to think of passkeys as mutual certificate authentication designed for use by the masses.
If you’ve ever used a Yubikey for primary authentication, you’ve already used a passkey.
That’s why the mainstream implementations are synced. Or why you have an extra Yubikey.
Not really relevant for password manager users.
> 2. Passkeys can't be to short, in contrast to passwords
Not really relevant for password manager users.
Echoed in his ears.
From that perspective it just makes the UX slightly smoother and makes it impossible for the site to screw up and leak your plaintext creds. Other than that yeah there's not a big difference compared to using an autofilled, unique, randomly generated password. Which is good, because eventually sites are going to start phasing out that latter option for the exact reasons I outlined in my previous comment.
The thing about good design is that it makes it impossible to "hold it wrong".
That's a big "if".
With a password manager storing passkeys, your private passkey is not transmitted as part of the website request. It can't be intercepted or accidentally/negligently stored in plaintext in a database or server logs.
You still have to trust the secure syncing of your passkeys, just like you do with passwords, but there are still fewer threat vectors than with passwords.
Yes, the problem exists in multiple "places" and all schemes are different balances.
There are many different kinds of "security". Each suits different needs, or addresses different threats. Not all are based upon "identity" as a central concept. Not all are based on secrets. For those that are, changing your secret from something you know to something you own merely shifts a locus of trust and mode of use.
Passkeys (and ssh keys with passphrase) are a good solution in some cases, where you use multiple end points which may be compromised. But they are no better (and less flexible) than challenge response and one time passwords and other elaborate password schemes that are a superior access control secret in other situations [0].
The problem is that most people don't understand the quite subtle interplay of factors. This is one area of cybersecurity education I'm spending more time on because regulations are going to place more emphasis on making good security choices (and not just accepting vendor defaults).
Microsoft unilaterally deciding it thinks it knows what is "best " for you accords with its clumsy patrician over-reach, and cover for a pitiful security record in its products.
Perhaps one of the most important meta-security factors is that you be able to select products that allow you to choose your security parameters and how they interact as your situation and access habits change. But that responsibility requires understanding.
It’s the same issue I had with getting a Yubikey.
The odds that I lose a piece of hardware that I’m carrying on me seems orders of magnitude greater than the odds of having my password cracked.
How does one recover from a lost device (other then backing up to Apple’s private cloud in which case you’re beholden to them forever to be able to access your own accounts).
And oh man tons of almost millionaires have lost their backups. Tons of people still have stolen credentials. Basically nobody can "do it correctly".
The workflow to enroll a new backup token (when the primary is lost and the backup becomes the primary) also seems like tedious and error-prone make-work.
It would great if I could load my backup token's public key into my primary token and export a copy of the primary token's secrets, encrypted with the backup token's public key. When I lose my primary token I would only need to restore my backup token and be back in business. That eliminates the make-work of enrolling on the backup token.
Of course, this scheme allows for "cloning" of a token so it'll never be allowed by the "security" nannies who know better than us.
Yes, exactly this. At one point I had a list of services that I utilize along with a list of the yubikeys I had enrolled on each. My plan was to enroll my backup key periodically (retrieving it from its safe place to do so). This ended up being a giant pita, and despite my best efforts, the list became out of date. In the end I just use Google Authenticator for everything since I can back it up.
I ended up disabling MFA in one case - with the most terrible flavour of implementing MFA - because f you!, they ask me to re-login on my stationary main home computer repeatedly for 'security reasons' (idiots) and I too many times end up the particular MFA gadget being somewhere else than at the reach of my hand, obstructing my efforts and workflow too often. Using computer systems are wasting efforts nowadays rather than helping, with the forcing through of cutting edge advanced 'solutions' without thinking about the broad picture (the curse of single-mindednes).
And then we did not even talk about my bank, completely different animal giving no shit about third party physical keys, yet another different way to get blocked if not done exactly as those particular fellas dreamed of in cheerful company meetings not caring collaborating on generic approaches.
MS is particularly bad and not to be trusted with their "insightful design" (it is told this way in the article, HAHAHA, funny guy) solutions f-ing up two things while pushing a marginal one through. With important ones the ratio is higher.
I 100% agree with you, but the counter argument I've heard is that "it's worse if someone else gets into your account than if you get locked out."
This does make sense to me in some scenarios. Like, if the author of some core Javascript package gets locked out of their Github, they can't push updates to the package; if a hacker gets into that person's Github account, they can push malicious updates to said package. Better to be locked out!
If this describes you, I think a Yubikey makes sense. Personally, I am not in this category!!!
I don't know about you, but a PIN is pretty much a password in my book.
Once I figured out that I can use a password with Windows, I stopped using my PIN. (I didn't use Windows for about a decade.) It's much easier to remember.
Even worse, on Windows, I'll only use passkeys on sites where I can use a Yubikey. If the passkey requires a PIN, I don't bother. I just can't be bothered to remember it.
Otherwise, on Mac, my passkey supports my fingerprint sensor. Much easier.
I haven't tried it but it should also work with "Windows Hello" supported face or fingerprint recognition.
The common definition of a PIN is for things like using an ATM, where the PIN is for the account, not the card itself.
I think a reasonable modern definition for a PIN is "a password that can safely be short"; more here: https://news.ycombinator.com/item?id=42446015
It can't have letters / symbols in it. If they're calling a password a PIN, that's the wrong word and will confuse the ^%$^#% out of people who expect PIN to mean numbers only.
Then your book is filled with misunderstandings of what the PIN function in Windows is actually doing.
A regular local account with a password would still work after a motherboard change.
This is assuming no bitlocker. If you have bitlocker, I don't know if bitlocker key recovery will also fix the pin (hopefully you printed the recovery key and can find it)
I'm guessing this would also mess up passkeys.
Also, as mentioned in the sibling comment, PINs are just device-local credentials. They don't necessarily have to be numeric-only and can also be very long.
You can have your computer re-challenge you for a full password on some interval. So have it force you to use your password on your first login of the day, then you can use your PIN to hop back in during the day and then have the PIN option time out after so many hours. Same with any of the Hello credential options.
After too many failures with a PIN, it will disallow the PIN authentication entirely. So, its length isn't really a problem, it'll start to disallow PIN attempts after only a few wrong guesses. Once again, also configurable. Meanwhile, it'll always still allow a password although it'll start trying to slow you down on password attempts.
PINs are supposed to be stored on the TPM or similar secure platform module, they're not stored on the local computer storage. So, there's not some easily accessible file to do brute-forcing outside of the computer.
While consumer Windows isn't really Windows Hello for Business, the same basic ideas of PIN security are the same. Here's the FAQs on that which also go into some depth of why PINs over passwords:
https://learn.microsoft.com/en-us/windows/security/identity-...
I guess the idea is that it is easier to use. I just setup a PIN for Windows Hello. The PIN requirements were more strict than the password requirements, so that is hardly more convenient. Maybe this is punishment for not wanting to use a fingerprint or face scan which remain optional. For now anyway, it feels like all I did was get my goose half cooked and end up with two passwords whereas before I had one. Even if I did give my face scan or whatever, I still need to use my password to login to things so my original point about two attack vectors seems to still stand.
No, because the PIN is tied to the device and becomes invalid much more quickly. A Windows password is potentially used in far more places and potentially across many devices.
> I guess the idea is that it is easier to use
For many, it really is. On some of my devices which lack biometrics my pin is just a few numeric digits easily input with a small numberpad. The PIN is backed by the TPM which wipes it after too many failures. This is far faster and easier to type in than my full Microsoft account password which uses most of the normal complexity concepts such as length, mixed-case, letters+numbers+symbols, etc. Far easier to just type 4-6 digits (or however long you want it to be) instead of dozens of mixed-case alphanumerics and symbols.
For instance, I recently got a gaming handheld which runs Windows. I want to use my Microsoft account, but as mentioned its a long and complex password. It seems this device doesn't have any biometrics, so its either type in my very long password every time the screen locks on a software touch keyboard or just type in a short PIN backed by the TPM. Which seems like the better process?
> it feels like
You may feel that way, but a Windows Hello PIN is not a password. They're different things in many ways. I could continue throwing more documentation at you, but somehow I feel like continued facts aren't going to change your feelings about this.
I'm talking about the password classic here. It didn't go away. It remains one of the now two methods for signing in. Now there is also a second one while the original still exists, is it more secure? I don't see how two doors is stronger than one.
(I'm assuming this is a personal PC and not a corporate device, in which case this model is the same but the strong password is also used for many internal single sign on resources).
Usually you pair this with a Windows Hello camera for face sign-in so you skip the logon hassle when in front of your PC.
There are settings in the group policy editor to change the Windows Hello PIN settings, but it could depend on your Windows edition and whether you have admin rights.
For example, if I use gpedit.msc > Computer Configuration > Administrative Templates > PIN Complexity, I see:
Require digits, Require lowercase letters, Max PIN length, Min PIN length, etc
That still requires making up and memorizing a PIN.
Or even better yet use biometrics instead of the PIN.
> Then your book is filled with misunderstandings of what the PIN function in Windows is actually doing.
The "PIN function in Windows" doesn't define what a PIN is. If Microsoft really meant the "PIN function in Windows" specifically, they should have said so in their blog post. Otherwise, in this context, PIN means this: https://en.wikipedia.org/wiki/Personal_identification_number.
> Once I figured out that I can use ___a password with Windows___, I stopped using __my PIN__.
Context clues. Read the whole comment. Pretty much immediately after they start talking about PINs and how they're pretty much just passwords, they go to talk about using passwords instead of PINs in Windows. Each sentence isn't its own entirely separate universe devoid of any context of the previous words and sentences.
What PIN do you think they stopped using immediately after referencing their Windows password? Think they stopped using their bank card PIN because they figured out how to go back to full Windows passwords?
So no, they're not speaking generally about all PINs, they're specifically referencing it in the context of Windows accounts.
https://www.grammarly.com/blog/writing-techniques/context-cl...
When you set up a PIN in Windows it can either be numeric or a full text password, it's your choice.
Your PIN for your bank card doesn't give anybody access to your bankaccount. that would be terrible. your pin acts as a secondary level of authentication to secure the bank card that is your primary authenticator. just like a PIN in windows hello acts to secure your primary auth method - the computer that's already signed in to your microsoft account.
if there is anywhere that you can use a PIN without additional authentication it's not a PIN, it's just shitty insecure password.
My definition of a PIN is a password that can safely be short (i.e. low entropy), which means you can only use it against a system capable of enforcing a rate limit.
That can be local trusted hardware (such as a secure enclave, a Yubikey etc.) or a remote backend via something like SRP.
> If the passkey requires a PIN, I don't bother. I just can't be bothered to remember it.
Then use your password! A PIN can, but does not have to, be short :) FIDO-compliant authenticators have to accept up to 255 UTF-8 characters; you're by no means limited to a numeric 4-digit code.
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
Also discussed on HN at the time: https://news.ycombinator.com/item?id=40165998
I think I'm fine with my uf2 / webauthn devices as second factor, thanks.
(Edit: to be clear, I'm not the author of said blog post)
> Users are three times more successful signing in with passkeys than with passwords (98% versus 32%).
> 99% of users who start the passkey registration flow complete it.”
I suspect this is because primarily tech oriented folks use passkeys today, and they are fairly unlikely to have trouble logging in with any method.
1. Tap the login with Face ID button
2. Tap to approve it
It’s even faster than using a password manager without MFA but safer than password+MFA, and you aren’t spending any time goofing around with some poser’s password complexity policy or rotating your password when their servers are breached.
no i don't remember this random string i typed in months ago and no i don't want to have to type in the password to unlock my password manager for the 82349th time
this whole thread is perplexing, a forum full of tech people bitching about something that's more secure and more convenient
Or if my keyring was in the other room, I'd use the passkey on my laptop or desktop.
I don't trust a cloud vendor to own my entire digital life, and I don't want to have to stand up and maintain my own super complex self-hosted passkey service. Passwords are easy, just stuff them in an encrypted text file. I have no idea how to self-manage passkeys.
Still no third parties between you and the remote server.
Like the very first sentence on the official passkeys website is, "A passkey allows a user to sign in to apps and websites with the same process that they use to unlock their device (biometrics, PIN, or pattern)." I don't use any of those methods to unlock my Linux laptop! What does unlocking my personal device have to do with logging in to websites? Is it reading my /etc/shadow? What's going on here?? Just terrible.
Oh, it's just a keypairing system. Okay. Why don't they just say that?? How you unlock the private keystore is just an implementation detail, not an inherent property of passkeys.
Thanks again for the Bitwarden link, I'm going to play around with it this weekend and see if I can figure out how it actually works without all the offputting, misleading marketing speak.
If passkeys are too complicated for me to figure out, I don't think they have any hope for the wider public.
PIN - a personal identification number (aka a password)
This is one of those times where there is usually an ulterior motive behind this decision. Most cases in the form of power and/or control.
Netflix didn’t crack down on shared passwords when they were growing rapidly but that’s not because they couldn’t.
Here's the argument. I guess it's up to you whether you think it's coherent.
1. Netflix dislikes account sharing. They'd rather have two people pay for two subscriptions. They're a business, and are in favor of higher subscription numbers. 2. Passkeys make account sharing harder. Customer behavior modeling probably suggests that some fraction of account share-ers would create new subscriptions if they switched to passkeys. 3. Of all the reasons Netflix is in favor or against passkeys, this reason is in favor of them, via 1. and 2.
If you asked most people "what password manager do you use" they would give you a blank stare; but sadly, the answer is rarely "I'm not using one" the answer is usually Apple or Chrome or whatever is built in and most convenient.
The password to decrypt your password database isn't your actual password to the logins contained within, its just a part of the process to get it.
The PIN to unlock a passkey isn't the credential itself. Its a part of the process to be able to use the credential.
Meanwhile, an account password is the credential.
If I have a key to my house attached to a chain so it can be used to open the door but not leave the property and then secure it in a lockbox. If someone steals the key to the lockbox they technically don’t have access to the house key but they can still rob my house
But in the end that PIN is still different from that Windows/Microsoft password. The PIN only works on that one device and gets totally invalidated after only a few failures. This is untrue of passwords which usually never get fully invalidated and are then used across multiple devices.
If you manage to find out my PIN to log into device A with my Microsoft account is 1234, you don't have access to my Microsoft Account in general or on device B. If you see I log in to my device A with hunter42 (my Microsoft account password), you can now log in to my Microsoft account and every other device I'm using my Microsoft account.
Is that a difference without distinction? I'd say that's quite a bit of distinction! And that's only one of the many differences!
In this scenario, even with the attempt restrictions the attacker has a couple of chances of relatively easy guesses, before falling back to the password protection. If we consider shoulder surfing, it’s a lot easier to distinguish a four or six digit PIN than a password.
I aware the PIN doesn’t give actual access to credential and so doesn’t impact online attacks. But that isn’t the only scenario.
Incidentally how much work is “in general” doing when you talk about the access Io Microsoft services granted by the PIN + TPM? It isnt zero access is it.
I mean you can't just go to microsoft.com and log in knowing only my pin on a single device. If you know my PIN for a device, but you don't have the device, you don't have access to my Microsoft account at all.
Sure. Whatever buddy. Nothing is truly secure. If they guessed my password as well along with my device I'd be in an even worse situation. At least my PIN just disappears forever after a few failed attempts and requires that physical device.
Needing a physical device which wipes itself after a few failed attempts is more secure than having a password that could be used anywhere on any device however many times they want to guess.
> without distinction only in some scenarios. Namely offline attack to a physical device.
There is a distinction in this domain though, and it's pretty massive. Offline attacks at guessing passwords, if you fail the PIN a few times (three on most of my machines) the PIN gets cleared never to be used again. Meanwhile you can keep trying the password over and over. The account password on the device isn't getting cleared. So I can make the PIN pretty simple and easy to type in while making my regular password very long and complicated. It doesn't matter if its a pain to type in, because its not like I'm typing it in every time I walk away and come back to my computer.
X and Y are both Z. The rest is implementation details. Except sometimes "implementation details" makes the two pretty radically different in usage.
A PIN grants you access to the service. A credential grants you access to the service.
Incorrect. The PIN does not grant access to the service.
If all you have is the PIN, you don't get access to the service. Therefore, its not the PIN that grants the access.
If you know my keepass database passphrase, but don't have the actual database file, do you have access to the services contained within?
And as acdha mentioned, the entire login workflow is radically different with security keys / passkeys. Its a radically different implementation of authentication with different guarantees.
Do you leave SSH open on port 22 with only password authentication? It's just the same as using SSH keys, just a difference in implementation.
That depends what the service is. If the "service" is a session on my desktop PC, then it absolutely does grant access. You'll have to take my word that if I type my PIN into it, it will start an interactive session.
My kid wants to play minecraft, but he can't because he doesn't have the PIN. If he did have the PIN, he could play minecraft.
I am willing to believe that the implementation of the PIN is totally different from passwords, but in this use case, the user experience is identical. The "attacker" does NOT need the password.
If your kid fails the PIN too many times, the PIN gets disabled. No more PIN retries until the real password gets used. If they tried the password a bunch of times, they'd get a timeout but could come back in a few minutes and try again.
Same thing with a fingerprint with a passkey to some service. The fingerprint itself isn't the login; you can't just go to any phone and press your finger and log in to the service. So the fingerprint isn't the login, its a part of the process on that particular device to unlock that particular saved credential that logs you in.
In some cases, a PIN can be used to achieve the same effect that the corresponding credential can.
I think normal people care about some of these cases sometimes.
If you login to Google.com with a password, the remote server knows your password and if you are phished the attacker can use your password to access Google.
If you login to Google.com using a passkey secured by Windows Hello, your PIN or biometric check is between you and your computer, and the passkey is used for a public key exchange with Google’s servers. They do not know your PIN and you cannot be phished. That’s a transformative change.
So it's not like this is a new thing. It's the same concept, but applied to a PC as well.
Switching to hardware backed authentication reduces risk and support. Face/touch/PIN are an additional layer to protect against hardware theft.
Congratulations. You have a passkey.
Was that easy enough?
The greater point is not the specific edge cases, it's that they haven't been worked through. Even a sophisticated user like myself doesn't want to use passkeys exclusively yet because of this very reason. I'm not confident that I won't get completely locked out when it's absolutely critical that I get in.
Same thing with logging into my mail provider which I use passkeys for.
A few accounts I did have to go find a backup passphrase for, but none of those accounts are the kind of accounts I'd normally be trying to get into while on vacation or something.
I don't travel very far or very long without a couple of different authenticators. If its farther than a bus fare and I'll be gone for a while, I'll probably have at least two, maybe three authenticators on me. For example, my phone, my laptop, and a yubikey. Its only a few dollars for the public transit around me, so if my car explodes on the other side of town with my bag containing my keys and my laptop in it and I had to jump out into the river to avoid the explosion and debris and it broke my phone I'll still be fine to get home with a few dollar bills in my pocket. Or hopefully those other physical security tokens commonly called credit cards will also still work. And there I'll probably have my desktop at home and another yubikey. But honestly that kind of thing doesn't happen to me too often so I'm not too worried.
So we just normalize having multiple devices, and suddenly my use case is the same as everyone else's.
Its not like I'm talking about everyone having a dozen $1,000 devices. Several of my authenticators were like $20-30 and have lasted over a decade even getting thrown in the washing machine and getting left in the rain and dropped in the pool. One was on my keys when I was daily driving a motorcycle in a rainy season and still works a decade later.
People don't find it weird to have two car keys and those things often cost hundreds of dollars these days to be replaced.
I also don't know whether there is even any recovery process planned or possible, I guess not? So why on earth would I pick a new system like passkeys where I can't just have Google email me a new password vs. a system where that is impossible? Effectively my email account is like a second device in the password system which is far easier to carry around than a physical device. Sure a second, different email account could get itself password guessed but the chances of that are so small, it's pointless to think about and even if it does get hacked, even then it probably wont matter because it will only get used during recovery processes for a few seconds.
It also still doesn't answer the question around how I would know whether the passkey I created on a different device will work. One time a login process on Windows told me to use a QR scanner via my phone and then I got logged in. Okay so did that create a new passkey now and where? Both devices were involved in the login process, it was unclear to me. Maybe it was also the registration process, they are so similar now that I can't remember.
I guess maybe half the problem is that the proposition seems so strange: We are being told that all of a sudden having multiple "passwords" for the same account is actually great, it's secure. In fact: Just have a new password for the same account on every device, you can just keep creating new passkeys and it's no problem at all?! Oh and btw, if you lose any one of those your entire account is utterly compromised and good luck figuring out which of those passkeys you have to invalidate now. Somehow this is okay and secure.
Tons of people walk around with lots of little hardware security modules every day. They've got a wallet full of chipped credit cards, they've got car keys with transponders, etc. What's one other piece of plastic on the keyring? What's one more card in the wallet?
> some phones don't even have usb ports
Practically no smartphone sold today has no USB ports. And besides, we're talking about activating a new phone, so chances are that new phone is going to have a working USB port.
If they don't even own a smartphone and don't want to own one, well, then sure I'd agree they maybe shouldn't use passkeys. But if they're not using a smartphone they're probably not too worried about logging into their iCloud account or Google account or whatever on their dumbphone. So I don't see the issue of their dumbphone not being able to log into the services which aren't supported on the device anyways.
I'm not necessarily arguing they're for everyone, but they do apply to most people in most developed countries. They should be an optional way to access your account.
> on vacation and your phone breaks, who really keeps a second phone around constantly
It's not a second phone, its either the yubikey on my keys probably still in a bag/safe in the room if I flew somewhere or it's in my pocket.
> someone breaks in and steals your backup phone
Yeah, I'd probably want to go about disabling it eventually. But generally, I'm not too worried in the immediate time. You need to unlock the device to get access to the passkeys. If you fail too many times, you're not getting access to the passkeys, ever.
> Effectively my email account is like a second device in the password system
So effectively all your accounts are protected by a single password that's available to have people attempt your password anywhere, anytime, pretty much however fast they want to.
> Sure a second, different email account could get itself password guessed but the chances of that are so small
As someone who's managed email for a lot of people, it's really not that small of a chance if it's just a password to an email account.
The only thing I'd potentially be really worried about is a house fire, but pretty much every important account of mine has backup passphrases in the fire-resistant safe. I do live just down the street from the fire station though, so the odds of a fire burning up all my stuff including everything in the fire resistant safe seems pretty low. Probably lower than your everything in your life email protected by just a password getting hacked.
Wow ... how not to convince me that passwords are a problem.
And not a lot of systems have 99.9% recall, without trading away absurd amounts of precision...
If passwords cannot contain dictionary words and must be mixed case with at least one special character in digit, there's no freaking way anybody's going to guess their way in, with a small number of tries before the account is frozen. The number of penetrations from that is going to be so tiny, it's not worth worrying about.
The bigger worry are stolen password hashes being cracked surreptitiously, where the attacker has an unlimited number of tries whose rate is only limited by their hardware.
There's other passkeys implementations and you can even use regular yubikeys as a passkey. But the problem is, many idiot sites block these implementations. PayPal for example only allows it in Chrome or Safari.
If it were as simple as printing out a list of QR codes or URL strings I would be happy, but so far no password app I know of supports this.
https://www.bleepingcomputer.com/news/security/new-fido-prop...
That’s where I have mine.
>At the moment, export/import is not part of the "Passkey" standard. The FIDO Alliance has a draft of the Credential Exchange Protocol that would allow such actions.
If it's already a standard, and it's that deeply faulty because it's been brain-dead since the beginning, then for a user having valuable data, they may be best advised to run the other way forever. Simple.
When you have an alliance of previous competitors and they are either incompetent or user-hostile enough from the beginning to leave out the most important factor in recovering from disaster -- personal backup & recovery -- I would want to wait a good ten years until after everyone as untrustworthy as that has been banished from any security work that could be the least bit consequential.
You can't have adequate security with untrustworthy people building the foundation no matter what they say otherwise.
People are the real problem, but clueless "security" people with initiatives this half-baked are more of a threat to average users' valuable data than millions of other clueless users are.
>Passkeys use Bluetooth technology, which requires physical proximity, to help verify the user.
Which I somehow doubt is accurate.
A passkey is an implementation of public key authentication.
The private part should stay with you, this is your identity. The public part gets shared with others, they can use this to verify your identity. "microsoft passkey" wraps all this up into a simple tool that just looks like you are putting in a pin number.
The vague thousand foot mechanism is. someone who wants to verify your identity will ask you to sign a unique number. because only you have the private part needed to to do this, only you can sign it correctly. they can then use the public part to verify the signature is correct. and know it is really you they are talking to.
The private part is usually protected by a device, something to prevent others from using it. this is often just a password, in this case a PIN. but some times is a dedicated usb dongle. this only has to have local security guarantees not global network security guarantees. so a simple password like a PIN is not considered a problem.
The primary advantage over a simple password based system is that the thing that is shared(the public part) is unable to be used as your identity so it can't be stolen like a password. or perhaps more accurately, it does not matter if the public part is stolen(it is already public knowledge)
And now the irony, I have no proof, however I have a suspicion that because loosing the private part is the same as loosing your identity, that is, a big deal and a huge hassle to recover the account. I suspect microsoft is storing them internally. which means your account security degrades to a password based system where the password is basically pubic knowledge, that is, your so called security questions. what is your favorite color? is not a good password.
1. Passkeys contain the username and the domain of the service that you have registered with
2. Because passkeys contain the domain, it provides very strong phishing protections, because a look-alike website still has a different domain.
Passkeys are resident keys. They take up storage space, which is a problem for dedicated hardware tokens which usually have limited storage space. A much nicer solution are non-residential keys that get recomputed on the fly based on the domain name that you want to authenticate against.
The site registers itself with your passkey "wallet" (?), and logging in would use a signed request and your wallet provides a shared secured response so you both can confirm who you say you are?
No. This is orthogonal and can be used in combination with the aforementioned technologies.
Let's assume you want to use OpenID connect and also JWT.
1. You have your own web service that does not implement a login form but relies on OpenID connect.
2. You have an authentication service like GitHub, Facebook, Google, ...
3. Your users have a pre-existing account on GitHub, Facebook, Google, ... They use their passkey/non-resident key/plain old password/... to log into one of these services
4. Your users want to log in to your service. They start the OpenID Connection protocol using the authentication service. If they are not logged in yet, then they have to present their passkey/non-resident key/plain old password/... to get logged in. Once they are logged in, the authentication service can issue a fresh JWT to your user.
5. Your user can then use the JWT to use your service.
Sounds like basically public key logic with a biometric local wrapper?
Thou shalt not sign arbitrary plaintext
… if, as you say, a service first gives you something to sign with your private key ?
What kind of “phishing” would it be if Mallory convinced Alice to create a new account on some new service for the purpose of leaking private key bits?
Really I am not an expert in this field, but
As far as I can tell signing arbitrary plaintext is a core mechanism in how public key auth works.
The theory is you have to sign something to prove your identity. this thing you sign has to be provided by the authenticating body and should only ever be used once to prevent replay attacks. that is you never want a situation where someone can give you a copy of the signed message and login.
For example, and the only one I have actually read the standard, during auth ssh signs a number of fields, the critical one being the session id. the session id is provided by the server and is only used once, thus satisfying this critical part of public key auth.
Is it sending a reset to a recovery email?
Yeah right, pass along responsability to someone else. And you wonder why people don't trust this "security" solution.
Passkey is just not supposed to solve all the problems in the world. It's supposed to replace login and password and that's about it. Authentication.
How do I get my keys out of Apple's wallet again? Or out of a Yubikey for that matter.
They are no longer under my control and I depend on Apple's or Yubikey's benevolence to access my services.
You don't, and neither does an adversary. That is literally the whole point of paying $50 for a Yubikey.
Oh no I forgot, I could pay even more to have backups.
If the security properties of a hardware authenticator aren't important to you, you don't need to use one at all.
You either have an extra set up or you work around the problem through some kind of recovery method.
Seems like this will also be difficult for a lot of non-technical ppl. Though I guess not much worse than forgotten passwords?
In Scandinavia we have authenticators tied to the banking system (MitID in dk and BankID in sv), where if you lose it, you can get it renewed by going to your bank, or you can have a special hardware device at home that helps you renew it. Does this exist other places? These are used on more and more sites around here, where your real identity is important (everything utilities, banking, insurance, banking etc).
But Passkeys have a huge problem: They assume you will never have your device(s) stolen or broken or otherwise made inaccessible.
What happens if you're out of the country on holiday and your phone/laptop gets stolen and you need to log into your account(s) from a brand new device? You're mostly shit out of luck if you use passkeys. Especially because most peoples' backups/account recovery is a google email or icloud account which...requires you to have a known device handy to access them or set them up on a new machine.
Just like with a password manager
> Plus, passkeys eliminate forgotten passwords and one-time codes.”
Again, can't forget what's stored in a password manager
Unfortunately she is unwilling to change her Windows pin to anything other than the PIN she uses everywhere else.
This has not improved her security at all. Before she switched it from what I assume was a Microsoft prompt, she had (through a bit of coaching from me) been fine with Bitwarden + TOTP
I do worry a bit that using a passkey tends to disable MFA requirements, so basically anyone with access to my bitwarden vault can log into those services.
PAKEs use passwords, and they are unphishable. That is the direction we should go to avoid vendor lock-in.
It does handle the second and third, IIRC.
Passkeys work because the user can't be tricked into entering their private key on a phishing website.
This is why I keep a spare.
You can pay a locksmith to pick (and rekey) the door lock. You can even break down the door and replace it later. None of that is an option with passkeys.
Ah, the magic of having two of them! Truly a revolutionary experience.
I just used my physical tokens or my laptop or desktop to authenticate my new phone.
Unless I'm using a password manager.
> Users are three times more successful signing in with passkeys than with passwords (98% versus 32%).
With my password manager, I almost never fail to sign in. Admittedly, the autofill does mess up on some websites and then I have to spend a few seconds fixing it.
On the other hand, I am pretty darn skeptical that only 2% of users with passkeys have trouble signing in. Are they not counting the people whose passkey accidentally got deleted, or who are on the wrong device, since those people (by the nature of passkeys) could not even attempt to sign in?
What about the flow where 99% of users don’t know how to back up and restore passkeys and get permanently locked out of their accounts?
Not hat I would ever imply that Microsoft has anything than our best interests in mind...
In fact, I would wager that the majority of current passkey users are on iOS (since Apple has been pushing this for a while now, and it's nicely integrated).
No it's not. How am I suppose to login to a console of a air-gapped server with passkeys?
> Signing in with a passkey is three times faster than using a traditional password and eight times faster than a password and traditional multifactor authentication.
When you sign in to anything Microsoft, you have to go through four different redirects, sure automatically but not not exactly single page sign-in.
> We don’t let users permanently opt out of passkey invitations, but we keep the messaging friendly.
by friendly you mean Dark-UI to push the user in the corner forcing them to accept as you limit their options one by one with threatening notification and nagging.
> We’re proud to be part of this collective effort and hope you will share learnings as well as you progress in your passkey journey.
Learnings is a grammatical error. Microsoft is proud to be a collective for part of vendor locked in.
The rest of all spunk.
Passkeys don't require the internet to work
USB has been disabled for security as I don't own my quater-rack (yet) in which I share with other DC customers.
The system is in a critical state where by a reboot would be disastrous.
How am I supposed to login with passkeys?
What you know then what you have then what you are
To passkeys any better ? Sure you cant hack them but what happens with losing your phone ?
How do they authenticate if they are not leaving the secure storage ? Through telepatic transmission ?
One of major failures of the passkey marketing is that the FIDO Alliance left it at:
1) Vendors marketing passkeys as this brand new thing for their customers;
2) Anyone technical needing to already know that passkeys weren’t this brand new vendor specific thing, and reading the standards documents.
Passkeys are essentially just a marketing name for FIDO2 credentials with a focus on particular kinds of implementation. But FIDO didn’t bother to handle communications to technical folks outside the authentication space, and they’ve failed to do so effectively beyond that area.
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
Now imagine a whitelist of acceptable providers. Suddenly, you don't even own your credentials anymore.
"Secure storage" defined as the vendor's cloud services but not the user's eyeballs.
“In the two years since passkeys were announced and made available for consumer use, the FIDO Alliance reported a few weeks ago, “passkey awareness has risen by 50%, from 39% familiar in 2022 to 57% in 2024.”
I don’t think that math works? Am I misinterpreting something?
I think they meant 50% increase from the 39% .
Imagine it was 100 people. 39 were aware. 50% of that is 20. So now 57 are aware, which is 18 more than before, which is pretty close to 20.
So yeah, it was a change in 50%, but it was only 18 points higher.
Microsoft's "convincing" is just going to be more months of casual user assault, abuse, and gaslighting with no way to just say "no".
This is similar to SSH or git operates when you disable passwords and use keys in ~/.ssh, for example.
You can store the private keys in YubiKeys or in password managers.
There is no private info (aka a password) going out in public so you don't have to trust anyone to keep your password secret.
It greatly reduces the attack surface of logging in, but the attack surface is moved to the weakest part of the system, aka the user.
I think I have used a digital passkey a few times to try it. Works okay, I guess.
It's nice when we build a non-brainer technology which gets adopted at scale by default, as happened for TLS 1.3, or even when other motives overwhelm the instinctive conservatism (e.g. Let's Encrypt) but that can't always happen and it looks like for WebAuthn the conservatives are going to stick by passwords "From my cold dead hands" etc.
One problem with HN in particular is that there are a lot more decision makers here, so more people whose conservatism means they're going to build, promote and demand worse solutions since the better option is in their minds impossible. That's unfortunate, it means there's a good chance that over the next years I'm going to be using more important services which have terrible authentication on account of somebody senior said "Passwords are good, we should require passwords" and anybody disagreeing was hushed or worse fired. So that's not great, but it is what it is.
Anyway, for the few people who get why this is a good thing but understandably don't trust Microsoft (or Apple, Google, Facebook, I dunno, Epic Games?) I have a suggestion: All of this technology also works fine with a Security Key, which is a thing you can buy from Yubico (or several other outfits, but Yubico is easiest if you have no idea what you're doing) for like $25. And if you - like me - use Security Keys those "But what if I lose it?" questions can be answered by Technology Connections' favourite: The magic of buying two of them.
> "But what if I lose it?" questions can be answered by Technology Connections' favourite: The magic of buying two of them.
And the magic of having to access both of them every time you create a new account anywhere, which probably means you'll keep them both close by – increasing the availability risk.
A more realistic recommendation would be to use an open source FIDO backend such as Bitwarden or Strongbox that let you cross-platform sync and, worst case, export your credentials if the vendor goes down a bad path.
Personally I would rather have Security Keys, and there are going to be plenty of people like me. Yes, if you need a physical object as an authentication token you will sometimes need to have that object with you, I also thought that went without saying, but it's true in case it wasn't obvious.
Signing up for new accounts which deserve a separate meaningful identity (like a bank account, or a Youtuber's account, or GitHub maybe) is not a common occurrence, in the time since I last got a new Security Key I have added let's see, zero new accounts, so I had to add that key to all the existing accounts, at work and outside, then nothing.