What is missing for OS based passkey support?

[-]

Dramatic_Mastodon_93@reddit

Seeing a lot of hate for passkeys here. I for one think that they should be the default, not passwords, and that everyone should be using a password/passkey manager, if not something like Bitwarden or 1Password, at least the built-in Apple and Google ones.

[-]

tomachinz@reddit

how do passkeys work for regular n00bs though? as in..... when they lose access to them? is that then just a matter to login again in a long form?

[-]

Nereithp@reddit

Excuse me I'm just going to pointlessly rant.

I'm so fucking tired of these more secure passwordless projects (yes i read and passkeys do genuinely seem more secure). I was today years old when I learned about passkeys while sitting in a restroom, logging into Youtube on a secondary browser and Google pops in with a HELLO WANT TO USE A PASSKEY? I don't know, what even is a passkey? Back when I switched to managing passwords with Keepass with massive randomly generated passwords it was nice and simple: I have my database of passwords and I also have my 2FA TOTP app for select services that need 2FA. Flash forward to 2025, everything is at a different stage of transitioning and now I have:

A database for all the "regular" passwords because newsflash I still need all the "regular" passwords
Like 5 different services that hard lock authentication to their proprietary Android app. Can't move that to my standard TOTP app even if I wanted to and every single one of them does it differently. Some of them want just the TOTP, in some of them it's just the 2FA.
3 services that still push SMS auth on you
Every email app that isn't called "Thunderbird Desktop" doesn't support OAuth 2 on every provider, so I need to go and generate a one-time password for that
Now I also need to learn how to manage passkeys with KeepassXC and co...

There is too much mental overhead for my walnut-sized brain. I'm half-tempted to return to monkey and just have Firefox browser manage literally everything.

[-]

KsiaN@reddit

I'm 100% with you on what you said .. mostly.

I wanna add a few things towards :

3 services that still push SMS auth on you

Only heard this story second hand at a meeting in the pub, but the person telling that story is pretty much always telling the truth, so i believe them.

Apparently they worked for some mayor banks in germany and a few years ago they switch from pushing confirmation PIN's for transactions via SMS to using an app instead.

This was a long announced change with like 1-2 years prep, many letters send via postal service, big adverts and what not.

Come the switch to the app, they said that the support lines got DDOS'ed like there is no toilet paper left in the supermarket during COVID. On a level where they had over 100.000 people waiting in support call queues for weeks.

Turns out .. first gen Smartphones are very reliable and borderline never die, because you can exchange the battery yourself very easily if you get a spicy pillow.

So they developed the app to work on the biggest market share ( which was android 7-10ish at that point ), but turns out that 80% of their customers where still on android 1-5 where the app didn't work.

So they turned SMS push on a gain while fixing it.

Totally different side story : I have seen a lot of people around me ( senior professional in IT ) splitting up their smartphone again in last 1-2 years.

Like splitting smartphone back into :

Your 30€ throw away phone that does nothing but phone calls and SMS with G2 support at best ( so 50kb/s internet )
A dedicated high quality camera
A dedicated high quality music player
A tablet

Not sure what to think of this myself, since you can just use self control to turn off your smartphone if you want peace, but i can see the appeal. Mostly just higher quality in each area and much, much MUCH longer battery life on your phone.

All the so called "dumb phones" i have looked into, do not have access to the android or apple stores, so you would rely on SMS verification instead.

[-]

Neoptolemus-Giltbert@reddit

Nowadays the banks also often try to restrict you on what devices you're allowed to install their precious app on, so e.g. if it's rooted, or running LineageOS or something. Also the PIN is supposed to be the confirmation, the 2nd factor, why do they need 3rd factor?

Banks really are entirely too paranoid and people are entirely too comfortable with banks deciding what you're allowed to do with your money and when, e.g. automatically blocking transactions if you buy too frequently from Steam when buying xmas gifts from some friends, without asking you or giving you the control over it.

[-]

parkan_real@reddit

here's a super fun talk from \~2 weeks ago for those who think banks/enterprise are being too paranoid with their 2FA+ measures: https://www.youtube.com/watch?v=cO72y8FDUOM

FWIW I agree that the specific ways in which banking apps try to guarantee device integrity are not sound (I haven't had problems on GrapheneOS but I know others have w specific EU banks) nor is the common pattern of "which verification mechanism are we going to use this time???" that totally breaks runtime isolation

[-]

Nereithp@reddit

So they developed the app to work on the biggest market share ( which was android 7-10ish at that point ), but turns out that 80% of their customers where still on android 1-5 where the app didn't work.

Oof. Sounds like they have either done no research or there was no feasible way for them to find out.

Not sure what to think of this myself, since you can just use self control to turn off your smartphone if you want peace, but i can see the appeal.

I've seen two versions of this:

The one you described, with dedicated high quality devices + a tablet and a dumbphone
Full on "disconnect" mode, where you completely eschew modern mobile devices and build your own "ideal device" that, like, takes notes, doodles and whatever else you implement. Basically "suckless" but for hardware. You only interact with the modern software ecosystem though your desktop.

In both cases the people pinching these ideas forward are, as you described, senior professionals in IT, aka people with resources and the skillset to be able to do that.

In my personal unfiltered opinion, I think it's a fad for the privileged.

[-]

KsiaN@reddit

Oof. Sounds like they have either done no research or there was no feasible way for them to find out.

Pretty sure the answer is : Yes, leaning towards the later. But they never specified, so who knows.

In both cases the people pinching these ideas forward are, as you described, senior professionals in IT, aka people with resources and the skillset to be able to do that.

Pinching those ideas .. probably, living those ideas .. no.

Because both of your examples would also fit my grand parents. They all have smart phones, but usually only have a dumb phone with them + desktop / tablet when stationary.

Same with my dad who uses a normal book as his login / password storage for decades. ( Don't even try to convince him .. i tried, it will not help )

All of those are probably well off in money, but also insanely tech illiterate.

[-]

TotallyHumanGuy@reddit

I mean, practically speaking, if using a book of passwords means that he uses a unique password for each of his accounts, then he's better protected than most from the threats that an average person should expect.

No-one is going to break into your dad's house to steal his password book, and if someone does break into his house, chances are they won't take what looks like a journal. He should keep it exclusively at his home, but even if he doesn't, chances are it's getting thrown away before it's uses by a bad actor

The threats he's facing are breached passwords and brute-forcing. If you want to make sure he's safe, get him to use the xkcd password scheme.

Also, from what they've said, it sounds like standard people ignoring things until it's an issue. It sounds like they did a fair amount of due diligence, but if they'd done a rolling deployment, they would've caught it before it was an issue.

[-]

KnowZeroX@reddit

I can never understand "shut off transitions", it is like begging for problems. Any transition should run both in parallel until you feel it is safe to discontinue the old one. Even when beginning, you start with a control group, like for example new customers get sent to the new method, while you don't bug those with stuff already working. Figure out the issues, transition.

[-]

Intelligent_Talk7038@reddit

That's the way it used to be with most things, there was beta/bug testing phase but in this new age where things move a lot faster and quality control doesn't exist companies see it as more beneficial to push the new and work out the kinks later. I remember electing to participate in test phases and the companies would sometimes compensate for potentially putting you through the headaches while working out the kinks but that affects the bottom line and money that could be going directly to executive bonuses. End users that pay for these nonsense services get no say and shafted, welcome to the world

[-]

KsiaN@reddit

Well it was in the banking sector so i'm assuming new laws or regulations forced the change.

[-]

I_Arman@reddit

And/or "We're banks so we know what security really is, shut up."

The ugliest, most insecure logins I've ever seen were on banks. "You have to type your password by clicking buttons on a flash app" only looks secure to people who have no idea what web security even is.

[-]

WitteringLaconic@reddit

Nokia 6310i was peak phone. A week on a single charge very do-able.

[-]

MrHighStreetRoad@reddit

passkeys are a bit more secure. It seems the only actual advantage over a password store like bitwarden is some validation of the site requesting the password which otherwise requires human diligence, and the fact that the password is not directly sent, but it used to sign something. However if you used unique and complex passwords per site, which is the point of something like bitwarden, it's hard to see how passkeys are a big improvement, hard for me anyway.

[-]

knome@reddit

passkeys are a bit more secure

passkeys aren't passwords. they're sending public keys. if a website gets hacked that users passwords you get either a) oh shit plaintext lol hope you didn't use that password anywhere else, b) oh shit unsalted hashes, time to rainbow table and hope you didn't use that password anywhere else, or c) shit salt passwords, can still check hashs for easy/common passwords even if it takes longer, will catch some users and if they've also used passwords elsewhere gonna fuck'em up.

a website could have the public keys of its users on a plaintext document that anyone could download and the hackers couldn't get access to it, and passkeys will ensure every site got a different plaintext.

the problem with passwords is the same problem that symmetric encryption keys had. sharing them is inherently a dangerous way of using them, but it's basically the only way to do it. hashing and salting are good mitigations, but the problem itself still remains. if a site is hacked, the hackers can just have the login form capture passwords as users send them and pass them along, even if the db is hashed/salted.

public keys means the website says "prove you're who you say by signing this wad of data (where signing is encrypting the hash of it). you never give the site your private key. they never have anything that can be used to sign anything on your behalf. they never have anything dangerous if they get popped.

it's not just a bit more secure, it's damned near infinitely more secure.

even if hackers owned the login process, they can still just get you to sign a wad of data that says you can login to that site. whoopty do. they can't user that signature anywhere else. they never get to see your private key.

passkeys are fucking great. the only thing I didn't like is the big players trying to tie them to your phone for no reason. doing passkeys from a password manager makes them as easy for the user as normal passwords, and still come with all the benefits of using public key encryption instead of sending passwords/hashes across the wire.

if you want to know more about the history and origins of public key encryption, check out Simon Singh's "The Code Book". Really good piece of literature. And remember to thank Diffie, Rivest, Shamir and Adleman!

[-]

MrHighStreetRoad@reddit

My comparison assumed unique passwords per site, which is what a password manager enables, so all they stuff about hacked password databases is irrelevant to my argument.

However, I agree with all the other points.

[-]

pt-guzzardo@reddit

The domain verification is a big step forward

Is it? Every password manager I've used has always done domain matching. If I go to a site and it asks me to enter my password and Bitwarden doesn't recognize it as a URL where that password could be auto-filled, that's a red flag that I'm being phished.

[-]

eredengrin@reddit

It seems the only actual advantage over a password store like bitwarden is some validation of the site requesting the password which otherwise requires human diligence, and the fact that the password is not directly sent, but it used to sign something. However if you used unique and complex passwords per site, which is the point of something like bitwarden, it's hard to see how passkeys are a big improvement

I see this as a bigger gain than you seem to. There's all sorts of ways to obtain passwords - scam sites/phishing being the main one that I know of, but there are other ways, eg the machine learning attacks that came out a while back where it can guess keypresses from audio, cameras that happen to be pointed at your keyboard, nefarious apps reading your clipboard or keystrokes, someone looking over your shoulder in a public place, etc. I mean, there are even times when users accidentally put their password into the username field, the failed attempt is logged, and now the password is in plaintext for anyone who can hack their way into viewing those logs.

Not transferring the password itself makes a whole class of attacks impossible. If you're very diligent and never become careless even when half asleep, upset, or any other unusual state of mind, passwords are mostly fine (empirically speaking, many users do not fall into this category), but as soon as it becomes as convenient to use passkeys instead of passwords I'm looking forward to switching over. Given the standardized API for authentication that passkeys theoretically have, I imagine it will eventually be more convenient than passwords which will be quite nice.

[-]

MrHighStreetRoad@reddit

thank you for your response. You are probably correct. However, I still think all is not what it seems. If passkey authentication (the equivalent to signing in to Bitwarden) is based on password, it is still vulnerable to all those attacks. It is true that biometric authentication is not subject to cameras watching keyboards, but it is vulnerable to other attacks, and in any case Bitwarden and its peers support non-password login anyway. When bitwarden submits a password to a form, it is not typed, in the ideal case when form completion works. But it's not always the ideal case.

But for sure, passkey means that the password (or its signed token equivalent) is never typed.

But it doesn't stop man in the middle attacks. And the elephant in the room is social attacks, which don't really have any kind of tech solution. The hippopotamus in the room (not quite as big) is all the highly secure fancy sites that still have SMS as a lost password option.

Mind you, I consider myself a sophisticated user who is aware, and I have multiple levels of defence. My #1 solution for the unsophisticated users in my life is to get them on macos, and I'm sure that means passkeys sooner rather than later.

[-]

Individual_Author956@reddit

Man-in-the-middle attacks are not possible with passkeys

[-]

MrHighStreetRoad@reddit

Why not?

[-]

MrHighStreetRoad@reddit

Actually it seems so hard as to be in practice impossible

[-]

eredengrin@reddit

But it doesn't stop man in the middle attacks. And the elephant in the room is social attacks, which don't really have any kind of tech solution.

It can make man in the middle much harder. Since the private key itself is never transmitted, at best the attacker gets a set of credentials that works only once. The authentication requests are also validated by the sites certificates, so you can't accidentally paste (or tell your password manager to paste) the password into a scam site. Of course if the user chooses to trust the invalid certs then it might still be possible depending on the password manager implementation, eg this keypassxc issue, but that could be made harder or easier to bypass in the password manager itself. Even without it, it's more default protection than pasting passwords.

It also limits the damage of man in the middle, the attacker still doesn't have the private key at the end of the day. Websites should ideally require additional authentication to add passkeys or change passwords/emails so in the event of mitm the attacker would just get a single session. That makes it harder for them to lock you out, still leaves you with the option to log them out (if the site has ability to log out all sessions, which many do). So yeah, a lot does depend on the exact implementation details, but at least it gives a bit better default security and allows for significantly improved security if implemented well.

Social attacks - how do you envision it being a problem if you don't have a password to give them? Are you thinking they trick the user into giving their private key? Could happen, I think it's a bit harder since some private keys are inaccessible (for hardware tokens like yubikey) and even software based keys should have big red warning signs around any kind of export option. Password managers can't really have warning signs around copying the password since that's an every day requirement for a password manager, but exporting the keys is rarely done and is always something to be cautious about.

The hippopotamus in the room (not quite as big) is all the highly secure fancy sites that still have SMS as a lost password option.

Yeah...even email resets makes it a lost cause for proper security imo but sms is certainly a level worse. I still view it all as a win though, even if the additional security only helps 10% of the cases (totally made up number), I'm sure those 10% cases would prefer not to have to go through a hack, every bit helps. And once passkeys become more convenient, I think it's fair to say almost everyone likes additional convenience for free.

[-]

HippoBot9000@reddit

HIPPOBOT 9000 v 3.1 FOUND A HIPPO. 2,681,499,442 COMMENTS SEARCHED. 55,442 HIPPOS FOUND. YOUR COMMENT CONTAINS THE WORD HIPPO.

[-]

CrazyKilla15@reddit

Bad Bot.

[-]

Helpful_Ad_1838@reddit

2FA is integrated in keepass, dont know if it wasnt before

[-]

nollayksi@reddit

You might want to consider trying some password manager that supports passkeys out of the box in case keepassxc doesnt. For example bitwarden is open source and provides free cloud syncing of the passwords as well meaning you wont lose anything even if all your devices break at the same time. If you dont feel comfortable cloud syncinc bitwarden is also self hostable, but being open source I wouldt just trust the end-to-end encryption. It supports the good old passwords obviously, stores passkeys automatically, can also generate TOTP codes and has open source apps and browser addond to automatically fill those in for you.

[-]

Nereithp@reddit

KeepassXC supports passkeys and TOTP, is local-only (I sync using Syncthing), has a browser integration + autotype + can be called from the command line.

I prefer my TOTP to be separate from my vault (but not separate in 10 different apps like it is now).

meaning you wont lose anything even if all your devices break at the same time

You will lose access to every app that mandates that you can only 2FA through their app and their app alone.

[-]

Mr-PapiChulo@reddit

KeepassXC (and KeepassDX for mobile) supports passkeys

KeepassDX does not support passkeys.

Also, KeepassXC support for passkeys kinda depends on how the website implements them. Some website will require a hardware device (like fingerprint, which a lot of people don't have on a desktop) to allow you enabling passkeys, otherwise it's imposible. While other's websites will allow you to add passekys to KeepassXC even if there's no hardware device for verification.

[-]

natermer@reddit

There is no way in hell I am going to use TOTP with the same software and/or service that I use to manage my passwords.

Defeats the whole purpose.

[-]

eredengrin@reddit

Defeats the whole purpose.

Not quite. Yes, if they breach your password database you're done for, but if they obtain your password separately from your database, they are still missing pieces to the puzzle. Depending on how you weight the likelihood of them getting your full database vs just your password, you may still see a great benefit from having TOTP in your main database. TOTP separate from password database > TOTP in password database > no TOTP.

One of the most common ways to obtain passwords is sending phishing links and hoping the user enters it into the fake site, so I view TOTP in password database as a significant upgrade to no TOTP. And personally, if someone has a decrypted copy of my keepassxc database, I am hosed just about any way I look at it even if TOTP is stored elsewhere, so I don't worry about it. Funnily enough I don't have TOTP in that database for other reasons but I wouldn't see it as a downgrade to my current setup.

[-]

nollayksi@reddit

Ok then that seems to be pretty solid tool for the job as well. But yeah I do hate those people who refuse to use standard 2fa solutions and instead make their own app. Luckily I personally only have one of those and thats steam and I rarely need to relogin to that. Also at least they provide recovery codes I can store in my password manager so I wont lose access but still inconvinient to have a separate app for that.

[-]

valgrid@reddit (OP)

password manager that supports passkeys out of the box in case keepassxc doesnt

But it does since: https://keepassxc.org/blog/2024-03-10-2.7.7-released/

[-]

repocin@reddit

Even more epic tidbit: I didn't log into my Battle.NET account for like 2 years because I don't really play Blizzard games anymore. I just wanted to check and apparently they completely changed how their 2FA works after merging Blizzard Authenticator into the Battle.net mobile app. Changed to the point they logged me out of the authenticator and my old saved recovery information that I diligently kept safe can no longer be used to automatically recover my authenticator and now I need to go through a manual support process including waiting for CS emails to restore my access to the account.

Wait, really? Oh, fiddlesticks - I might need to do that too, then. I don't even remember the last time I logged in but I'm pretty sure it was with the old authenticator app they forced down my throat.

[-]

rokejulianlockhart@reddit

It's a private and public key combination. You could have just searched Google instead of ranting on Reddit. It replaces both passwords and TOTP 2FA, so it's inequivalent to them, unless you wish to utilise it solely as a second factor.

[-]

Dramatic_Mastodon_93@reddit

Well I personally love passkeys. I can go to Google, my password manager 1Password shows me a card in the top right corner with all my Google accounts that have passkeys saved, I just click on one of them and I’m instantly logged in.

[-]

behindmyscreen_again@reddit

How the fuck have you been unaware of passkey? It’s been around for years and is being widely deployed.

[-]

Nereithp@reddit

It’s been around for years and is being widely deployed.

Enterprise? Because I haven't been offered to use a "passkey" by a public-facing service once until today. It has always just been passwords + 2FA.

[-]

Dramatic_Mastodon_93@reddit

Google, Microsoft and Apple are all really big on passkeys. And many other companies offer them too. Hell, even Nintendo offered them almost right away and they’re not exactly know for modern tech.

[-]

behindmyscreen_again@reddit

Oh, so it’s not a real thing unless it’s used in the enterprise? Lol.

It’s meant to be customer facing.

[-]

Nereithp@reddit

No, I am questioning if you are seeing all of these passkeys in enterprise because I have never ever seen them as a regular user.

[-]

behindmyscreen_again@reddit

It’s always opt in.

[-]

Nereithp@reddit

Got you. I might look into moving some of my stuff over to passkeys now that I'm acquainted with them.

[-]

cleure@reddit

Because passkeys are not widely used. They have gone through a couple different iterations of the same/similar idea, but it still has too many architectural pitfalls for regular users.

[-]

behindmyscreen_again@reddit

They’re widely available as options and have been for years

[-]

mina86ng@reddit

Maybe in your bubble. I’m early adopter of security keys (I’ve used Yubico Nano before it was available to the public) and it’s only recently that I’ve heard about passkey.

Furthermore, their website does piss poor job explaining what passkey actually is. Like why are they telling me that Babylonians were using fingerprints in 500 BC? Or this:

Can passkeys be hacked?

Passkeys are virtually unhackable. The private key never leaves your device, and this requires biometric authentication, making them completely immune to phishing and breaches.

My device doesn’t have any biometric authentication so I guess I either cannot use passkeys or they can be hacked if I choose to use them?

But let’s try. GitHub has option to add a passkey. Let’s try that. My FIDO device wants my attention. Alright…

This credential seems to match an existing security key or passkey registration.

So passkey is just a security key then?

Messaging around passkey is just shite.

And mind you, I’m not criticising the technology. It might be the best thing since before sliced bread. I just don’t know what the technology is.

[-]

hadrabap@reddit

I'm in a similar situation. I'm using passkeys long before Apple and MS came with that fancy name.

You don't need biometrics for passkeys. I have regular YubiKey 5 NFC, and it is sufficient. It fulfills all requirements. A key (you own), a PIN (you know), and a touch (presence). Works with GitHub.

The error message about the existing key is expected. Passkeys are the same WebAuthn used for 2FA but with residential keys! You need to unregister the service from the key to register it back with different parameters.

Apart from that, my two cents:

Adobe account, when used with their proprietary authenticator, asks just for the second factor. However, when you set up a passkey, it asks for a password and 2FA as well. Ridiculous!
Oracle account still uses password only. No 2FA, forget about passkeys. On the other side, I have been using -- now called -- passkeys in Oracle Cloud.
At work, we still need two authenticators (Android apps). They're unable to consolidate it.
My bank uses a separate app as an authenticator. When you have an old smartphone where application startups take a bit of time, the authentication times out before the authenticator loads the request. You're unable to do anything useful with your accounts. Is it usable? No. But it is secure. 🤣

[-]

LazarX@reddit

Not at my job.

[-]

ZENITHSEEKERiii@reddit

I only heard about passkeys in particular when Github suggested I use them for sign-in. Hardware authentication tokens are pretty well known I think because of the crypto bubble \~2018-2020, but passkeys are much less well known.

[-]

Flash_Kat25@reddit

Steam still requiring their mobile app for 2FA really rubs me the wrong way

[-]

CrazyKilla15@reddit

Its really stupid, but its basically modified TOTP and the algorithm is known and many apps support it, like Aegis. The hard/annoying part is extracting the secret or having to disable and re-enable it to get a new one

[-]

s_and_s_lite_party@reddit

Maybe there is a setting? I'm pretty sure steam emails me my code.

[-]

X_m7@reddit

Email works if you just want to buy and play games, but for some things like selling trading cards (or maybe selling them without the hold period or whatever, don’t quite remember) Steam requires 2FA to be enabled using their app.

[-]

s_and_s_lite_party@reddit

Ah right, yeah I just play games.

[-]

st945@reddit

I hear ya. I guess part of the issue is that while FIDO2 is around for a while, it takes major players to decide to adopt them - which Google, apple and MS did around 2022. Since there wasn't a standard widely adopted, some companies had to come up with their own way. I’d give a chance to passkeys... Once you set it up, websites will place it high in terms of trust, like they won't ask for any other 2fa; you won't have to type credentials ever (sometimes autfill might not work in some websites with regular credentials), you in theory don't need to be rerolling passwords, it's safer against phishing since your private key is never revealed and the OS/browser only tries to solve challenges for the trusted website the passkey belongs to. Adoption will increase and be smother over time.

[-]

LazarX@reddit

I defy anyone to top this. I have to maintain THREE separate 2FA authentication apps just to use the critical software on my work laptop used for my help desk duties. And that’s not counting what I use in my personal life.

[-]

sudogaeshi@reddit

can confirm. Some I can control in bitwarden, some have to use Microsoft Authenticator (installed via MDM controlled by work), some have to use Duo, and one have to use Symantec VIP

so 4

FML

[-]

letonai@reddit

Yah, we should create our own auth method, this new one will be better the others

[-]

MouseJiggler@reddit

It's not the OSs job. YOU choose the provider that YOU trust, nobody should be making that choice for you.

[-]

Implement_Necessary@reddit

So how would the provider interact with things like sandboxed flatpak browsers without a library or just insecurely without a choice getting rid of the sandbox

[-]

IAm_A_Complete_Idiot@reddit

Random app Foo wants to use a passkey to sign in. Maybe this app is even a cli app, maybe it has a GUI.

How does it know how to prompt for a passkey? Does it go manually talking to all the usb devices? Stealing your bitwarden vault and asking for a password from the user so it can decrypt it, and access the passkey from there (because there's no standardized API that bitwarden provides)? Do you want it to just not be able to use passkeys?

You need a standardized API, especially when you have multiple providers. They all need to conform to some interface so tools can access them. I.E. you need an interface for everything to talk too.

[-]

mrnoonan81@reddit

I don't know what you think the question was.

[-]

MouseJiggler@reddit

Native passkey handling in the OS.

[-]

mrnoonan81@reddit

The question was what is missing to be able to implement passkeys, not about creating an implementation.

[-]

Effective_Let1732@reddit

Nothing and yet everything. Basically, right now browsers do the implementation of the standard and the key management. Extensions can hook into the mechanisms provided by the browsers, but nothing more.

However, there may be legitimate reasons why you would prefer the OS to handle keys. Maybe because you are in an organization that centrally manages keys, but maybe you would like mechanisms like a fingerprint reader or a TPM module to be utilized for that authentication.

Right now, there is not a standardized way on Linux to handle anything passkey related that goes beyond the functionality the browsers have built

[-]

gclaws@reddit

You choose the provider, but it's incredibly useful for the OS to provide an interconnect between the provider and native apps. Android does this very well in recent versions, native non-web apps can call out to passkey providers (the built-in google one or others like 1Password).

It would be great for native Linux apps to be able to do this, I think having an interconnect protocol would lead to a lot more linux apps taking advantage of this.

[-]

hadrabap@reddit

Android does this very well in recent versions, native non-web apps can call out to passkey providers (the built-in google one or others like 1Password).

Usually, the apps forget to add the removable flag, so I can't use my YubiKeys. Having my login credentials burned in something as volatile as Android and smartphone are is not acceptable for me.

[-]

djao@reddit

The problem with passkeys is that they force vendor lock l-in and can't be backed up and restored, which makes them anathema to most free software sympathizers. It's not that Linux is "missing" anything, it's that passkeys are culturally unsuitable for Linux users.

[-]

eredengrin@reddit

They don't have to, and as far as I know they do not currently require vendor lock in (eg keepassxc) although I wouldn't be surprised at all if apple/google implementations do their best to lock it up. Long term it sounds like vendor lock in might become an optional part of the spec but I don't know the details on that.

This keepassxc issue is somewhat informative as to the state of this. At the very least it's nice to see how strongly the keepassxc community responded against thoughts of limiting user freedom.

[-]

djao@reddit

I see nothing in that link that would indicate avoidance of vendor lock in. The threat is explicitly that keepassxc will be banned from interoperating with other passkey implementations *because* it doesn't require vendor lock-in!

[-]

eredengrin@reddit

The link is about being able to export/import your keys. Yes, lock in is a threat, but it is not the current reality. If you can export and import your keys and manage them with your own software, there is no lock in. It only becomes lock in once device bound keys/attestation is required. I agree it is a long term risk though, and hopefully there is enough infighting and misaligned interests in the industry to prevent everyone going down that path. But I don't look at my ssh keys and say they are "unsuitable for Linux users" just because, say, microsoft might like to tie them to their secure hardware chip if they could.

As long as there are providers who don't require hardware attestation (which, if anything, seems like it might become an optional part of the spec), it is a win in my book. We've only really lost when providers simultaneously require device bound keys and don't allow passwords anymore. Not sure if we'll ever get there, hopefully not, but I could see at least some banking apps wanting that given it's similar to what they already do for attestation.

[-]

nintendiator2@reddit

Yes, lock in is a threat, but it is not the current reality.

There's a lot of people who complacently say nothing ever is wrong, then when things are wrong are curiously nowhere to be found.

[-]

CrazyKilla15@reddit

Bitwarden does include passkeys in vault exports / backups

[-]

djao@reddit

There's an old saying that backups are useless without the ability to restore. And this is exactly the problem here -- while program X may allow you to export your passkeys, very few programs actually allow you to import your passkeys, and even fewer allow you to import passkeys that were exported from elsewhere, hence the vendor lock-in.

[-]

CrazyKilla15@reddit

vendor lock-in is not when various open source programs don't instantly support every other programs export format.

bitwarden is open source, and exports perfectly fine JSON, passkey and all, and theres nothing stopping another open source password manager from importing it, no lock-in or proprietary format or evil lawyers. I do not care to dig into it, but would not be surprised if some like keepass already do support this.

[-]