Hacker News Reader

Comment by gumby271 | Hacker News Reader

I think this is exactly the "Passkeys are a trap" argument though right? If you lock yourself into a single vendor, everything is easy and beautiful. If you choose a diverse set of vendors, it sucks so much more than passwords and password managers ever did.

View on HN

Keepassxc and strongbox passkey integrations seem pretty good on all of the OSes and browsers I've used.

I think passkeys make a messy credential situation even messier, but make a tidy credential situation even tidier.

> Keepassxc and strongbox passkey integrations

Isn't that a single vendor (or two)? How is this not lock-in?

KeepassXC at least allows you to export your passkeys should you choose. The people behind passkeys do not like this. https://github.com/keepassxreboot/keepassxc/issues/10407

This is not accurate. The very first sentence of that issue is:

> Passkeys should never be allowed to be exported in clear text.

and from another comment by the issue creator:

> I don't quite understand why requiring file protection/encryption can't be a temporary minimum bar here.

They're arguing for storing them in encrypted form. That's very much a different argument than arguing against exporting. I'm not taking any sides here, I just think it's bad to so badly misrepresent people's standpoints.

The kdbx format is encrypted on-disk. You need a password to decrypt the database.

That isn't what is being discussed by the issue. The issue was pertaining to an unencrypted export.

>That isn't what is being discussed by the issue. The issue was pertaining to an unencrypted export.

Such security, very rules, wow.

Because an ZIP file with the encrypted key and the password to it in plain text is sooooo much more secure (but it doesn't break the rules, right?).

Asking that services require you to encrypt your backup file by default to protect against local malware or malicious access is certainly not "The people behind passkeys do not like...allowing you to export your passkeys".

keepassxreboot/keepassxc#10407

  [Passkeys] should never be exported in clear text
  Overview
  Passkeys should never be allowed to be exported in clear text.
  [...]

I suppose we have different interpretations of the headline.

maybe read the whole issue?

Which changed to KeepassXC looking to support the standarization work to allow passkeys to be moved between user-controlled software products.

The complaint wasn't in allowing credentials to move (that is the point of the CXF and CXP work). The complaint was in having sensitive data in a plaintext file live long-term without any protections. That is also why one of Tim's early recommendations was to require encrypting the file via a passphrase.

I get the intent of keeping things more secure, but I think the real issue here is that not much thought (so far) as gone into the disaster cases where passkeys are unavailable (either because of broken hardware keys or software glitches). Sure, people recommend registering multiple passkeys for the same service but that gets super cumbersome very fast.

Ultimately if a user wants control over their own keys so they can have a failsafe for recovery (and handle the safety of those exports themselves) they should be able to do so. Until we have very safe mechanisms for backups of passkeys we'll never be able to truly disable other very insecure forms of account recovery without too much risk.

Well, KeePass is self-hosted, and I hadn't heard of strongbox before, but it says on the website:

> Store your data anywhere you like, online or offline. Sync with every major cloud storage provider or your own server over WebDAV or SFTP. Use your Strongbox database with any KeePass compatible client on any platform.

I use nextcloud to sync my own keepass database across my devices. Both nextcloud and keepassxc are open source.

Please explain how self hosting open source software is locking me into a vendor.

If the sky falls and strongbox ceases working with mac/iOS I can use android and linux. Nobody is locking my lockbox.

Good thing the FIDO group is already trying to block key synchronization with keypass and other open source managers...

That wasn't FIDO as a group. That was one vocal member and even their employer ended up disowning the comment. It also wasn't about sync, it was about plaintext export.

It was about forbidding members from syncing with any software that allows or can be altered to allow plaintext exports.

From one guy mad in a github thread. It's a nothingburger.

The fact that they are reserving the right to say what software I can export my keys to makes every rumor a real-burguer. Even if this one specific case turns out to not be real.

"They". Again, it was one guy, who didn't have the full backing of his employer much "the FIDO group". Who made a suggestion, though it was written as a threat because he was bad at communication.

Not to mention the only way to blacklist a specific app from Passkeys is to use the AAGUID from attestation which means it only applies to attestation. A few pieces of software were providing AAGUIDs by choice even when not attested and Apple helped remind them that the spec says non-attested Passkeys should always just return an Empty UUID (all zeroes) in AAGUID. The people that are going to block non-attested Passkeys might as well block all of them, including Apple consumer Passkeys.

On iOS devices you can import/export Passkeys between supporting password manager apps (including Apple Passwords).

In my experience, migrating between Apple Passwords and Bitwarden worked without issues, in both directions.

I'm not saying it's impossible, I'm saying there's a barrier that's useful to further vendor lock in. My mom is going to use Apple passwords on her iPhone. When she needs a new phone, the complexity of import/export and fear of losing access to her accounts is going to push her to buying another iPhone. It's just another avenue of lock in, like existing OS level password managers, just with an extra level of confusion for the end user.

My dad didn't like iCloud Passwords because he still uses a Windows laptop and only recently has the iCloud Passwords app been good or all that useful. We settled on 1Password a few years ago and having 1Password on his phone and setup as his default password app means that iOS uses it as the default Passkey app as well. "It just works."

The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.

Wasn’t part of the point of the last article that some of the various methods we call “passkeys” aren’t portable?

Generally, if you want to restrict the user to use a particular authenticator, you need to own that authenticator. At that point you can have the attestation you are looking for. If you want Yubikey policy and behavior, you're gonna have to get your user a Yubikey.

The passkey provider vendors are motivated to serve their customer's needs (the end users, and secondarily enterprise deployments) over non-customer needs.

So Apple platform support (for example) will only send an attestation when one is configured via MDM. Your provisioned work device can indicate to work systems that it is in policy.

The compatibility-limiting risk, if it exists, is more likely from regulators putting their hands on the scale and pushing for security policies that would prevent synchronization and backup, and requiring attestations to make sure those policies are in effect.

Most "Passkey" branded approaches are portable. The "not portable" subset of Passkeys is primarily backwards compatibility with things like Yubikeys. That's also what attestation is mostly for, backwards compatibility with applications and Enterprises that still need "this is specifically the physical Yubikey I mailed this user" type keys, not as much Passkeys.

But can you use Apple Password app on an Android device?

If that's the argument, it's bull. If you use Apple hardware, you're not locked in and required to use Apple's default Passwords manager.

Microsoft Authenticator, Bitwarden, 1Password, etc. all support storing passkeys and support multiple hardware platforms.

It's no different than making your own decision on which password manager you want to use.

brother I locked myself in long before the passkey showed up

I mean yeah, customer lock in has been Apple's business model for a long ass time, that's not surprising.

Mostly, though, it is not true lock-in, as in they mostly don't force you to do things their way. They encourage it, make the features pretty seamless to use, etc, so that you want to stay in their system, but they generally permit you to use whatever tools you want.

Agreed, it's the bare minimum to keep them out of trouble usually.

On an iPad/iPhone, you are not allowed to install apps not approved by Apple.

Oh shit really?

The fact that the password manager someone might use on another system is a complete piece of crap does not mean passkeys are an Apple lock-in attempt.

There are an open standard. You just have terrible software.

My issue isn't with the standard, but if all implementations lead to the same shitty experience of 3 different apps begging to store and use my passkeys, then something isn't working right. In my case, the terrible software is Apple's Mac OS, Google's Chrome and/or Firefox, and sometimes Bitwarden still acting weird. Lets not even get into how wild Windows acts when a passkey shows up.

Saying it's an open standard, and that it's just all the major players I'm forced to interact with that make it suck isn't very helpful. That's like the people that say "Don't like iOS? Build your own successful mobile OS lol"

I’m not saying built your own mobile OS.

I’m sorry you have multiple pieces of software that want to be in charge, but aren’t passwords the same? Because Chrome and Firefox both want me to use them for my passwords. It’s not a problem unique to Passkeys.

It’s just everyone ignoring user preferences to try to score stickiness.

As the previous article says, some passkeys are open, while others require lock-in, and megacorporations deliberately create confusion between the two.

What lock in? The attention this article debunks and no one uses?

That question has been answered multiple times here.

Microslop uses it. If you want to login to a corporate Microslop account with a passkey, you have to use Microslop software.

Reply on news.ycombinator.com