Seeing this more and more with Chrome, like Credit Card numbers used to just save and autocomplete in browser but then they had some popup that was worded in a weird way that tricked me into saying it into Google Pay. Then I had to like type in the CCV to retrieve the card but then it also charged my bank account 1c for the privilege of autocompleting the card each time. Took me good 20 minutes to delete my card, get it saved back in the free local auto completely and shut down my Google Pay account I never knew I had.

I tried. The power-grabbing garbage was immediately apparent and sent me straight for "heck no, I'll just use passwords until they figure this out, at least that can't control my password manager".

In principle I should be very in favor of them, but the wild variety of lack of support for basics, and the built-in-the-spec ability for site X to control how I store and sync stuff is utterly bonkers. It's feeling like the OpenID promise -> OAuth platform lock-in cycle all over again, but compressed into v1.

I don’t get what the issues people have really are. I never experience them (fortunately!).

Now if we could just get the other providers that require insecure email/SMS 2FA to follow suit, that would be great...

The vast majority of the population will do a worse job on the availability and security of a selfhost solution than 1Password, whose core business and value proposition is password management.

I’m a very happy user of 1Password for Families and consider it the likely the best ~$50 a year that I spend on hosted technologies.

Whether or not you can import them into something else though…

Such things do have purposes, in high-stakes environments. They prevent accidents. The vast majority of uses on the public web are not even remotely in that realm. It'd be better off being a separate spec that only a handful of internal-only systems use, ideally requiring MDM to set up conveniently (to strongly discourage normal and even high-stakes-normal website usage).

My banking website has absolutely no business knowing and being able to approve or deny what brand my authenticator is.

I don't trust many people to do that.

I have everything encrypted and self hosted and I sometimes wonder what I would do if I was suffering from amnesia after an accident for example. And having a note somewhere telling me I have a safe in bank X is the only solution I have found.

Ah! I have the exact same recurring worry, it's very unpleasant. I'd really prefer to keep home media unencrypted, but the thought of a robber seeing my tax returns or photos of my infant daughter is constantly at the back of my mind.

Even worse is the eventuality of them getting their hand of a picture of your ID card or passport, or whatever they can later use to steal your identity. Identity theft is nightmare stuff.

This way you don't need to trust any single one of your friends to be 100% honest nor 100% available.

you could rsync files before you could Dropbox too, but there was still a need for a Dropbox.

Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contracts that stipulate fiduciary duties, courts will enforce those contracts just fine.

As a technical alternative (or augmentation), you can also use a threshold secret sharing mechanism to store your keys amongst your friends and/or with companies.

Now what you can complain about is that there is no convenient way to do all of this. And that's a very legitimate complaint! Convenience is important.

However, the way to get convenience is not via regulation.

Fun fact: the reason why giving it to your lawyer or a notary works is exactly because of regulation regarding these professions. Without regulations, there would be no such alternative.

It is, because no company is ever going to give you the convenience you want at their own expense ;)

The Western world and Asia is a pretty good evidence that government works. If you want the libertarian dream of no government, you can go to Somalia, or South Sudan, or Yemen, or whatever failed states you can think about.

> And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.

Oh sure you won't go to jail, but the alternative doesn't exists so you can't get it either. Like the convenient safe storage we both wish it existed.

In totalitarian dictatorship, you can't build such a tool without getting murdered or jailed, in totalitarian Capitalism you can build it but it will eventually be blocked from reaching any significant room on the market because of big corps or if you raise money from VC in order to get the marketing you need, it will eventually be bought out by one of the big player who will close or enshitify it.

The good alternative is what's called democracy, where the sovereign people vote for things instead of leaving the power to the party or the market.

Would you really trust your lawyer with your bitcoin seed? If they stole everything from you, how would you even prove it?

But the whole thing depends on how much you own in bitcoin.

If it's a whole lot, check how other people in more traditional domains are dealing with their lawyers or notaries handling these sums. (For one, it's a bit easier with bitcoin, because you don't need to tell your lawyer or notary what you are giving them. And you can encrypt the private key data with something derived from an easy to remember password. It doesn't need to be 100% cryptograhpically secure, it just needs to lower the temptation for your lawyer.)

Btw, I think the bigger problem in practice wouldn't be your lawyer stealing from you, but your lawyer somehow losing your data.

They used to offer their apps offline and you could "host" it anywhere. Venture Capital ruined them.

1Password has fallen hard from their earlier excellence.

[1] https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys

BitWarden is open source to a large degree and even provides an (open source) server for self-hosting.

Does it work well?

Google loves that nonsense, don't they? It's as though they think so highly of themselves that they cannot imagine they might not be strictly doing us all a favor by signing us up for their services.

Fifteen years later, I still have friends occasionally sending messages to a GMail address I never asked for, never used, and didn't even know about for most of a year while it was virally spreading through people's address books, silently diverting mail away from my actual address. The only time I used this account, after I discovered that it existed, was to delete it - but GMail apparently still suggests it when people type my name, because I get an "oops, sent this to the wrong address" forward every few months.

No I will not be knowingly using any Google passkey service, but perhaps I will someday find that they have signed me up for it anyway.

Now you have lots of chaff / ablative / imposter emails to divert away all the robo-mailers, spear fishers, destitute princes, and the like. Even the tiniest little mistake and the email goes to one of a million diversion accounts.

Side Not-a-joke: On this topic, I also really hate two-factor authentication you don't sign up for, don't want, yet are forced to add to your account, because Google Play is too much of SCIF to just let you log in. Even more security theater for the most basic activities. Now I need two-factor every time I try to use GitHub. Ugg.

I had my Facebook taken over because I had all notifications disabled and forgot that the email address was associated to it. Some criminal behind an Egyptian IP address took my old email and was in my Facebook within two days of me surrendering it.

The dark pattern about signing up for google pay is absolutely inexcusable though. Sorry you're going through that.

I believe those transactions are never confirmed and are reverted after 7 days or something like that

Additionally, passkeys are just a synced-via-cloud implementation of FIDO2, an open standard that has other implementations you may feel more comfortable using.

For someone who requires being able to sign in to, say, GitHub from multiple different operating systems or platforms, you have a few options.

1. Use a passkey on your primary device, say an iPhone. You can still sign in to GitHub on a Windows computer or Android phone but you must have your iPhone with you. During sign in, there is an option to show a QR code on the Windows/Android, which you will point your iPhone at, and the two devices will do a secure handshake to sign you in. This is probably the worst option from a UX standpoint if you sign in on lots of devices that are not your primary.

2. Use a physical security key to store a FIDO2 key instead of a passkey. These devices are inherently cross-platform. Remember, a passkey is just a type of FIDO2 key. No one is forcing you to store it in the cloud. You can buy something like the YubiKey 5C NFC to store your keys completely offline and under your own control. The tradeoff is you will need to have it with you and you will need to plug it in every time you create an account or sign in.

3. Add multiple passkeys to your GitHub account, one for each platform you want to be able to sign in on. Unlike passwords, where an account generally only has one password at a time, it’s normal and even recommended to have at least one backup FIDO2/passkey registered with an account.

And of course these aren’t mutually exclusive, you can mix and match these techniques, perhaps depending on how important the account is or how/where you typically access it. Maybe you only use a single passkey on your primary device for your bedtime social media scrolling, but use a passkey with a backup FIDO2 security key on GitHub.

Check whether your Yubikey supports resident keys (aka discoverable credentials) and whether the FIDO key for your account was created with residentKey: true, otherwise it’s a completely different (older) flow under the hood, where the private key actually gets sent to the server, and it wouldn’t surprise me if that’s the underlying cause of what’s happening to you.

I have so many keys scattered everywhere that I would need an excel sheet to keep track of them. I regret not doing that already .. or perhaps I regret using passkeys at all. I am still trying to figure that out.

But I do agree with the point that Passkeys make it really easy to get locked in unless you’re careful.

But then I have the analogous problem of never being able to switch password managers!

The idea isn't to move your keys around willy nilly the idea is that should you need to, you're not beholden to bitwarden inc.

1. Login with the passkey from your iPhone.

2. In your account, add a new passkey from your new Android. Now both passkeys are active.

3. Login with your new Android passkey.

4. In your account, deactivate the passkey that is stored on your iPhone.

Passkeys aren’t passwords. You can have more than one active at the same time. So instead of moving a single passkey around, you add or remove them to change devices or service providers.

There’s no way I’m doing that for each of them (or figuring out which ones support passkeys).

That's not true. Passkeys actually require iCloud Keychain, which is obnoxious, because you can't use the OS passkey support without using iCloud. And you can't even manually export passkeys from iCloud Keychain, which is totally opaque.

So it is still platform lock-in, just not in the way you described.

It doesn't matter how many SaaSes offer it or how many brands of devices adopt it. It still means that for access to all of your accounts, you either 1. Have to stay with that brand of device or 2. Have to rely on the goodwill of the SaaS not to suddenly start raising their prices (the comparison here is passwords, which are free).

Before you say that switching providers is possible, that doesn't really matter. Let's say I stored the passkeys on my iPhone/iCloud. And then it got stolen.. whoops! Now I must at the very least acquire another Apple device until I can reach any of my accounts, i.e. I'm tech-dead until I do so.

If switching is not frictionless, it's an absurd level of lock-in, almost making it impossible. I have to go into every single account and add a new passkey? What if I forget one when I switch, then I'm out of luck and can never use the account again?

I've not had a problem registering both this and my phone on any site.

Avoiding the risks of short, weak passwords? The risks of reusing passwords across sites? The inconvenience of remembering loads of passwords? The frustration of having to type passwords manually? The risk of getting phished or typing one site's password into a different site? Remembering and typing usernames? The password manager takes care of all that for you already.

And if your objective is to have a second factor just in case your password manager gets compromised? A physical button just in case someone takes over your mouse and keyboard? Or a credential stored in a secure element that's (somewhat) protected even if you use it on a compromised machine? Putting it in a password manager (or OS keyring) removes those advantages.

Technically the place where you store your passkeys can be hacked into, but there is no technology that protects against that. You could give a tech layman 5FA and he’ll give all 5 factors to the nice man on the phone call.

Neither can passwords if you’re using a password manager to handle them.

So again, if you’ve already got a password manager, and would put your passkeys in a password manager, what is the benefit of passkeys?

Edit: The other great part is that the server just stores your public key, so it's idiot proof on their end. It makes a breach effectively useless, since offline cracking is impossible.

The value of these seem very low. Passkeys are a solution looking for a problem.

Mayve 10 years ago before password managers became a thing they made more sense? Now they're just kind of annoying and hard to share (sharing passwords is a real need for many people /applications / services)

With passkeys it's literally impossible.

I'd see having the user add the domain themselves, or get the user to copy/past the password themselves on some other form. But the phishing is not happening on the password manager side, and these use cases still exist even after you chose passkeys (i.e. I'd still need to somewhat log into Google's auth from my Nest hub for instance to have it show the calendar)

In any case users are trained by the internet to need to search for the right password outside the pinned domains. Most of the time I guarantee people don't add the extra domains to the password records. So when a phishing site pops up they'll do the same: search for the site name/domain that they think they're logging into and go from there.

Password managers solve password reuse, weak passwords, etc. but IMO do not solve phishing, especially not for the kind of user who's most susceptible t it (little technical understand, hates this stuff, just wants to follow instructions and not deal with it), but passkeys might.

These issues won't be solved unless passkeys work absolutely everywhere the user has to authenticate. Logon required or weird and funky domains is currently due to service providers being a mess themselves (I'm looking at you, Microsoft). So should we expect them to miraculously get their act together and have each of these system flawlessly work with their passkey auth. from now on ?

That's where I think we're stuck with that class of issue for as long as there are multiple auth systems, passkeys or not.

I'd still recommend using a password manager, as overall and in practice the risk of phishing and (re)using (weak) passwords is far greater than this kind of rare vulnerabilities (and also I work for a company that makes a password manager ^^)

See https://lock.cmpxchg8b.com/passmgrs.html if you'd like to know more

I dunno about you. But I like being able to get my passwords out of the password manager. How is not being able to do so a feature?

A password manager, OTOH, is happy to hand out your private key ("password" in this case) to anyone that has access to it.

I want to move my passkeys where I want and use tools I want.

Not allowing anyway of changing passkeys is terrible. Imagine someone switches from IOS to android. How do they use their passkeys?

Even if they had a big “warning don’t do this” sign it would be better than not allowing it in anyway.

Who says you can't change your passkeys? Just log into the site with your existing passkey (or other 2FA) and change it.

This is absolutely not true, it depends heavily on usage patterns of the password manager and its features. Not all are browser extensions that autofill, and even if they did, sites change their domains for auth occasionally that break this functionality (or more often, signup is on a different domain from auth) meaning you must manually copy-paste your password somewhat often if you don't meticulously, and manually, maintain your domain list for a credential. The average person is *not* going to do that, they're going to go "huh, it broke again" and copy paste their randomly generated password.

Please, do not give security advice you are not equipped to handle.

Sure the do. All somebody needs is the password to your password manager. It's a single point of failure and by putting your passkeys in there to you've made it even more vulnerable.

Do you put a passkey on your password manager that exists outside of that ecosystem? Once you have that why not just use it for everything?

The parent wasn't giving security advice. They were asking a valid question.

Not more vulnerable than if they were just using password. You're still missing my point, password managers do not give you the ability to just copy-paste the private key of a passkey into a form field, unlike passwords. Some don't give you access to it at all (*cough* Apple *cough*). Sure you can get the private key if you have access to the password managers vault, but that's not what's being talked about. Common usage patterns matter immensely in security. At the end of the day, the attack surface for passkey-based authentication is smaller than password-based authentication, which is a step in the right direction.

> The parent wasn't giving security advice. They were asking a valid question.

The parent made a blatantly false and dangerous statement and then followed it up with a question. Did we read the same comment?

I also agree that passkey-based authentication provides a smaller attack surface than purely password-based authentication.

But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.

This is an HN forum. Nobody's giving "security advice," but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?

I feel like we might have a mismatch in understanding what a passkey is. You make a new keypair for each account to authenticate to. A leaked passkey is generally no more vulnerable than a password when leaked.

> But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.

Correct. The gold standard is a hardware secured, non-cloud synced private key.

> This is an HN forum. Nobody's giving "security advice,"

It's a technical forum with statements on a technical topic. Making statements like that can always be misinterpreted as technical advice by default.

> but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?

This is fair. The answer is: convenience. It is most definitely worse security posture to sync passkeys than to store them on a separate, physical device that can answer challenges without leaking the private key.

The reason to use them over passwords is they are more secure, even when synced to a cloud vault.

Password managers should be the default authentication method, and the current hack of having it type text into a password field is both unwieldy and completely avoidable.

That's the benefit you get from passkeys that no password manager will otherwise be able to give you.

Passwords are reasonably secure since we've been using them for a long time but there is in fact a huge chain of trust required to keep them secure and links in that chain frequently break.

Passwords are based on symmetric cryptography. When you log in to a site using a password you give the site your password in plain text, hopefully over an encrypted communication channel such as HTTPS so that no one between you and the site can see the password.

The site then takes that plain text password and decides if it matches the plain text password you gave them when you created the account or most recently changed your password. If the site is following good security practices they aren't actually storing a copy of the password in plain text. They will store a hash of it and compare a hash of the password you just send to see if the hashes match.

Passkeys are based on asymmetric cryptography, also known as public-key cryptography. When you set up an account at a site to use passkeys your device generates a public key and a matching private key. The site is given the public key and your device keeps the private key.

When you want to log in later the site sends your device some data, your device does a computation on that data that involves the private key and sends the result to the site. The site can recognize that whatever did that computation had access to the private key that corresponds to the public key the site has on file.

Passkeys use public-key authentication wherein the server only stores the public half of a keypair and the client authenticates by correctly signing a challenge sent by the server, which the server then verifies using the public key.

At no point is the private key ever sent over the network or otherwise exposed to any infrastructure or code controlled by the server.

If you read adtech docs, authenticated user sessions are the gold standard on enumerating user preferences for the sake of ads.

Un/pw friction is noted as a difficulty in achieving this. Cookies developed the way they did in response, +/- details.

If cookies go, then passkeys look a lot like a tangible and realistic solution to enumerating users via authn/z’d sessions, minus the friction of un/pw and a pw manager.

IMO, the impacts of passkeys will feed right into this solution, and while I’m not sure if you can safely argue passkeys are a nefarious plan to replace cookie tracking, I don’t think you can get a tech giant to support such a reimagining of user experience if it didn’t have ancillary benefits beyond solely security use cases. When has a company like Apple or Google ever done such an equivalently large amount of work solely in support of security?

Ideally, you should be able to get an authenticator's public key and be able to enroll one without presenting the authenticator itself, allowing you to keep it in a safe/etc.

This would enable an easy workflow - enroll main authenticator as normal, then enroll your safely-stored backup by pasting its public key. If you lose your main, go to your safe, get your backup and "promote" it to primary and enroll a new backup one which goes in the safe.

In reality websites should not allow setting up a single passkey.

I remember AWS having some weird choices at some point too, not sure how they are currently.

But yeah, typically I think most services have had multiple choises available at the same time.

On MacOS you cannot enable passkeys (or using TouchID with them?) without enabling iCloud Keychain.

I'm fine with iCloud Keychain. But to enable it, you have to enable "autofill form password" which enables it in Safari. Disabling it in Safari disables the global setting and disables iCloud Keychain.

WTF.

https://twitter.com/dmitriid/status/1782787035637375050

This comment just 4 months ago from 1Password says that exporting isn't possible: https://www.reddit.com/r/1Password/comments/18m4iph/comment/...

And I haven't seen any announcements in the opposite direction.

————

Edit: so I just checked and I can confirm that it's not possible to export passkeys from 1Password. Neither of the two available export options include passkeys.

> • 1PUX A 1Password Unencrypted Export (1pux) file will export all your data, except your passkeys. You'll need to create new passkeys with your next password manager

> • CSV (Export only certain fields) A comma-separated values file (.csv) will export only certain fields. It won't export data such as custom fields or file attachments.

To answer your question, "bamboo menu, Copy Item JSON" which I believe is turned on due to my "Preferences, Advanced, Show debugging tools" being checked. I actually did try the $(op item get --format=json $its_uuid) first but figured there was some sekrit env var or --fields some_horseshit that I needed to dig up and it was more energy than I wanted to spend for a HN comment

So, OT1H, what I send was half true - they are available for export but only after some hoop jumping and seemingly not in the official export packaging, which I suppose almost guarantees they will not "round trip" back into a Vault in any kind of disaster recovery scenario

It seems those 1Password jokers just get great thrills out of ensuring that anytime I have something to praise them for they ensure they have some user hostile stupidity ready and waiting to drive people away

    $ cd ~/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data
    $ sqlite3 -readonly 1password.sqlite
    sqlite> .tables
    account_objects   creation_drafts   item_overviews    ssh_pubkeys
    accounts          deleted_accounts  item_usage        users
    autofill          editing_drafts    kanon_autofill
    collection_map    feature_flags     objects
    config            item_details      search_weighting

The whole fucking point of a password manager, though, is to store and securely provide authn material while ensuring users can’t lose it… which necessarily includes ability to access it, and back it up.

It looks a LOT like passkeys and FIDO are, relatively effectively, backdooring what Google got beat to death for when they attempted to add “Web Environment Integrity” to browsers.

edit: But can I? I’m already questioning how hard it’s going to be, and if it’s feasible without a lotttt of hurt.

I feel bad for the author. They put a lot of their heart into something that could have been awesome.

[1] https://docs.onlykey.io/usersguide.html

The big tech companies (Google, Apple, MS) have all become evil.

My understanding is the ability to do that is built directly into the spec with the attestation feature. The only thing that might slow it down is Apple choosing to not implement it and zero out their device string. Others can piggy back on that to protect themselves behind Apple's skirt, at least until Apple changes their stance anyway.

Platforms of course could just not allow Apple passkeys and only allow Apple users to use other 2FA options as well. Rest assured that small players like KeepassXC will be the first ones to have their passkeys blocked or not supported.

The whole thing is a trap IMO.

Basically, the security key stores a single symmetric key. It'll generate a public/private keypair on registration, encrypt it, and send it to the server. On authentication the server will return the keypair back to the security key, which decrypts it and uses the retrieved private key for authentication.

You create one on your iPhone and another "backup" key from a desktop PC running some open source software. If your iPhone breaks you can always use the other.

Similar to a server configured to accept multiple different SSH keys.

There’s some hope for interoperability between password managers someday. There doesn’t seem to be agreement on how you can securely export, transfer and import today however.

- you can log into your 1password on multiple devices

- you can sign in by QR code, with the help of whichever phone has the passkey on it

- you can add multiple per-device passkeys to your accounts of interest (for example, log into github on desktop and then add a passkey for your desktop device for that github)

- you can keep all your passkeys on a hardware dongle

- you can set up and keep all your passkeys inside an open-source manager (e.g. KeePassXC)

For first-party systems, passkeys are supposed to be stored in hardware storage (TPM chips, secure enclave, etc). Once it's in the chip, the secret key's never coming out of those pins again (unless you're a nation state with a tunneling electron microscope and a very steady hand).

(The huge exception is iCloud Keychain and whatever Google's doing for passkey sync, but that's importing from account data into hardware storage, not exporting existing credentials from a user's existing device)

If the website is momentarily down how are you going to access it with a password at that moment? You'd have to wait until it came back up. And then you could just as well set up the passkey.

- Apple's iCloud Keychain syncs across devices

- Apple has APIs that allow third party apps to create and offer passkeys, presented as a first-class option in Apple's authentication system. I use this to sync my passkeys between my Mac, Windows PC, and iPhone.

...as long as you always keep buying apple.