[HN Gopher] Credentials for Linux: Bringing Passkeys to the Linu...
       ___________________________________________________________________
        
       Credentials for Linux: Bringing Passkeys to the Linux Desktop
        
       Author : alfie42
       Score  : 41 points
       Date   : 2026-02-08 16:41 UTC (6 hours ago)
        
 (HTM) web link (alfioemanuele.io)
 (TXT) w3m dump (alfioemanuele.io)
        
       | digiown wrote:
       | Passkey/webauthn is a cool tech, and I'd really like to use it
       | everywhere, but I find the anti-user attitudes of the spec
       | authors concerning. The spec contains provisions about "user
       | verification" (the software must force user interaction) and not
       | allowing the user to access the plaintext keys. It appears that
       | the spec authors do not consider the keys to be owned by the user
       | at all.
       | 
       | KeepassXC implements passkey support, but they do not implement
       | these anti-user features. As a result, they are being threatened
       | with being banned via attestation:
       | 
       | https://github.com/keepassxreboot/keepassxc/issues/10406
       | 
       | https://github.com/keepassxreboot/keepassxc/issues/10407
       | 
       | Screw these "You'll own nothing and be happy" people. I'll own
       | all my keys no matter what. The software I run on my device
       | should never betray me to signal things like "this passkey is
       | allowed to be backed up!".
        
         | cadamsdotcom wrote:
         | Agreed, unfortunately.
         | 
         | Passwords are easy to understand, transparent and portable, and
         | when used with good hygiene (always using password manager and
         | generating unique & strong passwords for everything) there
         | isn't yet a strong case for anything else.
        
           | doubled112 wrote:
           | I'm not happy with everything about passkeys either. I am
           | fine with them as an additional method, but I would never use
           | them as the only method.
           | 
           | That said, I had a much easier time getting my kids onboard
           | with a FIDO2 security key than I would have a password
           | manager.
           | 
           | Enter your email and touch this is easy to understand.
        
         | giancarlostoro wrote:
         | How do you even ban something like KeypassXC given that it is
         | open source and any end user could basically edit KeypassXC and
         | bypass a ban?
         | 
         | Edit: Reading one of those issues it sounds like they want the
         | keys stored in an encrypted way, is that too much to ask for? I
         | dont care about viewing it but it shouldnt be stored in a plain
         | easy to open JSON.
        
           | digiown wrote:
           | That's the thing, they can't yet.
           | 
           | They are proposing an attestation scheme. I'm not sure the
           | details are out yet, but the authenticator would presumably
           | use one of the hardware security mechanisms (like a TPM bound
           | key) to "certify" its own authenticity along with the
           | challenge.
           | 
           | This will effectively ban all open-source implementations,
           | and end user freedom if widely adopted. Fortunately for us it
           | seems like Apple isn't cooperating here for now, and without
           | Apple signing on, it wouldn't get anywhere.
        
             | altairprime wrote:
             | [delayed]
        
           | digiown wrote:
           | It's an export format. The storage is always encrypted with
           | the database key. And you can view the key directly anyway
           | just like you can view passwords, and copy it from there.
        
           | politelemon wrote:
           | > ask for
           | 
           | That's the key difference. If it mattered, they would make it
           | part of the spec, not threaten a ban. That's even more
           | concerning, there is a central group of people who get to
           | decide who can and cannot use Passkeys.
        
           | Dedime wrote:
           | Well, it's stored in an encrypted way - in the encrypted
           | password database. Much like a password, everyone already
           | knows not to share a passkey. But also like a password, as
           | the owner, sometimes I want to look at it!
        
             | frizlab wrote:
             | Genuine question: why?
        
               | TomasEkeli wrote:
               | it's mine.
        
         | signal11 wrote:
         | Shafting open source projects that implement your spec is not
         | okay, and is terrible optics.
         | 
         | Tech journalists should ask the FIDO Alliance if they're just
         | Google+Apple+Microsoft in a trenchcoat. Definitely not very
         | open!
        
           | digiown wrote:
           | I do get that there are use cases for actual hardware bound
           | keys for enterprise settings. But having non-exportable
           | credentials (effectively non-ownable) is not acceptable in a
           | consumer setting. This is a thinly veiled attempt at
           | strengthening platform lock-in.
           | 
           | Look, the spec says you can't export the keys to a file! Too
           | bad, go re-register your 120 websites if you want to stop
           | using iCloud/Google!
        
             | Groxx wrote:
             | Particularly because "you must use only an approved passkey
             | manager" is fairly easily solved by MDM, which is already
             | widespread.
             | 
             | It's DRM, and it will go down exactly the same anti-user
             | and anti-competitive route as every other DRM. Fight it
             | with fervor.
        
         | politelemon wrote:
         | > It appears that the spec authors do not consider the keys to
         | be owned by the user at all.
         | 
         | This was my impression, and it explains why the original
         | announcement involved companies that would benefit the most
         | from keeping their users on a leash.
        
         | AndrewDucker wrote:
         | They don't consider the key to belong to the user. The key is a
         | token generated by the site to allow it to identify a user. In
         | order for them to do perfectly so they do not want users to be
         | able to tamper with them, leak them, or do anything which might
         | violate their assumptions about the key.
        
           | mzajc wrote:
           | No, the private key is generated and stored client-side, and
           | never sent to the server. Even if that wasn't the case, how I
           | store my credentials is none of the websites' business, and
           | my own hardware shouldn't do as I say.
        
       | notepad0x90 wrote:
       | I just wish more people would protest this instead of things like
       | secure boot.
       | 
       | Password managers and/or operating systems can manage private
       | keys just fine. websites shouldn't be concerned with how the keys
       | are managed, or be able to make demands on how users store
       | credentials, or know device details for users.
       | 
       | One thing I dislike even with systems like FIDO2 is that the
       | websites/apps can block list your FIDO key's vendors. Similar
       | trends suck. Passkeys are just one iteration in a long line of
       | systems designed with corporate interests in mind.
       | 
       | The system validating the authentication needs only to verify
       | that the credentials are correct. If users want to use TPMs,
       | HSMs,etc.. or none at all, that's up to them. And no information,
       | other than what is strictly required to verify the credential
       | should be transmitted over the network. a signature of challenge
       | data from the app should be sufficient. the user's public key
       | shouldn't be signed at all by hardware, a trusted 3rd party,etc..
       | the registration process should take care of establishing public
       | key trust to the authenticator/app. The whole thing feels
       | insidious.
        
         | digiown wrote:
         | Corporate interests HATE general purpose computing, and the
         | freedom to run what you want. With that freedom, you can hurt
         | their interests by blocking ads, stripping out spyware, or
         | avoiding giving up your privacy, and they can't let you have
         | that.
         | 
         | It's a death by thousand cuts that's finally starting to come
         | together:
         | 
         | - Remote attestation like Play "integrity"
         | 
         | - Hardware backed DRM like Widevine
         | 
         | - No full access to filesystem on Android, and no access to
         | filesystem at all on iOS
         | 
         | - No ability to run your own programs at all on iOS without
         | Apple's permission.
         | 
         | - "Secure" boot on Android and iOS that do not allow running
         | your own software
         | 
         | Ever wondered why Windows 11 have a TPM requirement? No, it's
         | not just planned obsolescence.
         | 
         | If they get their way, user-owned computers running free
         | software will never be usable again, and we'll lose the final
         | escape hatch slowing down the enshittification of computers.
         | The only hope we have is that they turn up the temperature a
         | little too quickly that normies would catch on before it gets
         | far enough.
        
           | hparadiz wrote:
           | Windows 11 has tpm required to enforce full disk encryption
           | that is pinned to a given machine. Linux would do well to do
           | the same thing. It's possible but almost no one does it.
        
         | jmclnx wrote:
         | I fully agree, seems Linux is heading directly towards being a
         | Windows Clone. So far all the windows crap can be easily
         | avoided, but once these things are forced on me, it is bye bye
         | Linux.
         | 
         | Already I use BSD on an older laptop probably 40% of the time.
         | Linux on my main system is there due to a hardware device issue
         | BSD still have a minor problem with it. But for me right now,
         | Linux seems to be heading in a wrong direction.
        
           | digiown wrote:
           | KeepassXC implements passkeys in a respectful way. I don't
           | see how this is "Windows crap". If they want to force
           | attestation on passkey implementations, whether or not Linux
           | supports it will not matter.
        
       | hexo wrote:
       | No thanks, it stinks.
        
       | shmerl wrote:
       | That's interesting. How the actual passkeys will be stored with
       | this approach?
        
       | flumpcakes wrote:
       | I'm a big fan of passkeys, but they are currently harder to
       | manage/reason about than passwords (even autogenerated ones
       | stored in a password manager).
       | 
       | My web browser wants to own the passkeys, my OS wants to own the
       | passkeys, I have to deny them before I can get to my hardware
       | key. Some providers will sync passkeys amongst devices, which at
       | some point seemed to be against the spec.
       | 
       | It's all rather confusing. I wish there was a straight forward
       | best practise that can be followed without the niggling worry
       | that you're doing it wrong, or that you might get locked out of
       | services.
        
       ___________________________________________________________________
       (page generated 2026-02-08 23:00 UTC)