Meanwhile, half of the people at every company I’ve ever worked at:
Passkeys are awesome. Developers not following the standard properly are a trap.
The biggest problem I see is that it requires OS or browser integration. While possibly a better solution than simple passwords this feels like a vendor lock-in scheme.
You could store them in your password safe if it supports them?
Potentially the server can request hardware/software attestation that would limit the choice of password safe to approved ones only. We don’t yet know how big/likely this could be, but in theory it’s possible.
Passkeys are greate as long you make sure you use a third party (partial) password app, like proton or bitwarden that works everywhere.
I think the worry is that if passkey attestation is required it will force people into a narrow set of authenticators controlled by the big orgs.
At this point in time it’s not a problem, but how can we know it won’t be in future?
This right here. KeepassXC (PC) already had passkey support for a while, KeepassDX (Android) recently implemented support. If you use FOSS implementations, vendor lock-in and potential future corporate enshittification are non-issues.
The argument from the “it’s a trap” article is that the service you are registering to can use attestation to ensure that you are only using passkey managers that they approve.
I have to admit that I haven’t investigated this thoroughly myself but if the protocol can be abused in that way then your only choice really would be not to use the service. If it is related to banking or government services then you may not have much of a choice.
The web api for fido2/passkeys exposes attestation information.
Warning: Attestation provides a way for a relying party to determine the provenance of an authenticator. Relying parties should not attempt to maintain allowlists of authenticators.
from https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
I did read that part, but like you, I haven’t been able to independently verify it yet.
Which most people don’t do.
They’ll learn like I did the hard way. Lol
Admittedly I didn’t read that one guy’s blog post very closely, but it seemed to claim that because some companies may some day misuse/abuse some features of passkeys, passkeys are poison and no one should ever use them.
Well if that’s possible, it doesn’t sound like a good basis for security.
The features they’re talking about are secure from a cryptographic standpoint.
However, there are features built into the passkey system so that a company could decide that it will only accept passkeys from a specific piece of hardware or software.
This isn’t necessarily bad, you may only want your server to allow you access if the passkey comes from your phone’s hardware. A person could have stolen your passkey but they’re unable to fake the attestation step.
On the other end of things, a company like Google could provide a passkey service which requires you to use hardware provided by vendors that they approve of and they could abuse their position to force it’s implementation, such as how you can use Google to sign into websites via OIDC.
Google could just as easily provide a service for ‘secure’ passkeys which are only allowed to be issued by phones provided by Google, Verizon or AT&T. No more third-party OSs (at least, if you want to sign into anything on the Internet) and no more jailbroken phones. You would have to use the exact, spyware laden, operating system that comes installed directly from your cellular provider who would have remote root access to your device.
I think the idea that we can just boycott passkeys and prevent this is nonsense magical thinking. It requires some hypothetical world where we can perfectly coordinate a boycott of otherwise useful technology. In reality this issue will remain obscure and generally only known to people interested in the topic while Google can pour tens of millions in advertising to reach everybody on the planet explaining how good and secure attested passkeys are to mainstream Internet users.
Use passkeys, they’re useful and more secure than passwords. Not using them won’t prevent enshittification, just sit back and watch the slow motion attested passkey trainwreck as it unfolds over the next decade.
I’m gonna need to find this comment in ten years. Wish me luck
Another point someone brought up in one of these posts: the remote attestation (IE locking your passkeyto a specific app or software) issue is highly unlikely to be used for public websites, because it would block / halt the adoption they’re trying to promote, and its against their interest. No website that I know of has done this for TOTP either.
They push TOTP and passkeys now because they want to avoid the costs and support around resolving hijacked accounts, and password phishers.
The use-case for remote attestation is a valid one also: say you have a really secure internal system that you want to lock down to only users of your specific passkey validator, and make sure its that specific app, unspoofed.
Brought to you by the community sending death threats to a guy that added a date field in a program
Who did what now?
The developer who added a “date of birth” field to systemd received death threats, because some people saw it as a first step towards age verification and apparently the appropriate response to that is cyber bullying and death threats
They really aren’t a trap. They’re a well designed standard. The tooling around them isn’t quite perfect yet, but they’re a huge improvement over passwords.
People upvote because they hate change.
People upvote because they hate change.
People upvote because big tech has a tendency of forcing the most anti ownership outcome possible on everyone. Here, such an outcome likely would be mandatory passkeys that are set up to require hardware attestation.
One way to reduce that risk is to boycott passkeys until TPM and hardware attestation are removed from the standard. You may not think that’s a fair response, or that such a boycott won’t save us from the inevitable outcome, but nevertheless it’s not a completely irrational reaction.
This is what people seem to be missing, I haven’t seen a rebuttal to this problem.
I only dislike the ability for service providers to enforce a “security level”. Those should be the exclusively under my (the user) control. Sending preferred default (hints) would be cool, but not enforcement.
That a webpage can basically prevent me from using a passkey if the passkey is stored in software (a password manager for example) is complete bullshit. Especially if there is still username/password as alternative which is clearly worse. Sure, hardware tokens are the ultimate security. But it should be up to me and not them if I want that level of security.
This has actually been a really good discussion on both sides as I think many including myself didn’t know about some of the inner workings of them. I’m glad the discussion happened. The trap article IS worth a read, it’s overly long but is really well written. After reading enough about both sides though I don’t think I’m too worried and will continue using them.
I fucking love passkeys. I hate 2FA on every god damn website, but clearly the majority of people are too lazy/stupid for passwords alone to work in a time when phishing is so widespread. My only problem with them was that I couldn’t use my Bitwarden passkeys in Firefox for Android, but they fixed that, and I’ve never had a bad experience with a passkey since.
I have a password manager and hardware token. I see no need to use passkeys.
Password manager can store passkeys as well. They’re way easier to fill than passwords, they always work and never have issues with filling like you can have on some websites that just don’t work well with pw managers.
Still needs an arguably perhaps overengineered complicated standard to do it, and seems to open the door to more hardware attestation demands. I’m not a fan and I refuse to use passkeys. (But I can see the use for preventing fishing attacks, so I realize there is no obvious perfect answer here.)
Yubikey4lyfe
Yubikeys support device bound passkeys already.
But you need to buy at least two of them, which isn’t cheap.
And… honestly, you should probably buy 3. Losing your main key only to find out that your backup key broke a month ago and you haven’t been testing it is a real risk.
I ended up getting one through arstechnica (they sent one if you subscribed back then), then I got more through some sale or something
are passkeys not a type of a hardware token? they’re tied to a device.
They’re actually not tied to a device. They can be synced across devices.
Bitwarden, 1Password, Dashlane, Google, Apple, and Microsoft will all do passkey syncing for you.
We don’t yet have a good Linux native passkey store. I believe the
credentialsdproject is working on a spec for that. Once that’s up and running I would expect to see some options for syncing without relying on a third party service (though, you can self-host bitwarden right now). It’s definitely not seamless on Linux yet though.Sadly 4 of those companies are American, and Dashlane has significant US operation presence, making those recommendations unacceptable to me - ymmv
1password is Canadian and zero-knowledge so could be an option if i didnt already use a different service.
I dont like the idea of pre-authorising a device to handle credentials and access in perpetuity at the hardware level. I’d be fine with having a hardware key that holds passkeys but cant use them, while the device using them can only do so when i put the two items together. Unfortunately i do not understand how to save a passkey to a hardware key or how to manage them once that is done. Till someone gives me a straightforward ux to do that, i’ll be using unique passwords, a manager, and totp.
If i am misunderstanding, thats just a different problem; the passkey thing needs to be explained more clearly.
Microsoft makes a hard distinction between Device-Bound and Synced passkeys inside of corporate tenants. They are in fact two different things that happen to be using the same FIDO standard, and can be stored alongside one another in the same app if it supports it.
Also KeePassXC with the browser plugins works a treat for synced passkeys.
so whats a passkey and how is it different from a password?
It’s essentially just public key cryptography streamlined to reduce friction for the user. When you’re prompted to create a passkey for a service a new public/private keypair is created. The private key can then be synced to other devices for example via the iCloud keychain or Bitwarden. Obviously you have to then trust that provider to keep your keys safe. The upside is that your passkey can be automatically discovered and used to sign in without using a password. Alternatively the private key can be device bound but the downside is that if you lose the device you lose the private key too.
If it was just to helpfully reduce friction, it wouldn’t be so controversial. The inclusion of any sort of TPM and hardware attestation support at all is what has some people sounding the alarm (in my opinion rightfully).
It’s mainly controversial because the actual use contradicts its purpose. Passkeys are phishing-resistent, which is still the main risk for password in real world scenarios, and are a good idea.
But the websites supporting it put out big warnings when you don’t have another method to login configured. And they don’t actually advise you how to backup your passkey and keep it safe, but instead want you to set up an alternative way to login or recover your account. Which totally defeats the purpose in the first place.
Quite the contrary: “there is a problem with your passkey/account, please use the recovery method you set up” even makes for more convincing phishing. So why are they pushing for passkeys when it isn’t for security reasons?
This is, imo, the bigger issue. No clean way to export and move passkeys around, even between the open source options like Bitwarden and Proton Pass or as plain backups…
My post was only meant to be a quick explanation of what passkeys are so I’ll leave it as is. I do think it’s healthy to be suspicious of big tech corporations and their motivations though so I’ll be doing some further reading.
That passkeys are a trap article also has straight up one of the best explanations what passkeys are https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them
A passkey is cryptographically signed by the server when it’s created.
So it does not only has your credentials encrypted which are then used to login to a server, but it also carries information about the server and only that server can request the credentials from the passkey. So unlike a password a passkey is resistent to phishing attempts as you can’t actually give your credentials away to anyone but the actual server it was created for.
Again with this?
I’m going to do the smart thing, get drunk and pass that key to a designated driver and let him figure it out.Or “Like all questions of security vs convenience, a user should decide what they are or are not comfortable with.”
I think the reason passkeys are so controversial is that tech has a long history of ignoring user choice and pushing the most anti ownership solutions possible. Therefore, I think there is fair concern emerging along with any new mechanism that has any sort of TPM or hardware attestation components at all.
The concern is valid, but we should also look at these company’s interests in pushing passkeys, which first and foremost is avoiding all support and resources they have to dedicate to password resets and account hijacking, of which TOTP was the band-aid for, which they also push.
The software or hardware attestation is IMO a non-issue for most public sites. We have a precedent in TOTP, and they haven’t locked those down either to specific software, because they care more about adoption (to avoid the costs above) than controlling what software you use to validate.
If someone wants to say that these companies will turn on this attestation for passkeys in the future, and break a ton of logins and decrease adoption, then they should have a reason why they haven’t done so for TOTP.
If someone wants to say that these companies will turn on this attestation for passkeys in the future, and break a ton of logins and decrease adoption, then they should have a reason why they haven’t done so for TOTP.
Didn’t you already answer this by saying they want to increase adoption? That seems like the reason. I think the argument here is the same as what they do with something like streaming (which is closer to what I have a problem with, rather than locking people to specific software). They work on adoption until the numbers and ease of use are high enough to kill the other options and prevent multiple people from logging into one account. They lose some people, but gain more because of the new restrictions forcing people to have their own account.
Doesn’t necessarily work the same in that sense, but it’s still a numbers game. We continuously see companies/governments postpone onerous policies until they have enough people willing to put up with it. Then they ram it through and ignore the people that complain. It’s age gating and digital only purchases and digital id and backdoors and everything else we see with tech.
Passkeys are a good idea to prevent phishing. Using passkeys but then require a second method to login as a backup to prevent lockout when you lose your key (as many sites do) is epic bullshit. It makes an actual security improvement into some convenience feature so people don’t need to remember/type passwords anymore. Because the phishing will now ask for the alternative/recovery login to fix some alleged problem with your account/passkey…
So it suddenly does not provide additional security anymore above what a password manager would already do.
When you sell somehting as a security feature then instantly defeat the additional security to make it just about convenience the question about the actual goal feels natural…
the duality of passkeys
No duality: only suck
Seems like if you want something to be able to be unlocked, you’ll need a key.
It’s the typical case of perfect being the enemy of good.
Passkeys… how to make the public still not understand mutual TLS…
If you read the pro article you can tell its a bunch of hogwash as they don’t understand Tue point of passkeys.
The person that wrote the anti article thinks that 2fa is a form of password… they’re the one that doesn’t understand passkeys.
