Link: https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them

Comments

Never used. Each time a website asks me if I want to create one I have this uneasy feeling of not actually owning the key.

TIL what passkeys are. Thx for sharing.

If your security relies on a password, you will always be anxious that somebody, somewhere, has somehow figured out what it is and already has access to your bank account.

No I won't. All my passwords are something like I0!2b6KJ!eA04WiJ&&MFToCQ7CN*4mvb and each is used for only one thing because I've been using a password manager for over a decade.

I0!2b6KJ!eA04WiJ&&MFToCQ7CN*4mvb

Mwahahaa, I'm in

https://lemmy.ca/comment/25786053

I've always thought they were a really bad idea. It puts everything into a "setting you have" factor and removes the "something you know as well as the need to match the factor to a username. And if the site is hacked, they can get a lot of information about how the passkeys are generated even if they don't get access to secure info. It just simplifies the ability to hack a random account in many ways if not a specific one.

This is why I only use passkeys that are stored in my self hosted vault warden. As long as you don't create passkeys locked to a vendor's manager, I don't see any reason to avoid them.

The Bitwarden client is so bad though. I seem to only be able to use the passkey on the specific device I saved it in.

This is some weird doom and gloom take on a real improvement in public security that we don't see very often. Of course there are a lot of stake holders. Of course every protocol is complicated. I run security for a company, and my auth systems mandate attested (i.e., company-provided) hardware keys. You're not using a passkey on my systems that I'm not providing you. Pretty simple concept, yes?

Do you have any examples of any public service requiring attested keys? No, because it really doesn't make sense. But because the protocol supports it, people shouldnt use passkeys? Shitty hot take.

I agree it would be helpful to make the feature set clearer to the end user, but the UX are still a mess across OS and websites. IMO that's not a reason to not use them.

Passkeys are much more phishing resistant. They apply unqiue-credential best practices. I've been managing unique passwords for decades, and passkeys are a great improvement. Very few companies are going to completely remove other forms of auth, and so suggesting passkeys are ruining people's ability to share passwords is really premature. And even so, companies have been pursuing other strategies for identifying shared accounts much more effectively than shared credentials. Thinking that's a reason to not use passkeys just tells me you aren't valuing how passkeys elevate public opsec.

Passkeys are projected to overcome TOTP market share next year. That is honestly amazing. I like the writeup on the features, but this nefarious, conspiratorial narrative doesn't fit what's actually happening.

I've experimented with this and haven't had a problem. However, I was using the open source fork Vaultwarden and only the browser extension(s).

Hmm I haven't had that issue, I have a lot of passkeys saved and they sync fine and are usable in Firefox on my laptop as well as with apps on my pixel 5 running lineage. I have noticed that occasionally an app will refuse to give me the option to create a passkey in bitwarden, but I just skip those and I haven't noticed that issue in a while.

Have you checked whether the site entry shows the passkey on both devices? On mine it'll say "passkey created ..." on both devices in the vault.

Haven't had that issue using Vaultwarden backend and bitwarden android, Firefox and Chrome extensions.

I evaluate it based on that they replace passwords.
Password is shared secret, which is bad. Passkeys are public-private cryptography, which is good. Passwords has to be stored in a password database and your username is gonna be stored alongside it, so you might as well store your passkeys there istead. Passkeys have the added benefit of being possible to store in an authenticators secure storage, like a security key. I see no real downsides, relatively speaking. Passwords that are created by humans, those not using pw managers, are gonna be bad.

With my security key, using FIDO2, i have to have the key, touch the key and enter a PIN. My key is never exposed, signatures happen on device. It's neat!

Ah there's that phrase again, remote attestation. That has very quickly become my least favourite phrase, and I've yet to see an example of it that benefits the end user. I didn't know passkeys supported it but I'll be avoiding them even harder now that I know they do.

I've already been avoiding them because I don't see how there's any security advantage over TOTP unless the passkey is the only way to access the account (which would be awful for account recovery). And the concept of tying my login to a specific device is stupid. I also don't appreciate how many websites keep trying to stealthily create passkeys automatically on login without explaining what they are or letting the user make an informed decision.

That is the issue of passkeys. They are hard to understand and without understanding there can be no trust.

Problem is passkey generation, expiration logic, etc., is often not well protected, so if a hacker is able to get it, they may not be able to target a specific account, but they can target random accounts with semi-bruteforce since there's no username to limit tries against or lock the account if there's too many tries. Just use a botnet and start throwing probable keys at it and you're likely to get a few.

Also, with a password repository, I protect that as exceptionally as I can, but I can always change my passwords and would do so of that was compromised. But I'm not talking about the passkeys of an individual being stolen, I'm talking about a compromised site having very little way of determining of a hacker has gotten enough information to narrow brute forcing down to a relatively manageable level with a botnet and using that to access random accounts for personal information scraping. And the user may have no idea it's happened to them since the bad tries never were associated with any login.

My background is very much not in this world so caveat my questions/response below with that mind set. I do however try to practice decent personal opsec such 2fa (TOTP), password manager with random generation, etc.

I feel like a lot of what you stated was covered in the article. For example the article states that problem isn't the number of stakeholders, it's that none of them are consumer advocacy groups.

I understand that the author maybe leaned on the password sharing example too much but I think that was in an effort to present the material in a friendlier manner to the average reader. The closing statement makes it clear it's not really about Netflix, etc. The main concern is that attested passkey requirement will now be the easiest way to force specific software and hardware upon user. The GraphenOS example is a good one.

You might not use the attested flag in that manner but I have zero doubt that once passkey adoption rate passes a certain threshold Google will be more than glad to miss-use that flag to lock people out of their gmail account unless they have the most recent phone and software.

Do you have any examples of any public service requiring attested keys? No, because it really doesn't make sense. But because the protocol supports it, people shouldnt use passkeys? Shitty hot take.

I think this is a bad take. "Because this potential is not being misused right now it won't be a problem in the future" has not really served us well thus far.

My understanding is that the article is saying that passkeys are giving away too much control to the second party. That can and will be abused.

But again, layman's understanding from my end.

Just use a botnet and start throwing probable keys at it and you’re likely to get a few.

This is not plausible, would take billions+ years to stumble upon just one with a botnet that has all online PCs on Earth utilized.

Remote attestation is the real problem with where passkeys are going.

And if the site is hacked, they can get a lot of information about how the passkeys

I don't like passkeys, but this is not a real worry, unless the service you are using is ran by idiots. I mean to say that knowing how passkeys are generated is typically not helpful in guessing your passkey. There are more interesting questions where security fumbles, like is your data encrypted on the provider side & is that encryption tied to your passkey or not, often not, since they want to mine your data.

You'd be surprised how poorly most modern web developers (especially LLMs) understand cryptography and the importance of protecting secrets, often storing them in plain text in poorly protected code repos, etc. On a site with a large enough user base and access to that information, it's absolutely possible to reduce the number of tries to hits to a manageable level for a distributed botnet that can't easily be blocked.

You'd be surprised how poorly most modern web developers (especially LLMs) understand cryptography and the importance of protecting secrets, often storing them in plain text in poorly protected code repos, etc. On a site with a large enough user base and access to that information, it's absolutely possible to reduce the number of tries to hits to a manageable level for a distributed botnet that can't easily be blocked.

This is actually a terrible take. Passkeys provide a very large security benefit over passwords and have an open standard.

It’s particularly ridiculous that they seem to think TOTP good passkey bad. They solve the same problem: symmetric persistent encryption like passwords is very weak. TOTP solves this my making it not persisting and passkeys solve this by making it asymmetric. Passkeys are mildly more convenient because you don’t have the copy a code over.

Both also have the same potential for abuse, any service could require you use their specific app. The fact that this article makes it sound like TOTP is a perfect open standard while passkeys are a Trojan horse for abuse is ridiculous. If most services are using the open standard for TOTP why wouldn’t they for passkeys? Also not all services do obey the open standard for TOTP. I’m sure I’m not the only one who was forced to install the duo Authenticator because their institution was somehow sold on their protocol being stronger than the open standard.

TOTP and passkeys are comparable and both with doing.

I've already been avoiding them because I don't see how there's any security advantage over TOTP...

I'm not going to challenge your choice in using passkey or not. However, I do want to set the "technical record straight": passkey is the successor to TOTP in every technical way*.

TOTP works by having a "shared secret" saved by both you and the place that your authenticating against. This shared secret is then mixed with current time to generate a rotating number that the client shares with the remote server. The remote server does the same calculation, if the rotating numbers match, the user is successfully authenticated.

With TOTP, this means that there are two attack vectors: your device and the remote server. If an attacker is successful in getting the "shared secret" from either, your TOTP is effectively broken.

Passkey works more like ssh-keys. The client generates a public and private keypair. The client only shares the public portion with the remote server and stores the private key locally (or in your password manager).

So the only attack vector (with passkey) is your device (this is often why it's bundled with attestation). Also passkey is not dependant on both the client and server having their time kept in sync. With TOTP, if you have more than ~30 seconds drift between the client and server, they will be generating different rotating codes and never match (which is confusing when you need to explain this to your Grandma).

• there is one thing TOTP can do, that passkey cannot: TOTP is 2FA, your TOTP can reside on a separate device (ie your phone when logging in using your PC). With passkey, you'd need to enable 2FA on the passkey manager (which varies from manager to manager).

...unless the passkey is the only way to access the account (which would be awful for account recovery).

Recovery options are never going to go away. With TOTP, you often have one-time use backup codes. Email, SMS recovery etc.

I am using the same combination, but the passkeys do not persist between different browsers

The main problem is that there's no place to view my passkeys like there is for passwords for TOTP (according to my searching and their website, anyway)

Yep, using the exact same and still have the problem.

Pepperidge Farm Remembers when the FIDO Alliance threatened to recommend the blocking of FOSS implemententions because they gave the users control. Control over backing up. Control over not using biometrics.

When something wants too much power, you must avoid.

In the bitwarden browser extension, settings -> autofill -> "make bitwarden your default password manager"

Is this checked?

I also set a "pin" in settings -> account security -> "unlock with pin".

(After reading the article: maybe passkey requires bitwarden to be "more secure" - I dunno)

In vaultwarden, they do appear in the web client. The behavior you're describing hints that your passkeys are not being stored in bitwarden.

...and tbh, the UX sucks pretty bad: I was trying to store a passkey in bitwarden, but it was failing (unrelated networking error). I had two options: add it to bitwarden (which failed) or cancel. I hit cancel and was prompted for my fingerprint, which I provided -- this ended up storing it on my device... no input, no description of what it was doing. The website came back with "passkey now enabled" :facepalm:

See I bought a couple of yubikeys, but have zero passkeys becuase I've yet to encounter any service that lets me choose to store their passkey on said yubikeys. How do you do it?

Seems to me that if I could tie them to yubikeys (ideally on two keys), remote attestation wouldn't risk me allowing any third party to assert influence or control over my choices of technology - is that right?

Amazon is probably the most visible example of trying to create passkeys all the damn time, but it never offers any user choice about where this passkey would be (my best guess is that its on the computer and tied somehow to my login).
I'd happily use passkeys with yubikey, but I'm not willing to set up a different passkey on each computing device I use. Thatś a housekeeping/maintenance headache I dont want or need and it would be made all but impossible if I give up visibility and control over what devices are 'authorised' and how.
I hate to think how many people have inadvertently set up passkeys on devices that they rarely use.

Oh that's good to know, I didn't realise TOTP was vulnerable on the server side. I'm still going to steer clear of passkeys for now though.

Thanks.

Thanks.

FIDO 2 level 2 also requires the supply chain documented and a bunch of expensive certificates, which locks small vendors and open hardware implememtations out.

Thank you so much for clearly and concisely explaining how TOTPs are kept in sync between server and user. I KNEW the answer couldn't be "magic".

I don't think any service allows passwords that long

Happy to discuss a few points you've brought up.

it’s that none of them are consumer advocacy groups.

I would put that more as a curiosity than a red flag. I doubt they were excluding groups, but happy to hear about if they were (e.g. donation minimums or something to that effect). The author actually says that whole paragraph is "notable" -- great, noted. I hope that doesn't mean they were using it as an argument for "Do not use [passkeys]" (the title of the article). FWIW, W3C recommends use of passkeys. EFF has had blog articles for 3+ years suggesting advantages of Passkeys. I also don't know what a consumer advocacy group would suggest differently here -- DONT implement an attestation spec? Attestation is a massive improvement for specific types of security.

The GraphenOS example is a good one.

I went and looked for what you were referring to and didn't find anything. What do you mean by this? I use GrapheneOS. I use passkeys. Google being hostile to third party OS doesn't seem related but maybe I am missing something.

I have zero doubt that once passkey adoption rate passes a certain threshold Google will be more than glad to miss-use that flag to lock people out of their gmail account unless they have the most recent phone and software.

Well this seems like a reasonable point I should expand on. Maybe I can plant a seed of doubt about this hypothesis. A few comments:

1. People being locked out of their email is actually one of the biggest logistical nightmares for email providers. Proving someone is who they say they are is actually fairly difficult as well as doing it at scale. People lock themselves out of their own email. People get locked out of their email because of phishing attacks. In practice, Passkeys reduce phishing rates significantly. That's a massive win for email providers in reducing their burden. Intentionally locking out a massive number of their customers is an unthinkably bad move, comically bad. It wouldn't happen.

2. Email is the most important mechanism of communication for people's security. Bank and financial accounts, paid services, government notices... they are almost all through email. The idea that they will vendor-lock email to specific hardware... it's not realistic. They would face such massive PR And public blowback. Email is also accessed from more than just your phone. "Requiring" an attested phone would kill a massive use case.

3. People already feel locked to their email provider -- it's extremely difficult to change all contacts you have to a new email address. Passkeys don't change that. Phone hardware doesn't change that. So I'd say it's just a continued problem, and not a reason to not use passkeys.

4. The FIDO Alliance had like three phone manufacturers out of 250 members.

Overall, I don't see how passkeys, or attestation, could lead to a world where any public service would want to require attestation, and even if they did, there's no reason it would be "requires my X branded phone". These companies supported the development of this protocol for the specific reason of NOT wanting to cater to specific vendors. This is a vendor-neutral specification. There are many hardware and software providers. They all have their own motivations, and they hope implementing the spec brings in more customers, improves consumer security, and reduces their operational costs. Do you still have zero doubts about a future world with vendor-locked attested passkeys for public services?

passkeys are giving away too much control to the second party.

There are already dozens of hardware and software passkey vendors. It's honestly amazing how little lock-in there is. There's a half dozen FOSS authn services providing passkey services. You can buy dedicated hardware for passkeys from multiple independent companies. What "control" are you referring to? Companies could always force rotate your password, make it invalid, etc. Any control you thought you had was an illusion.

Cheers

Despite the attention-grabbing headline, the only negative thing I can find in the article about passkeys are this section:

Attested passkeys7 are the last but most important type of passkeys you need to know about. These types of keys use what’s known as remote attestation to cryptographically verify – using the aforementioned tamper-proof cryptoprocessor that lives in all your modern devices – that you are using one of the several approved passkey managers, and not using a custom one that you vibecoded yourself and which can lie.

This is the feature that means you no longer get to make the calls about your passkeys. Fortunately, attested passkeys are not yet required on most websites.

I don't see why we should assume this hypothetical is going to happen. There is a lot of different software that supports passkeys (I use keepass for example), and going against the open standard and forcing all their users to use a specific software would basically make them unusable.

Overall every password / login style has its dangers and bad ways to use it, including passkeys. That doesn't make them "traps".

When you go to log in with a site that uses passkeys, bitwarden pops up with a list of passkeys for that site, the same way autofill shows your logins for that site.

I switched to using a password manager last year that scrambles all of my passwords like how you describe, and hot damn is it nice, both in terms of security and convenience.

If the site supports passkeys, the site asks the browsers WebAuthn API to create a passkey. From there it's up to the browser where the passkey ends up. In firefox, for example, it tries my security keys first, and I can choose which one by touching it. If you use a password manager, like KeepassXC, you install an extension to hijack this process, so all passkeys end up in the password database.

Attestation on a security key just means the firmware on the key has to be signed. So in theory, you can't use something like the 'Solokey hacker'. When sites ask for information on my keys I ususally choose to block it in the browser. That has not been a problem so far. I allways register two separate keys for each service and they are fully mobile. A security key you could not bring with you would be pointless.

I have amazon passkeys on my security keys. I didn't notice anything unusual with the registration process.

All the sites I've encountered have allowed me to use my security keys. Google had some dark pattern that made it confusing to set up and Discord does not allow passkeys for login, so the ones they let me create ended up undiscoverable passkeys, only for 2fa. The only site my solokey didn't work so far is l1t forum. I don't know why. but I doubt they require an attested device.

I use a NFC key for my phone.

I would not accept a device bound passkey. Nor would I let a third party, like Google, manage them for me.

If you wanna try it out; use https://webauthn.io/

the vast majority of mine are +50 characters - you are just wrong. the services which strictly limit the length are rare and their security is suspect since they should be hashing your input anyway

Didn't know that. I stand corrected

SQRL, been around before passkeys, it's portable, and it's FOSS.

I mean it's probably a good idea to have some kind of limit in place, because you really don't want to deal with attackers trying to transfer megabytes worth of text in the password field and triggering an OOM on your end. But this limit should still be pretty high ofc.

Most do. Source: I usually use passwords that long.

Maybe 1 in 10 don't, and I find that annoying since 32 characters containing only lowercase real words and spaces has several times as much entropy as 8 characters of random mixed case letters, numbers, and symbols.

But your private key should never leave your secure storage to be put anywhere. If you somehow export it and then also give someone or an LLM access to it, then this is ofc very stupid. But this attack vector is possible with every authentication.

I default to using 128 characters because that's the max for the password generator I use. A surprising amount of accounts are OK with that, like more often than not. I have pared accounts down massively since using a password manager though, and use privacy respecting services when possible, so I may be self selecting here.

Also, like, if it doesn't allow me to set up a passkey because my manager or OS is not supported...I guess I'm not setting up a passkey then, which is OK by me, so there is no problem.

for sure, but limiting it under 64 (the length of a sha256 hash) isn't ideal at all