Andrew Eikum has updated his blog post on passkeys. The revised title, Passkeys are incompatible with open-source software (was: "Passkey marketing is lying to you"), says it all.
Update: After reading more of the spec authors’ comments on open-source Passkey implementations, I cannot support this tech. In addition to what I covered at the bottom of this blog post, I found more instances where the spec authors have expressed positions that are incompatible with open-source software and user freedom:
When required, the authenticator must perform user verification (PIN, biometric, or some other unlock mechanism). If this is not possible, the authenticator should not handle the request.
This implementation is not spec compliant and has the potential to be blocked by relying parties.
Then you should require its use when passkeys are enabled … [You may be blocked because] you have a passkey provider that is known to not be spec compliant.
I suspect we’ll see [biometrics] required by regulation in some geo-regions.
I’ll leave the rest of the blog post as it was below, but I no longer think Passkeys are an acceptable technology. The spec authors’ statements, refusal to have a public discussion about the issues, and Passkey’s marketing, have all shown this tech is intended to support lock-in to proprietary software. While open source implementations are allowed for now, attestation provides a backdoor to lock the protocol down only to blessed implementations.
So long as the Passkey spec provides the attestation anti-feature, Passkeys are not an acceptable authentication mechanism. As a result, I’ve deleted the Passkeys I set up below in order to avoid increasing their adoption statistics.
Passkeys are cryptographic credentials marketed as operating through locally executed programs to provide authentication for remote systems and services. They are sometimes additionally tied to biometrics or hardware tokens. The jury is still out as to whether they actually improve security, or will merely continue as another vehicle for vendor lock-in. It's looking more like the latter.
Previously:
(2024) Why Passwords Still Rock
« Get Ready for Plastic Blood | Scammers Will Try to Trick You Into Filling Out Google Forms. Don’t Fall for It »
Related Stories
Software Engineer Nikita Prokopov delves into how programs have changed over recent years from doing our bidding to working against us, controlling us. This adverse change has been ushered in through requiring accounts, update processes, notifications, and on-boarding procedures.
This got so bad that when a program doesn't ask you to create an account, it feels refreshing.
"Okay, but accounts are still needed to sync stuff between machines."
Wrong. Syncthing is a secure, multi-machine distributed app and yet doesn't need an account.
"Okay, but you still need an account if you pay for a subscription?"
Mullvad VPN accepts payments and yet didn't ask me for my email.
These new, malevolent programs fight for attention rather than getting the job done while otherwise staying out of the way. Not only do they prioritize "engagement" over its opposite, "usability", they also tend to push (hostile) agendas along the way.
Previously:
(2025) What Happened to Running What You Wanted on Your Own Machine?
(2025) Passkeys Are Incompatible With Open-Source Software
(2024) Achieving Software Freedom in the Age of Platform Decay
(2024) Bruce Perens Solicits Comments on First Draft of a Post-Open License
A lot of security myths have acquired lives of their own and taken as facts. Dr. Andy Farnell over at the Cyber Show's blog has posted an item about where passwords can still fit in as a part of general authentication despite what fleets of salesmen selling authentication gimmicks tell us.
Security models: password or tracker?
Indeed people do not discriminate two vastly different security models that should really be obvious with a moments thought. The question is, "who is the security for?"
Security schemes that ask that you carry around a device which is connected permanently to a network and uses a mechanism that is entirely opaque to you is a different kind of security. It is more than a mere access control. It is not security for you.
It may pass for "something you have" but also has a function to act as a location or close proximity biometric remote sensor for an observer elsewhere. It's a tracking device.
[...] Partly it's because we've been using passwords wrong for about the past 40 years. The new NIST document partially puts that right. It's also because there's a massive "security industry" that sells things - and you can't sell people the ability to think up a new password in their own head. Where's the profit in that?
Instead they'll tell you that you need a fangled security system of gadgets and retina scans, and that you're too stupid to be trusted with your own security. They are wrong. In most cases passwords are just fine if not better than alternatives, and in this post we're going to explain why.
Thus another theme of this essay is personal responsibility and the crux of the argument is that all security solutions which are not passwords solve problems that are not yours.
Like self-service checkouts at the supermarket that make customers into employees, they are a way of passing blame, liability, and work onto you in order to solve someone elses security problem. As Prof. Ross Anderson bluntly puts it;
"If Alice guards a system but Bob pays the cost of failure, you can expect trouble."
Cybersecurity has become more harmful than helpful in many cases and biometrics are more of a user name than a password despite the constant misuse as the latter.
Previously:
(2024) NIST Proposes Barring Some of the Most Nonsensical Password Rules
(2024) VISA and Biometric Authentication
(2023) A Fifth of Passwords Used by Federal Agency Cracked in Security Audit
(2020) Here's Yet Another Reason Why You Really Should Start Using Better Passwords
(Score: -1, Flamebait) by aafcac on Thursday September 04, @05:46PM (9 children)
I think that it's way past time we just admitted that a lot of the questions about what is and isn't open source are bullshit and have less to do with the source than other things. Which is fine, but it's idiotic to suggest that the BSD and MIT licenses are less open than GPL when GPL comes with more restrictions than BSD and MIT licenses do. These are important considerations, they just have nothing to do with whether or not you've got access to the source to use and modify as an end user.
It's the same sort of a thing here, any time that you need to log in to somebody else's computer to do something, you're going to have the ability to control how you work with it. That's just the nature of authentication. Whether it's a password, passkey, 2FA is somewhat lesser of importance than the fact that you have to log in to begin with. Apart from requiring the use of phone numbers, which is legitimately evil and needs to stop, a passkey versus a password isn't necessarily that big of a deal depending upon how it's implemented. If it requires a code that comes to a phone number, that's a problem. If it requires a code that's in something like authy, a FIDO key or even email, that's probably not that big of a deal. But, given the way in which people typically treat passwords, I'm not sure that it's viable to continue to use passwords as such an important portion of the process for logging in and identifying yourself.
(Score: -1, Troll) by Anonymous Coward on Thursday September 04, @06:40PM (1 child)
Congratulations on your long ignoratio elenchi [google.com].
(Score: 2, Informative) by aafcac on Thursday September 04, @07:46PM
Isn't that exactly what you've done there? I've made a fair point, and apparently, you're not able to actually refute it.
(Score: 5, Insightful) by ntc on Thursday September 04, @07:52PM (6 children)
The GPL is a Free (as in freedom) license, not an Open Source license. It does meet the Open Source definition, but you could think of that as a side-effect, not the goal.
The aim of the GPL is to maximise the freedom of the USERS.
I argue that it is MORE free than BST and MIT. Consider freedom in everyday life, how do we maximise freedom? We do it, in part, by encoding RESTRICTIONS into law. For example, it is illegal to murder people.
The GPL's "restrictions" are equivalent to laws against coercion.
(Score: 2, Interesting) by aafcac on Thursday September 04, @10:17PM (5 children)
Except, even by that measure it doesn't really. The penalties are extremely weak and require that somebody with rights file suit. Meanwhile you've got strange situations like the period where ZFS wasn't available for Linux because the GPL doesn't play well with the CDDL, and for years the FreeBSD kernel source shipped with an optional math emulator that couldn't be compiled in by default due to the viral nature of GPL. It wasn't a particularly big deal as FreeBSD has always provided the source, but because of the way that the GPL is written, the users were in a worse situation due to the use of the GPL than if the developers had chosen a proper license.
There was a concern decades ago, but in practice, there's little actual basis for the belief that the GPL does much that other open source licenses don't do. At the end of the day, you still have to identify the infringement and potentially file suit when there are violations and some of the most wide spread code in existence is BSD licensed.
It's sort of the same thing here. It's an absurd basis for the view that obscures that actually issue, being when the passwordless entry uses things that aren't open or uses them in a way to track or trick the users.
(Score: 3, Insightful) by Thexalon on Friday September 05, @01:09AM (3 children)
The reason the GPL is the way it is has to do with creating a risk to private companies trying to do to GPL'd software what Apple did to BSD, namely Embrace, Extend, and mostly Extinguish. The whole point of the GPL is that it treats the knowledge of how to do things with a computer as a commons, and if you want to use the commons you have to give back to it.
This has largely succeeded in preventing a repeat of the Unix Wars in the world of Linux: While there can be lots of variations of Linux out there, if IBM wants to add some feature to their Linux kernel that's not in Canonical's, they can't, because the GPL forces them to contribute whatever they created back upstream. And they can't get out of that by declaring their version to be a fork, either. Well done.
Sure, somebody needs to be motivated to bring the lawsuit when somebody tries this, but conveniently there are foundations and such that that's what they do.
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 1) by shrewdsheep on Friday September 05, @02:20PM
There is one aspect often not properly discussed in GPL vs. BSD: they are not mutually exclusive. Within larger projects such as distributions, mixing and matching is possible.
I consider it crucial that the Linux kernel is GPLed for reasons you mentioned and I believe the availability of Linux code has also helped the BSDs if only by allowing to inspect the code. For other projects, I consider a BSD license not to be a problem or even preferable as it might allow smaller companies to retain a stronger grip on their IP which would otherwise not have been able to establish a business plan.
A somewhat orthogonal aspect which has never been tested in court is that licenses can be revoked by the copyright holder meaning that even published open software versions might become unavailable. There has now been a ~ 50 year period where revocations have not been performed (AFAIK) and that might establish de facto law. I guess we will find out at some point.
In conclusion: all licenses are uncertain and we have to be fast at the keyboards to recreate stuff we might have lost through license shenanigans.
(Score: 2) by jasassin on Saturday September 13, @08:55AM (1 child)
I need a clarification on this. I'm under the impression that if IBM wants to modify the source of any GPL code and use it for themselves, they don't have to release any modified source (e.g. if they don't distribute the binaries). It's just if they want to sell the modifications? I'm not sure how this works. I think as long as the modified code isn't in a product they're selling. Maybe some backend things? Seriously, I do not know. I would think there are lots of companies that have modified the kernel and use their modifications without giving anything back.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 3, Informative) by Thexalon on Saturday September 13, @02:27PM
For GPL v2, they have to give back whatever they did if they distribute the resulting software to anybody else. So, for instance, if they run it on their own servers that's their business, but if they sell cloud instances running it then they have to distribute that code under the GPL v2 at no extra charge.
My understanding is that GPL v3 targets those that take GPL'd code, modify it, and sell the results of the modification as a service, so that could hit IBM in those cases.
What's perfectly OK, though, is to take LGPL code, build something new (e.g. an application) on top of it, and sell that new thing.
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 2) by sjames on Saturday September 06, @08:30PM
The GPL is why for a number of years the WRT54 was THE WiFi access point to get. Linksys used GPL code in their firmware and was forced to open up the whole thing to stay out of court. GPL has fueled a similar openness in 3D printers, though the companies that used the GPL Marlin firmware didn't have to be coerced to do the right thing.
It even affects products that avoid the GPL so they can be locked down. For example, I just watched a video where a Bambu Carbon X1 printer was modded with GPL firmware and a controller board designed to be used with GPL firmware in order to break it free or it's dependence on the "Bambu cloud" after Bambu "altered the deal" to require it.
The insistence on openness among early adopters in the 3D printing space combined with the GPL are why 3D printers are so much more open than regular 2D printers. Dremel TRIED the whole proprietary supplies thing and so their 3D printer aspirations went down in flames.
The ZFS situation was a pain, but in fact, many people use ZFS with Linux because nothing in either licence forbids the end user from combining the two.
(Score: 4, Interesting) by kolie on Thursday September 04, @05:54PM (11 children)
idk what the problem with passkeys are. its essentially a key pair - and integration with the os and other ecosystem members to query the keystore/signing pair. The whole point of hello/pin/whatever verification is to authenticate the user at the OS level, which controls the keystore, and then feeds whatever auth pieces are needed to the other side. No pin unlock? Windows won't let you validate with the keypair. Anything following the spec can act as a keystore/auth etc. I use bitwarden and it supports this, a bunch of my friends use keepass and it has plugins that do this to.
I'm not advocating for or against them. The title of this article appears to be a lot of fud so I didn't dig into it more then that.
(Score: 3, Interesting) by aafcac on Thursday September 04, @06:00PM (1 child)
That's what I'm getting out of it. If it's a piece of software that's otherwise opensource by whatever definition we're using, then there's no inherent reason why passkeys are a problem, just don't tie them into proprietary things and it should be fine. The biggest issue I see is requiring that part of the process requires something like a cellphone that's not easily changed and can be tracked back to a user.
(Score: 2) by kolie on Thursday September 04, @11:47PM
Yea and I think the point is here that - IF you choose to have your passkey store on the phone - then yes - it's tied to that device and if the passkey app on the phone use bio or whatever to unlock, your phone, because it has the passkey store on it is necessary. It seems to me that could be literally anywhere else which is a good thing ... It would be the users choice to have the phone do this work.
I suppose for the novice having windows store the keys and manage them behind your bitlocker key and your windows auth is convenient and where most people seem to find issue with the design. I guess that might be a valid concern if that was a requirement, but it seems like anyone can implement the passkey store anyway they want, and just interface with the standard. It actually seems very flexible and open - and yes there are some proprietary players that have made this really integrated and easy into apple/android/windows.
(Score: 5, Interesting) by canopic jug on Thursday September 04, @06:06PM (4 children)
idk what the problem with passkeys are. its essentially a key pair [...]
Passkeys, as pushed by big tech, are as you describe — a key pair — but wrapped inside a proprietary "app". The standard complaints about proprietary software apply then.
Passkeys are different than password managers. And if you leave out the proprietary parts, the key pairs alone or even certificates alone are probably a good idea for authentication in most use-cases. However, these key pairs are wrapped in proprietary cruft. While such passkeys are being marketed as for "security" they are really used to advance vendor lock-in and, I expect, surveillance and tracking.
Money is not free speech. Elections should not be auctions.
(Score: 5, Insightful) by VLM on Thursday September 04, @06:29PM (3 children)
Essentially, the protocol is the password manager, so to speak. You can't use the passkey without it. "Wisely" nobody trusts someone else's password manager so they're not even trying to permit FOSS they're going right for non-FOSS and trusted locked-down appliances all the way.
(Score: 2, Insightful) by Anonymous Coward on Thursday September 04, @06:40PM (1 child)
So the solution here would be open standards for the protocols and keys. Then they could be implemented in any number of ways from fully copyleft, to non-reciprocal OSS, to fully proprietary.
However, the whole point of the kind of pass keys being pushed by Google and others is the lock-in. Thus FOSS options and even FOSS operating systems will be left out on purpose.
(Score: 2) by kolie on Thursday September 04, @11:47PM
The entire thing is open. I use pass keys on full FOSS. Vault warden supports it, I got a FF extension which talks to pass key web stuff.
(Score: 4, Insightful) by aafcac on Thursday September 04, @07:57PM
I can't entirely blame them for not trusting other organizations. MS has its own authenticator that looks a lot like authy or Google authenticator, but it's somehow incompatible with other options. I'm not really sure what the point of that really is, at work they had to hand out a bunch of yubikeys for people who couldn't or wouldn't install MS' authenticator onto their personal devices just to get into software that we don't really use at work that often.
It would be a lot easier just to standardize around some sort of public key/private key pair of whatever the most widely regarded to be secure type is and just use that for handling the session key exchanges. Of course, that would depend upon them being legally responsible for breaches that result from their variant passwordless login not working properly, so we're stuck with the status quo.
I do personally like the idea behind passwordless logins, it's a shame that basically everything gets corrupted eventually to try to lock people in or more accurately track them.
(Score: 5, Insightful) by VLM on Thursday September 04, @06:26PM (2 children)
Correct but incomplete. Its also like a password manager software program. Written by people you can't trust but they insist you should totally trust their non-FOSS programs solely because they say so.
True that every piece of hardware and software has backdoors for every criminal and corporation and government. However there is kind of a trust anchor wiht legacy passwords that in the end, my bank password is in my mind and they haven't perfected fMRI scanners well enough to steal it casually on the street. Keypass takes that away, like using a password manager written by someone you don't trust (or should not) to hold your ssh authorized_keys and your ssh key files "for you".
Keypass is also a giant centrally controlled password manager, where as usual everyone has root on it but you. Nobody likes biometrics and you'll have FOSS developers making and shipping "password protected" keystores by using the string "1234" instead of all this fancy biometrics PITA that nobody likes. Also you'll have governments/corporations sideloading in backdoors where the system skips the biometrics entirely. So if you allow "any" keypass provider then you void all your PCI/DSS / HIPPA / NSA-stuff because none of those allow a four digit password and its impossible to stop a FOSS provider from existing that "locks" your keys behind the password "1234".
Meanwhile on the other side the attackers only need to crack a non-FOSS system once to get ALL your digital access to everything all at once. So the motivation is high. Luckily corporations and governments have never shipped closed source software that has security holes (sarcasm)
Fundamentally the problem comes from everyone other than you having root on all hardware, firmware, and software so they've been stealing passwords stored in your brain. So in the spirit standards are so good that the world always needs new standards, they came up with a new piece of hardware, firmware, and software that they pinky-swear fingers-crossed-behind-their-back will totally not have a bunch of crooks with root on it. For five minutes it'll probably work, too, then end up even more brokens and overcomplicated than it was before passkeys.
Its just an awful design.
(Score: 2) by kolie on Friday September 05, @12:24AM
https://passkeys.dev/docs/reference/specs/ [passkeys.dev]
(Score: 2) by darkfeline on Tuesday September 23, @01:45AM
> Its also like a password manager software program. Written by people you can't trust but they insist you should totally trust their non-FOSS programs solely because they say so.
No? What is this outright misinformation FUD bullshit?
Putting aside the disclaimer that "passkey" is not a standardized term or concept, the multiple things that "passkey" generally refers to are open protocol specifications (FIDO2, WebAuthn), which can and are independently implemented, and for which already exist multiple FOSS implementations. The protocol is fundamentally just a standard scheme (think JSON schema) for passing public key signed challenges, with metadata like which website is requesting, what the key type is, etc.
Presumably, your fevered rant stems from the misconception that because there also exist proprietary client implementations, the entire thing is some Illuminati conspiracy by the dark government or some such.
Join the SDF Public Access UNIX System today!
(Score: 2) by darkfeline on Tuesday September 23, @01:49AM
The complaint from TFA is that the specification says you should accurately report information like "is this key transferable to a different device" and the spec authors have commented on FOSS implementations that falsify this information, that these implementations are not compliant with the spec and some websites (or more likely internal corp IT systems) may try to ban them.
So it's a bunch of noise about nothing,
Join the SDF Public Access UNIX System today!
(Score: 5, Interesting) by VLM on Thursday September 04, @06:05PM
Its a strange mixture of accurate and FUD.
The problem with this stuff is its VERY OLD like almost as old as IPv6, which is some truly ancient stuff (I remember setting up A6 records before Y2K LOL like our RFCs were distributed on clay tablets back then). OpenSSH added FIDO key support around 2020 and I played with a FIDO compatible usb key and SSH (IIRC you specify a weird name of crypto type to ssh-keygen and it makes a "special" key that only works with your FIDO key). I have long since lost the FIDO key although it all worked fine under Ubuntu around 3, 4 years ago. It was kinda fun. This is relevant because passkeys are mostly marketing bullshit piled on top of an architecture identical to that. And people were doing SSH with FIDO keys and openssh under Ubuntu like five years ago, but passkeys are eternally advertised as something new that'll never work. It may never work LOL but not for technical or linux/ubuntu type reasons.
I suppose this scheme from 2020 would get blacklisted in 2025 because the FIDO key did no biometrics other than a touch sensor. You have to touch it with a finger to get it to do its thing, presumably so it would be harder to MITM because you don't usually touch it so you'd know if you're being MITM'd. It provided minimal physical security, if you steal the device you have full access, kind of like if I had a laptop full of ssh keys included in numerous authorized_key files. It's somewhat safer as you can attach it to your physical keyring and people presumably keep better track of their car/house keys than rando digital devices.
Its kinda FUDdy as surely chrome on linux works with FIDO keys for AWS although I have not tried it and can't really do so right now. I used to have to use a FIDO key to access a client's somewhat limited AWS console (long boring story) but that was years ago on Windows (long story)
This is true; there are MOUNTAINS OF BULLSHITE about passkeys but its quite literally a big coverup that its incredibly simplistic, its just a SSH public key and authorized_keys file and the only secret sauce is your probably hyper-locked down and very much FOSS system theoretically keeps the secret key on some kind of "special" FIDO key or similar. It can't work on FOSS and non-trusted-computing because its essentially a shite password manager with magic pixie dust and fingers crossed behind backs that they'd totally never MITM you and they totally wouldn't steal your keys ha ha no trust me bro...
The craziest part of passkeys is the intentional MITM bullshit where you can access the key on your phone using your computer. Just like everyone in India and China will also be able to access the key on your phone using THEIR computer, because everyone in the world has root on your hardware except you. Every scammer, ever government, most corporations, they all have root on your phone, you're the only participant in the security theater whom does not have root and you have to "trust" these known scammers by using an easier to steal system like passkeys. At least they have to "work" to steal passwords but once someone powns your passkeys its all over for all your accounts at the same time.
Honestly, you're probably WAY safer using TOTP and 2FA or just using long passphrases as passwords. The reason to demand strange punctuation and numbers and weird capitalizations is to encourage the use of easily stealable password managers or post it notes or just stick it in a file. A much better idea is to remember a long phrase. How about something applicable to this situation like the ESV translation of Bible verse 1 John 4:1 which should provide oh gosh at least 512 bits of security oh and also it provides some good advice in general about AI and especially about Dead Internet theory and bots on social media. But I'm sure the bible can't be relevant in 2025, or so the haters say LOL, but the more educated I get the more relevant it seems to become LOL.
If you want to learn how passkeys work, on a forum like this, I assume we're all familiar with ssh, so run ssh-keygen and give me a copy of your private key and when I say "trust me" I guess you'll have to rely on a blizzard of marketing BS that you should trust me and a long tradition of scammers and crooks who have never done anything bad in the past so you can so totally trust them.
(Score: 4, Interesting) by RamiK on Thursday September 04, @07:06PM
Recent AML/CFT directives (Anti-Money Laundering / Countering the Financing of Terrorism) are stricter about KYC (Know Your Customer) and require mobile devices touching credit card numbers, medical records or even metadata that may de-anonymize to do attestation (the processor check the bootloader-os-binary chain for signatures): https://finance.ec.europa.eu/financial-crime/anti-money-laundering-and-countering-financing-terrorism-eu-level_en#legislation [europa.eu]
The exception that proves the rule is the likes of github doing 2FA TOTP without attestation and really not enforcing much at all except for the TOTP. e.g. https://github.com/rsc/2fa [github.com] keeps the secret key in plain text in ~/.2fa and doesn't ask for any passwords. But, Github's own official client for the mobile does.
compiling...