Passkeys: don’t stop them Passkeys: don’t, stop them
What a shitshow
Usekeys are a pass. Trap them!
Them pass a use, keys are!
Last time I was in Thailand and my buddy told me don’t worry, she’s not a trap.
Meanwhile, half of the people at every company I’ve ever worked at:
So at a customer I found the following note. At the desk of an employee with the last name “Sun”:
“‘Sun’ is user name and password!”
I wonder why we use passwords at all.
Oct0ber2026!
That’s why you should never change your password. No one will think to guess @utumn2O23 in 2026.
If the computer is in even a marginally secure place, storing passwords on physical paper is better than what a lot of people do.
Of all the proverbial bullets I’ve been hit with, none had my name on them; they were all addressed “To whom it may concern”. The times my identity has been stolen or my accounts compromised it was because somebody attacked some fairly large entity, like Alphabet or Equifax or Microsoft or Visa. Nobody’s going to walk into my house looking for my passwords. They might walk into my house looking for my television, but that hasn’t happened to this house longer than I’ve been alive.
Yep, there’s a reason 2FA recovery keys are usually printed and stored safely.
With that said, one way to avoid someone compromising service A due to somebody breaking into service B is to have different passwords everywhere, so a Password Manager is more convenient anyway.
Which is why I use a password manager. There are some passwords that I do keep human readable and typeable, like my home wi-fi password, because…enter a password like ghQ953mGh0hY0eo5vgnj;lse%tp[n9a36 into my niece’s Switch Lite when she comes to visit. For that I do the CorrectHorseBatteryStaple thing. But for most passwords for services that aren’t in my physical control I use my PM’s random string generator.
For home Wi-Fi I use a strong password, but that’s because it’s something I input once in a blue moon. For guests I have a guest Wi-Fi with a simpler* (still reasonably secure and random, but shorter and without special characters) password and a QR code for simple use, though they are rate limited and have no access to any other network clients.
I have a nice notepad from a conference on my desk labelled “Passwords”
Woah now what about changing 1 to !
I will take a stanza from a song, use the first letter from each word, switch the S to 5 or $ as an example, and make sure I have two uppercase, two lower, two numbers. and two special characters, 8 minimum, although now it runs about 13.
I hum as I type in my password. All I have to remember is how I typed it out.
Come at me, dictionary cracks. The result is bonkers as fuck, but I loved that stanza. I have passwords I have used for 20+ years.
My coworker who sits next to me recently commented to me that I always hum the same tune when I log into my computer. Then he mentioned I hum a different tune when I log into the proxmox.
My sticky note would be like:
computer - Local H
proxmox - Sonic Youth
mail server - Future of the Left
NAS - Faith No More
Inventory - Slothrust
etc.
Holy $#!7111
Alt joke:
Thanks for the tip! My password is now…
hunter2I feel more secure already. :D******* you say?
The worst part of the left one is the implication they have only two passwords. The “under the keyboard” part at least requires physical access and (hopefully) means its not something stupid or short like “p@ssw0rd”.
The “under the keyboard” part at least requires physical access
That’s fine at home. Not so great in an office, though
I agree, but if I had to choose between someone reusing passwords and someone who kept them under the keyboard I’d probably choose the latter
You can’t fit that many post-it notes under the keyboard though, so if they’re doing the latter they’re probably doing the former
I have yet to see a sticky note password that was anywhere near NIST compliant lol.
NIST compliance is 15 characters. That’s it. No stupid cycling every three months. No stupid special characters.
Somebody finally read the XKCD comic.
Ain’t it 8 characters, and 15 for machine accounts?
I just read it yesterday but maybe it was an older entry
I wonder why passphrases fell out of style? If you remembered a series of random words like you were activating the freaking Winter Soldier, boom, 40+ characters!
Did they ever get into style? I use them, but I don’t know anyone else who does. And some sites make diceware passphrases harder to use by e.g. requiring you to add numbers, special characters or capital letters, or by banning spaces. Or by banning non-ASCII, which makes it harder to use diceware passphrases in other languagess than English.
If we take the EFF wordlist commonly used to generate passphrases, we have 7776 words. If we take ASCII alphanumerics and special characters we have about 92. Assuming we generate a NIST compliant password of 15 characters in length we get 92^15=2.8*10^29 of combinations. To get the same level of security (same number of combinations) using the EFF wordlist we need (log(2.8)+29)/log(7776)=29.45/3.9=7.6 around 8 words. If we assume the words are 7 characters long on average, plus the separators, we get 7*8+6=62 characters long. If we start to also include Unicode characters like other scripts or emojis (something I’ve recommended to others) the required number of words grows even more. I don’t know about you, but I can’t be bothered to type that all out every time, a password manager works for me.
Yeah, that makes a lot of sense. I guess I meant for things where you need to actually memorize a password, like for the password manager.
But yeah for 99% of cases, a backed up KeePass database with randomly generated ridiculous passwords for every little service is fantastic. 👍
my workplace makes us change passwords every 3 months and I don’t respect them so its the same password with the same number at the end -1 because I can’t be bothered. If I get hacked oh no ive dealt damage to a multi billion dollar corporation woe.
Mine also along with multiple new pin codes for our phones every 3 months. Its annoying as hell and makes people just use easier and more memorable passwords rather than sticking with harder ones for longer.
I have a system of using month and year plus a common trailing string. My annoyance is that every year the last number on the year keeps moving.
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 don’t remember them you are not expected to moving from iOS to Android lets say generate new ones for your new device.
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.
yup, and Netflix will use passkey attestation to make sure you can’t share logins with other users
they can already force your to install their app to receive a push notification (cough… google…cough…). if they really want to lock you in they will. passkey or not.
well, if I’ve seen a vendor lockin before, and I’ve seen a couple, they’ll push them with open standards until they’re accepted and normalized.
Then suddenly the big players like Google and Microsoft will block all the open platforms sighting “security” forcing businesses to adopt closed proprietary versions while touting their free and easy too use platforms.
then the monitize it.
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.Admittedly I didn’t read that 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.
It’s a very basic principle, that you don’t create powers that could be abused. That they haven’t been abused yet does not make doing so ok. It like saying it’s ok that my government was given the power to lock people up with no reason or due process because they haven’t used it yet.
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
Please provide a blood sample to verify your Age. Thank you for using Open FaceGoogazonthropic, we love you.
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.
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
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?
Which most people don’t do.
They’ll learn like I did the hard way. Lol
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.
Until they only allow specific AAGUIDs to enroll passkeys that don’t include the one used by KeePassXC (
fdb141b2-5d84-443e-8a35-4698c205a502) or KeePassDX (eaecdef2-1c31-5634-8639-f1cbd9c00a08) because they don’t consider them secure enough.vendor lock-in and potential future corporate enshittification are non-issues.
For now.
In some countries, banks require users use their app on IOS or Google’d Android. You can’t use their services via browser, LineageOS, GrapheneOS
In some countries, banks require users use their app on IOS or Google’d Android. You can’t use their services via browser, LineageOS, GrapheneOS
True. I’m kind of affected by this in GOS, although I found a workaround to bludgeon my banking app into submission.
Still, this is an issue that is already here, and it exists independently of passkeys.
Then you’re screwed anyway
This mentality is so gross. “Well might as well roll over and get pounded in the A by big corpo! what else am I going to do, right? Hehe!”
So what are you gonna do about i
Me personally, I’d get a burner smartphone in a drawer just for banking that is on airplane mode 24/7 except when I need it for banking and use a dumbphone for everything else. Also, I run linux and I have strict control over my router and I have ZERO subscriptions and creditcards. It’s not much but it’s something. Beats blindly rimming apple and alphabet.
Good work. Never capitulate.
That’s not gonna stop them from doing any of these things you’re afraid of it’s just sparing you from it
Fuck off with that defeatist bullshit.
Make them drag you ckicking and screaming. Only morons and cowards walk in lock-step with the corpos
Then don’t use these websites and this is a non issue
Ah, but of course! Why didn’t I think of closing my bank account?
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
Mozilla’s warning is funny. “Don’t use this to reject attestations from unapproved authenticators!” That’s, like, almost the entire purpose to attestation. It tells you an Apple device or a YubiKey or whatever created the credential. What else could you use this information for other than to make life harder for users using certain authenticators?
I did read that part, but like you, I haven’t been able to independently verify it yet.
Passkeys… how to make the public still not understand mutual TLS…
so whats a passkey and how is it different from a password?
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.
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
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).
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.
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…
Because of this discussion (and because I hadn’t looked at passkeys for quite a while), I did some testing…
And passkeys integrate seamlessly into my keepassXC to get backed up with all my regular passwords. So software- instead of device-based passkeys that can be properly transfered, synced or backed up work…
The problem is that tech-minded people that use password managers and think about security and backups are not the primary target group that passkeys should protect from every-day phishing attempts in the first place. And when it’s supposed to protect the common user effectively and conveniently/frictionless but then instantly destroys the effect by advising to set up another login method it makes no sense.
Maybe I should have clarified, you can’t export from Bitwarden into KeePassXC or vice versa. Imagine you have 100 passkeys and you want to switch your passkeys manager. Unless something has changed drastically in the last few months, this was impossible
Are you sure about that?
When I open up the import function in KeePassXC I can pick 1Password(.opvaul), Bitwarden(.json), Proton Pass(.json) and a couple of other file formats.
PS: Oh, wait. That only works for the passwords while passkeys simply get ignored? Okay, that’s dumb.
I have a password manager and hardware token. I see no need to use passkeys.
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.
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
Question: do English native speakers also read “arstechnica” as “arsetechnica”
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.
