My issue with passkeys is the fallback.
For instance, when the biometric fails, you can use a fallback login. That's fine (and good that it exists). But the fallback for me is a pin number. That pin is far less secure than my password or a randomized TOTP number.

How do you handle that for your setup?

Both also have the same potential for abuse, any service could require you use their specific app.

That's not true. TOTP is just a mathematical formula for how you mix a "shared secret/seed" with the current time.

In the authors article, they mention that you could write your own python program to generate the correct rotating numbers.

There is no way Big Tech could force you to use a specific app, because at the end of the day, TOTP is just math. 1+1=2, that could be calculated by you, your cellphone, or me - it doesn't matter.

According to the article, Passkeys, on the other hand include a bunch of metadata. For example, can this passkey be copied or moved to another device.

The article is also very clear that all those fields can be faked except attestation.

And for those at home, attestation is a cryptographically secure way for an application to be certain that the application, operating system, and hardware are not modified to work in a way that the OS provider, application, and hardware vendor expect it to.

This has been abused by google/android to prevent/limit people from installing applications outside of the google play store, its been uses to force people to only use google-approved os' (no cfw, no grapheneos). The same technology is a requirement for windows 11 (TPM).

Now, if FIDO agreed to not include attestation as part of the metadata - this would not be a discussion: everyone would love and use passkey, as you (the user) get to decide how to store/backup and (optionally) share this key.

But that's not what FIDO did, the attestation flag is included in the metadata. And the author speculates that once people accept passkey, Big Tech will turn the screws and then start to force how you store your passkeys.

So, in an apocalyptic future "coming soon", when you try to log onto your bank, you'll be greeted with an error:

"We detected that your passkey is stored in the cloud. Your security is important to us. Please, install your new passkey onto your local device using your manufacturers approved Google Android Operating System and Google Approved passkey application."

There are lots of reasons to like passkeys from a technical/enterprise standpoint, but I do think you're missing the critical issue the article is speaking to: digital sovereignty.

Passkeys, while more secure in the average usecase, shift the balance of control over your access to services. Yes, you can no longer write your password down on a post-it and leak it in a photo—thats's a good property. But trading that at the expense of your freedom to run software as you see fit on hardware you bought and paid for? For many people, myself included, that's not an acceptable tradeoff. There are plenty of tools and systems around passwords that folks can use to make passwords+2FA match or even exceed the security properties of passkeys.

The thing that should chill everyone is the fact that built into the standard is a switch (given to service providers, not users) that locks out the people that do want to have control of their digital infrastructure. Not everyone can or should be expected to run like that, but they should not be blocked from doing so. Similar with the Right to Repair; not everyone can exercise that right on their own, but no one should be prevented from repairing what they bought.

Similary, I do believe it's my neighbor's right to practice a religion of their choosing. So if the government tries to prevent them from doing that, I'm going to go grab my pitchfork, not because I share their religion, but because they should be able to make that choice. Likewise, while I might not want to exert control over how my credentials are backed up, I still reserve the right to do it, and support anyone else's ability to do it.

And to address the slippery slope objection, I have to point out that this is not particularly theoretical. When Big Tech has provided service providers with the opportunity to enforce restrictions on your device, service providers have used it. Widevine DRM, Google Play Protect, etc.. It's why my LineageOS phone can't use banking apps, which is a shame since some features like Zelle payments are specifically a mobile-only feature, and so I cannot use it anymore. I either run my phone to the exact specs and settings that my bank and Google prefer, or I'm denied access to basic banking anywhere but my desktop (and who knows how long until the block my access there, I run Linux afterall).

I do not trust Big Tech with my devices, and passkeys increase their capability to deny anyone who doesn't buy into their ecosystem, and further entrenches those who already are. I for one find that despicable, and an unacceptable tradeoff. There's no reason it has to be this way though, passkeys could have been the best of both worlds. However, they've been compromised with features that serve platforms at the expense of user freedom. It's the kind of disempowerment that happens when you give the reins to power-hungry, profit-seeking corporations.

Maybe you'll prefer more practical criticism then:

https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/

To put it simply, every passkey is locked into a large combination of factors: device + platform (OS) + app + the service being used. It is not trivial and often downright impossible to change any of these factors or to render them agnostic. This makes it complicated or impossible to backup passkeys or make them portable.

It's fine for them to not be portable when they're used on a work phone, running the company mandated OS, authentication app and passkey store, to login into a suite of apps that are also company-approved.

I do need portability and backup as an individual who wants to be able to login into multiple services across multiple apps running on multiple OS on multiple devices. But I can't, because the big tech players (Microsoft/Google/Apple etc.) are actively trying to capture passkeys into their platforms and make it hard to get out in any practical way.

With passwords and TOTP I can run something that will sync them across devices and fill them in into any app in a unified manner (or use copy & paste if all else fails). With passkeys I can't.

There are already dozens of hardware and software passkey vendors. It's honestly amazing how little lock-in there is.

If my passkeys are spread across dozens of vendors I wouldn't call that good, first of all, it's just a headache.

Secondly, just because there's many of them doesn't mean there's no lock-in. Can I get my passkeys out? Can I migrate them freely between any vendors? Can I take backups for myself from all the vendors? Can I restore the backups into each vendor? Can I replace those vendors with a self-hosted solution?

You're not wrong to have that feeling.

Where is the passkey saved? Can I take it out and back it up? Can I use it on another device, running a completely different OS? If I lose this device the passkey is on, what happens?

The answers to most of these is negative.

Yeah good question, and more people should give consideration to account recovery. Are you referring to recovery PINs? There's really a couple aspects to the design:

1. They are single use -- this is really just to make sure users aren't coming to rely on these PINs. It's also a simple fact that passwords that are typed are more likely to be leaked than passwords that are never typed. Single-use do a great job taking advantage of that.

2. They lock after very few attempts and generally have more aggressive anti-hammering/brute force/backoff protection than password/TOTP attempts.

3. They help get new devices registered without already having a passkey.

Securing/backing them up has the same challenges as TOTP secrets management. Storing them in a password manager is what I generally do, but there are a few that warrant keeping offline completely and storing it in a fire-resistant/water-proof enclosure.

The other reliable recovery is just registering several passkeys and keeping one as the recovery credential. I always issue two hardware keys per employee, and we have a pretty lax policy if more are needed or replaced. We also don't allow employees to recover their own accounts. If we're at that situation, we need to know in order to help. And FWIW, I don't use biometrics.

So... Uh... What's a passkey? The article is saying they're pure evil. Everyone here is saying they're good. Everyone knows what they are except for me.

What's the difference between a passkey and a password?

I haven't found this to be the case in practice (IE passkeys are plenty portable). I've successfully used passkeys on multiple browsers, OS's, and apps, all stored using a FOSS password manager (keepass). Any FOSS password manager that is either self-hosted, or syncs, should work just as well with passkeys as it does for regular passwords or TOTP.

https://www.yubico.com/resources/glossary/what-is-a-passkey/

If my passkeys are spread across dozens of vendors

You're picking what vendor you want, not picking unique vendors for every unique passkey.

Can I get my passkeys out? Can I migrate them freely between any vendors? Can I take backups for myself from all the vendors? Can I restore the backups into each vendor? Can I replace those vendors with a self-hosted solution?

It depends. It sounds like you just don't like or want hardware-locked/TPM passkeys. If you generate that type of passkey, then no you can't do much of that. Maybe your major complaint is that some major OS's default to hardware-bound passkeys?

My reference to "vendor" meant to include self-hosted/FOSS solutions.

I think there's somewhat of a conflation of concerns. It sounds like your concern is, I have a credential manager and want to migrate to a new credential manager. I just want it to be simple to migrate my massive number of passwords, right? I need to bulk export + bulk import. EASY. But... what if your first password manager has a bug in the seed generator? Oops, you have to rotate 500 passwords now... there is no easy, off the shelf solution for that. It's basically the same for hardware-bound passkeys. If you generate hardware-bound passkeys, you're not going to simply replicate them to another hardware-bound passkey. The whole purpose of that type of credential, is to make it hardware-bound. There are a lot of meaningful reasons to do that from a security POV.

Now, I think what probably needs to be made clearer, is that if you do want that kind of credential, you shouldn't be using TPM-backed passkeys. You should be purchasing independent hardware (FIDO2 hardware keys) or only make software+transferable passkeys. Personally, I have several hardware keys and I register them with one being a backup. If the vendor posts a vulnerability notice that there's some big gap in their hardware, I will have to go and rotate every passkey. I know that is what I am signing up for, but maybe not a lot of people do.

Sounds like a turbo encabulator.

Also, that website is full of sand traps. Every time I accidentally mouse over something, a huge menu covers up the definition.

FWIW, the article may be a bit outdated. I'm not a FIDO expert by any means, but there have been improvements in the spec to help define how to transfer passkeys (CXF and CXP). The situation should be better than 2024, but if you're using TPM-locked passkeys, you're just in that locked box already.

There are plenty of tools and systems around passwords that folks can use to make passwords+2FA match or even exceed the security properties of passkeys.

Likewise, while I might not want to exert control over how my credentials are backed up, I still reserve the right to do it, and support anyone else’s ability to do it.

Widevine DRM, Google Play Protect, etc…

I do not trust Big Tech with my devices, and passkeys increase their capability to deny anyone who doesn’t buy into their ecosystem

I can only speak for myself, but I hold all of those values you claim. I see no evidence, technical or otherwise, that passkeys are subverting or acting counter to any of these principles. Frankly, it's a baseless claim that passkeys lock people out of their own control/infrastructure. I think people conflate non-transferable, TPM passkeys with passkeys. Just don't use that if you don't want to.

FWIW, passwords were never "yours", they are PSK (Pre-Shared Key) with a service. Maybe you invented the credential, but it's not yours. You have historically enjoyed being able to bulk export credentials, and if that property is important to you, then you should be using transferable passkeys. Passkeys have a well-defined transferable format -- if they are the type that can be exported.

I can only continue repeating that the passkey spec is public and transparent. If the service is not supporting passkeys in a way that you want to use them, then complain to that service. I don't decide that service X doesn't support transferable passkeys, but they should.

DRM and other gate keeping efforts, IMO, are tangential to passkey support. Passkeys are fine, vendor-locking and walled gardens are not.

It sounds like your concern is, I have a credential manager and want to migrate to a new credential manager.

No. My concern is that I want to choose my own credential manager, and I want it to work with any passkey usage out there. And that's impossible.

Which credential manager, and which service is not working with it? Just looking for an example to understand what you're struggling with. I feel like I don't have these problems heh.

You're picking what vendor you want, not picking unique vendors for every unique passkey.

I don't get to pick anything, in fact. Most often you're told "that's how it is, that's where the passkey goes" and there's nothing you can do about it.

It sounds like you just don't like or want hardware-locked/TPM passkeys. If you generate that type of passkey, then no you can't do much of that.

Again, _I_ typically don't get to make that choice, it's being made for me. And that's a problem.

Really there is no way big tech can force me to use their app? Ok so you know how the open standard for TOTP is a six digit code computed from the time and shared secret? Well every student at the university of California and every employee at many companies across the US has to use an Authenticator app called duo which uses a 3 digit code generated by the app at the moment you attempt to log in. How does it do that? No idea it’s closed source. Is it even a formula like the TOTP open standard? Probably not I’d guess duos servers just send a code to both sides when you attempt a login. And would you look at that suddenly we have TOTP that I can’t write myself and I’m forced to use some shitty app.

Now I do recognize the point you’re making but I want to emphasize it’s not about attestation being in the metadata or not. It’s about open standard compliance. As the open standard is written even if you have to have hardware attestation you can build the passkeys yourself (because this is functionality all password managers are quickly starting to have) and frankly having each passkey being device locked is good security practice to protect you from credential stealers and related malware. You’d still be in control and you could still sign in to as many devices as you want. You’d just need to make a new passkey for each one if you don’t wanna sign in the old fashioned way with a password and dual factor and such.

The abuse scenario you describe would require a departure from the open standard. Is this possible? Of course. As I said some companies already do this with TOTP. But I don’t see that as a structural fault of passkeys that TOTP somehow doesn’t have like the article tries to imply. Both only work well for the consumer if the open standard is adhered to.

What do you mean, which. All of them have this problem. You can't force any platform owner to use your favorite credential storage when they decide they don't want to. All of them will tell you "for my services you use my storage, period".

I replied to someone else asking the same thing, but we can avoid this infinite-universe syndrome. Which service is forcing a specific passkey provider, and doesn't offer alternatives? I just need an example to understand because I don't know of any and I have been using passkeys for awhile, so I'd appreciate being informed.

Literally just name a service that forces this. If it's all of them, it should be pretty easy.

OK, Apple. How do I use passkeys created on iOS for accessing Apple services, on a Linux laptop?

I've personally refused to use Apple for decades because of their walled-garden, and it sounds like I'll continue to follow that principle, heh. But that also has nothing to do with Passkeys, and everything to do with whatever Apple is doing. So I guess, you got me there, Apple sucks.

I will say, I am able to deploy FIDO2 for SSO on Apple devices just fine with both Microsoft Intune and Jamf. But that's not really Apple's Passkey vault.

Cheers

No problem until they make every other method more and more difficult. Which is already happening.

I only use passkeys when the alternative is an onerous song and dance.

The article warns that passkeys could be used, assuming they become the only form of logging into platforms, to prevent someone using the wrong operating system to log into those platforms.

Being prevented from using certain applications because you use the wrong OS is nothing new, but there is, from everything i have seen, always a reason to block it, they dont do it for someone elses benefit. A lot of banking apps cannot be used on many android roms; without microg or gapps many android apps wont work (some wont work even with microg); games sometimes use kernel-level anticheat that forces players to use windows; people solved this issue by just not using those apps

Why would a significant portion of used websites/applications that require accounts stop allowing passwords or authenticator apps, relying on this open standard, force certain options to be used for the standard and ensure that the user isnt on an operating system they have no reason to care about. There are already methods to prevent people from using a certain OS, they could just not rely on an open standard

So in order to log into most websites, you need your username/email address and a password.

You can save your username/password in your web browser or in the cloud.

Sometimes people get lazy and reuse passwords, sometimes people forget their passwords.

Passkey is a replacement for usernames/passwords. It does require that the passkey is saved somewhere, often on your device (in the cloud is possible, but non-standard).

When you "create" a passkey, this passkey is used only at a single place. For example, you'd have a passkey for your bank, another one for your email, another one for Lemmy. You have no say in the matter, that's just how it works.

When you log into a website that has passkey enabled, your passkey/password manager pops up, you click on the passkey and that's it. There is no email address, there is no password, no MFA.

edit: oh, you also asked about the difference between passwords.

It's all about improved security.

You go to certain websites, and they'll only allow a-zA-Z0-9, others require a minimum length of 8 characters, needs 3 symbols (except ! for whatever reason ;)

Then you have no idea how the website is storing your password. Are they encrypting it? Did they do it correctly?

If you look at the number of "breached/leaked" passwords on the internet, it's because it's hard to securely store passwords.

Passkey solves all this. Websites are just given "a public key" and it can be "just stored", no special treatment necessary.

FWIW, passwords were never "yours", they are PSK (Pre-Shared Key) with a service. Maybe you invented the credential, but it's not yours. You have historically enjoyed being able to bulk export credentials, and if that property is important to you, then you should be using transferable passkeys. Passkeys have a well-defined transferable format -- if they are the type that can be exported.

This is the equivalent of Sony arguing that you never owned any games, you owned a license. Congrats. You’re the best kind of correct - technically correct.

There is no flag on a password that determines if it is transferable. There is no amount of “if you don’t like it, don’t use it” that will work out in your favor if you’re not in the majority. If you give corporations the power to limit consumption while increasing prices, they will eventually use it. Especially if they provide a product you can’t get anywhere else (and this is their goal for every product - even if they have to buy other companies to do it - even if they have to collude to offer the same service). It’s the foundation of our entire economic system.

I see no evidence, technical or otherwise, that passkeys are subverting or acting counter to any of these principles. Frankly, it's a baseless claim that passkeys lock people out of their own control/infrastructure.

The evidence is in the fact that the passkey standard provides the means to deny service to anyone whose passkeys do not match the service provider's preferences. This is a non-issue with passwords, since there's no way for a provider to tell whether or not, for example, a password is simply remembered, stored in your password manager, backed up, shared, etc.. The threat model of the user can inform what choices they make there. The platform may require certain things of the password, like length requirments or another factor, but it ends there.

You're correct in that the standard supports passkeys with similar data sovereignty properties; however, the standard includes controls that allow service providers to dictate that those properties be configured to the provider's preferences, not the user's.

Just don't use [locked down passkeys] if you don't want to.

It would all be well and good if that were actually entirely my choice, but it's not. The standard specifically includes a trump card for the service provider in the form of remote attestation. You seem to think that's tangential, but I reject that. It's kinda the whole point.

Authenticating based on a shared secret is an interface with a special property: there's no way for a service provider to know how you remember a secret. That guarantee is extremely important. Service providers accepting password based authentication are guaranteed to not be able to enforce requirements on how you remember your password.

The Passkey standard removes that critical protection by explicitly supporting remote attestation in the standard. It does not matter that the standard is public if it does not preserve that guarantee.

Passkeys are fine, vendor-locking and walled gardens are not.

If you're not a fan of walled gardens, I would recommend against giving corporations the mortar, bricks, gates, and locks with which they use to build them. Maybe they won't use them in ways you don't like, but you'll never have a guarantee that they won't.

This is the equivalent of Sony arguing that you never owned any games

It's far from that and bad analogies pollute otherwise very simple conversations. If you want a more apt analogy, this "debate" is shaping up closer to LED vs incandescent bulbs.

It's easy to say passwords are sufficient when you're one person practicing good op-sec. It's not when you're supporting thousands of people of varying technical proficiency, thousands of machines, thousands of services, and thousands of bad-actors. It was an even simpler time when 4 digit PINs were "sufficient", but the world you and I live in is more complicated. Certain passkeys are transferable, so you're not even losing out on that capability. Curmudgeon arguments aren't convincing. Passkeys aren't "giving power away". Using passkeys doesn't mean your giving up freedom. Passkeys have no bearing on the "economic system" and inflation. As far as the IT ecosystem is concerned, we've never lived in a more open and capable time. There are so many alternatives to every service (that isn't tightly coupled to copyright). Of course companies are trying to offer unique products people can't get anywhere else. None of this has to do with passkeys.

This is still fuzzy. What would this look like in BASIC?

IMO you're reading way too much into the value proposition of passwords. Services can "deny service" for arbitrary reasons already with zero consequences, but your idea is that they will ban based on... passkeys? You've got people banned from youtube for arbitrary comments. You've got MS locking out non-profits for arbitrary reasons. But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I'm not buying what you're selling.

You seem to think that’s tangential, but I reject that. It’s kinda the whole point.

I didn't say it was tangential. Attestation is for very specific purpose. Non-attested credentials are not sufficient for government and corporate security. I cannot allow BYO hardware to authenticate my users on my services. I highly doubt any public service would require attested passkeys. I doubt passwords will stop being allowed, almost ever, so you probably have nothing to fear. Maybe you can throw that comment back in my face in 20+ years, heh.

Here's another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. Sign-in prompts on recent devices, email codes, etc. are all proprietary. None of these companies killed passwords despite having implemented the tools to do exactly that with vendor lock-in. All the evidence is the opposite. This is one of the first times we're even getting an open standard authentication, the exact opposite of "walled garden".

Authenticating based on a shared secret is an interface with a special property: there’s no way for a service provider to know how you remember a secret.

The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.

I think we've probably hashed out enough of the sides of the argument. Good luck to you.

As the article states, they're an extremely malicious solution to a problem that has better, simpler, and easier to understand solutions.

It's also a very good solution to the “problem” of users being able to do things our corporate overlords don't want us to do.

In short, they're even worse malware than the ones they're sold as protecting us from.

Enshittification manifest.

Passkeys mean a spread of enshittification to ever more areas of life. Specifically, they

• force me to use an extra OS on an extra device and keep it around just to use a site with passkeys.
• add insecurity and inconvenience. I neither can backup the passkeys nor use them on another device. (That's not implemented on Windows.) This user experience is laughable in 2026. The passkeys are forever locked on the device where I created them. I am forever chained to exactly one device. If it breaks down, my life ends because our lives depend on digital technology.
• take away control from me and force me to trust third parties. I have to trust the hardware, the OS, the proprietary software, which makes me feel very uncomfortable as someone used to use Free software. Security by obscurity was always a bad idea.
• deny me anonymity and control over my accounts. I can have only one account per domain.
• are a black box with no user interface. With passwords I know exactly what account name and password I enter at which site. With passkeys I get asked for a PIN. That is all. There is no indication what exactly I authorize. This is a lot like clicking links in emails and giving your banking details to everyone who asks.

The recommendation “do not use them” is cute. They are forced on people. I can't choose.

some of this is disingenuous. For example you’re supposed to make multiple passkeys for your devices so that you can still Access your Accounts even if you lose your Main device (Ofc its still shitty because this forces you into the cloud if you only have 1). Also thats why the passkeys being bound to their „birthplace“ is Not really more of an issue than the others. Also im Not sure where they are forced? In fact i wish it would be more supported in certain apps

Have you ever used bank software, or some government services site? It is often really hard to not get the idea that it was designed and run by idiots. As someone who's worked as a software developer most of my life, it is not difficult for me to believe it, either.

For example you’re supposed to make multiple passkeys for your devices
How do I do this? Can you link to a guide?

Also im Not sure where they are forced?
The big transition is underway. Switch to passkeys or you are out.

Website supports passkeys. Browser supports passkeys. Extension supports passkeys.

Then why does it keep asking me to "insert my security key"? Why doesn't it work?

Passkeys are bullshit.

But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I'm not buying what you're selling.

Because you appear to be misunderstand what I'm saying. Be careful to not put words in my mouth. I said nothing regarding bans.

I am, however, arguing that a service provider can reject your passkey if they dont like how you manage it, (e.g make it copiable). To access that service using a passkey, you'll have to accept storing your credential on their terms.

And to be clear, I'm in no way blind to the issues with passwords. We've had to tack on a bunch of extras to have password based security keep up, like TOTP, password hashing, recovery methods, phishing resistant tokens, security questions, and so on. I'm not arguing that passwords are perfect; I'm arguing that they preserve the users ultimate control over the credential. I'm totally open and hopeful for improvements to authentication as long as they similarly preserve the user's freedom to manage their credentials as they see fit.

And this may be where the difference in our values shows, since it appears that you view the user's freedom as more of a problem than a boon:

The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.

I'm sorry you've had to deal with that, but I simply don't think some users making mistakes justifies allowing a service provider to remove a critical freedom from the user. I dont believe that improved UX and security has to come at the cost of user freedom, but that's what passkeys explicitly allow for by design. I fundamentally disagree with that.

I didn't say [attestation] was tangential. Attestation is for very specific purpose.

Fair enough, I tend to thow it in the same category as "DRM and other gate-keeping technologies" which you did call "tangential." At the end of the day, for the purposes of my argument, they are the same: a service wishes to exert control over how a client runs, and I object to such limitions broadly speaking. The computers I own work for me, not the service. (Of course this changes in enterprises that own their own clients, like the workstations used by their workforce. But even in those situations, however, I would argue that there are generally more effective measures than remote attestation. But I digress...)

I highly doubt any public service would require attested passkeys.

Ah, but how can you be sure? You're missing the guarentee that they can't flip the script on you. The standard allows them to start forcing users to rotate their passwords and passkeys for ones that require attestation of their preferred settings. Maybe it's unlikely, but "unlikely" is still a massive downgrade from "impossible." IMO, it's unacceptable.

Here's another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. ...

Just because a standard is open does not mean it isn't rigged in the favor of closed platforms. This is especially the case with passkeys, where platforms use them to further entrench you into their ecosystem, often under the guise of "look how good the UX is!" For example, MacOS really, really wants you to tie your passkeys to their keychain, so that they can control how it's backed up, transferred, and stored. Remote attestation only makes this worse, opening the possibility that a service provider can enforce that you have to use MacOS's keychain. Sounds like a walled garden to me.

It’s interesting to say more often websites are ok with that length. I do know that some websites truncate passwords so a long 128 character password may end up being a 16 character password and it all still works despite the password being that long.

Apologies if I miss-stated your point and conflated service's other arbitrary decisions with what you're suggesting may happen with passkeys.

Maybe I have one follow-up question, there are a number of websites that just don't use passwords at all. It's always one-time codes sent to emails. Where does this fall on your freedom spectrum?

Do you have similar arguments about HTTP 3? QUIC? Web RTC? There's so many protocols that could be used in a way to lock in users. Just because it has some bits in the schema, doesn't really mean much. Particularly when it's actually supplying a very real need in other contexts. Nobody wants 30 versions of passkey-alt protocols.

Cheers

That's why I always click the eye to see it if possible, and log in on another device with the password manager after changing/creating a password. I've only had that happen once or twice though.

Indeed. Every device should get a passkey. Its like client certs where you can lose a device and just remove that passkey from your account. Also, you /can/ store passkeys in pure software. Bitwarden can store passkeys for example. Lots of options for FIDO keys too. I have never heard a non technical person give me a secure password strategy. That is 100% of nontechnical people I have asked use bad password schemes. Passkeys at least enforce a truly randomly generated key.

They still suck at usability but it is an attempt to solve a real problem. Basically the only thing standing between 99% of people and having all their accounts compromised is service password attempt rate limiting.

Imagine instead of inventing and storing passwords in your head and typing them in each device. With passkeys each device generates a real, cryptographically strong password for each site and stores it in a secured part of the device. Nothing to memorize.

Sites must now to let you have many passwords so you can have many devices without needing to sync between devices like a password manager might do.

No one can guess your password and it is never reused because they are machine generated. They are protected on device by the security of your device (typically behind a pin) so if you trust your OS, it is safe (which, in effect is the same as passwords you type).

Unfortunately, the experience still sucks and shitty companies might use them to further lock people in if they end up with all their passkeys on one iphone, for example.

Zero trust is the end station, if you allow organizations to treat your personal devices as being theirs. Organizations that could actually benefit from the increased security (which isn't Twitter, except for some high-profile individuals, maybe), should provide the user with resources to do so, at their expense (issuing a dedicated TOTP device for example).

But what tends to happen instead, is enshittification of service, while offloading it onto the client. A similar trend can be observed with car parking: where operators remove parking meters, and require the customer to use their device and data plan, to make a payment to the operator...

We've been on this trajectory for quite a while now: from Outlook enforcing IT-policies of email administrators (dictating screen locking requirements as device administration app), to SMS-based 2FA requiring one to have a mobile phone number and tying all to this tamper-resistant identifier. So why not a black box snitch, paid for by the client, further restrict their freedom for "security"?

It seems perfectly in line, and I think this article draws all the right parallels.

means to deny service to anyone whose passkeys do not match the service provider’s preferences. This is a non-issue with passwords, since there’s no way for a provider to tell whe

Yes it is. I have had to work with many companies that set password specifications, and sometimes they prevented secure passwords. My bank maxed out at 11 characters for many years!

You dont own the specification for a password, the service provider does. I always wanted to use deterministic password generation (i.e. hash(servicename + memorable password), but never could because every provider has different "password rules" about different character types, etc.

Passkeys can be transferrable and syncable ( see keepassx, bitwarden, and relatives). But ideally, eventually, you never sync them because every time you log into a service with a new device, that device gets its own passkey. No need to sync them and you can revoke a devices access if it is lost or stolen without effecting any other device. They are closer to client certs than passwords in that respect.

I'm not familiar with any of these limitations that you described. Those might be limitations of the specific credentials manager(s) that you're using. You might want to try a different one.

finally people are waking up to this garbage.

10 PRINT "So in order to log into most websites, you need your username/email address and a password."
20 PRINT ""
30 PRINT "You can save your username/password in your web browser or in the cloud."
40 PRINT ""
50 PRINT "Sometimes people get lazy and reuse passwords, sometimes people forget their passwords."
60 PRINT ""
70 PRINT "Passkey is a replacement for usernames/passwords. It does require that the passkey is saved somewhere, often on your device (in the cloud is possible, but non-standard)."
80 PRINT ""
90 PRINT "When you "; CHR$(34); "create"; CHR$(34); " a passkey, this passkey is used only at a single place. For example, you"; CHR$(39); "d have a passkey for your bank, another one for your email, another one for Lemmy. You have no say in the matter, that"; CHR$(39); "s just how it works."
100 PRINT ""
110 PRINT "When you log into a website that has passkey enabled, your passkey/password manager pops up, you click on the passkey and that"; CHR$(39); "s it. There is no email address, there is no password, no MFA."
120 PRINT ""
130 PRINT "edit: oh, you also asked about the difference between passwords."
140 PRINT ""
150 PRINT "It"; CHR$(39); "s all about improved security."
160 PRINT ""
170 PRINT "You go to certain websites, and they"; CHR$(39); "ll only allow a-zA-Z0-9, others require a minimum length of 8 characters, needs 3 symbols (except ! for whatever reason ;)"
180 PRINT ""
190 PRINT "Then you have no idea how the website is storing your password. Are they encrypting it? Did they do it correctly?"
200 PRINT ""
210 PRINT "If you look at the number of "; CHR$(34); "breached/leaked"; CHR$(34); " passwords on the internet, it"; CHR$(39); "s because it"; CHR$(39); "s hard to securely store passwords."
220 PRINT ""
230 PRINT "Passkey solves all this. Websites are just given "; CHR$(34); "a public key"; CHR$(34); " and it can be "; CHR$(34); "just stored"; CHR$(34); ", no special treatment necessary."