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.

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.

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

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.

The dark pattern about signing up for google pay is absolutely inexcusable though. Sorry you're going through 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.

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.

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

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.

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?

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?

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?

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.

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.

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.

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

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

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.

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.

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.

- 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.

Technically, by not being copyable, a resident key isn't a "Passkey," but that's just terminology and it serves the same purpose as a passkey.

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

Maybe they sorted all this out so it “just works”, but there seems to be so many potential pitfalls, that I feel like I’d need to spend weeks researching stuff and testing edge cases before I could feel safe using it. No one is going to do that.

With a password, I know it works now, and it will work in 40 years. I don’t have that same kind of confidence with a passkey. Even if it’s great, if people don’t adopt it in mass, it will fade away and be removed, so how deep do I want to go? This isn’t something I want to be an early adopter on, at least not for anything I care about.

What's supposed to happen is when you tell the site you want to use a passkey and one is not available to your Linux desktop's browser you are shown a QR code that you can scan on your phone. The login will then take place via the phone using your passkey that is on the phone for that site.

If you want to test to see if your browser handles this right you can do so at <https://www.passkeys.io/>.

Once you are logged in with your passkey from you phone you should be able to go to your account settings on the site and somewhere in there find an option to add another passkey. You can then add a passkey generated by your Linux browser or your Linux password manager if you use a password manager that supports passkeys.

Some will object that this is not good enough because they might want to login to some desktop they have never logged in from before when they do not have their phone handy.

That's probably not as big a problem as they expect though because unless you are using passwords you have memorized the same problem applies to passwords. I've got over 400 accounts in my password manager, almost all with long random unique passwords. That means I'm not going to be logging in somewhere new to any of those sites unless I've got access to my password manager, which in practice means unless I've got my phone or tablet with me.

Once on vacation I shattered my phone. Only time that’s ever happened and I happens to be away from home. I was able to get a new phone at the local Apple Store, but the only reason I was able to get setup and running again was I happened to bring my iPad, by sheer dumb luck. Other than using it for 2FA to get my new phone setup, I didn’t use it at all.

In my most recent trip I brought my recovery key with me, and know my password for that 1 account. As long as I can get into that, I can get everything else setup from there. But I need someplace to start to make myself whole again. It seems like PassKeys make that more risky.

FWIW I don't think that this makes passwords redundant in general, but with passkeys, password becomes a last-ditch safety valve to regain access to the account. Meaning that it can be generated, very long, and stored in a way that is optimized for safety and security over ease of access (like, say, an encrypted text file on multiple USB sticks stored in different physical locations).

Because surely such devices never get stolen, or dropped from a cliff.

The problem though is that you have to do this for every single site you access. So if you have 100 log ins and are switching PC or phone, you'll have to do this same dance 100 times in the next period. And of course, if you're switching because you lost your one device that was registered this way...

"Communicate over bluetooth" doesn't mean anything. What app or BT device would they be using? How would a PC communicate with a YubiKey over bluetooth?

I have no idea where you got this strange concept from, but registering multiple passkeys from multiple devices on the same account on a site requires no communication between the devices - it only requires a trusted device to approve the request.

No idea how Yubikey works, never used it.

But in general I haven't felt these are secure enough for the reason you say.

While my practical threat model today would make passkeys seem great, the theoretical future threat model in my head does not support it.

So the only real risk is key extraction, hardware key extraction is always possible but likely incredibly expensive, so for most threat models it is not an issue. (Software key extraction or side channels is a different problem which may be easier but in theory is not possible.)

- a PIN is hard to memorize, so people are more likely to use personally-relevant or common numbers, whereas a password can be easily be both complex and memorable - it's easy to burn through even 10 login attempts through any combination of temporary/permanent disability, stress, being drunk, damaged device... - a wipe-after-failed-attempts system is trivial to abuse, be it by a prankster or a real adversary - it's much easier to see someone's PIN over their shoulder or film them entering it

In my experience, that’s a notebook or piece of scrap paper next to the PC with all their usernames and passwords scribbled on it.

That being said, all of the friends and extended family members that I have helped with computer issues have chosen to save several passwords in their browser’s autofill. Yet, none of them knew that they could view and edit these passwords.

sure they do if, unless you want to be held in contempt of court for not providing the information.

In practice, juries will take a refusal to divulge a password as evidence of guilt, the cops will use it as an excuse for even greater brutality, the FBI is perfectly willing to hold you without trial for years on end, and in most cases they don't need it anyway because everything lives on someone else's computer and they're perfectly willing to hand your data over if they haven't already. Furthermore, because the defense is founded on the principle that the password serves as evidence that you owned the encrypted data, if the prosecution is able to prove that you owned the encrypted data in any other way, that protection goes away.

  > In Boucher, production of the unencrypted 
  > drive was deemed not to be a self-incriminating
  > act, as the government already had
  > sufficient evidence to tie the encrypted
  > data to the defendant

The State of Utah instructed the jury in State vs. Valdez to infer that a suspect was guilty because he refused to provide his password to the police. On appeal, the Utah Supreme Court ruled that he had the right to withhold his password according to the 5th Amendment, and he shouldn't face negative consequences for doing so. The state appealed that ruling to the U.S. Supreme Court, citing various other state and Federal courts which have made conflicting rulings on this same issue.

Sixteen states (Indiana, Alabama, Alaska, Delaware, Iowa, Kansas, Louisiana, Maine, Michigan, Mississippi, Nebraska, North Dakota, Ohio, Oregon, South Carolina, South Dakota, and Texas) just filed a motion asking the Court to hear the case: https://www.supremecourt.gov/DocketPDF/23/23-1020/307804/202...

Quoting that brief:

"[C]ourts have issued orders requiring persons to unlock devices or provide passcodes. But courts across the country are divided as to whether the Fifth Amendment bars such orders. [...] The Court should grant certiorari to provide guidance on how the Fifth Amendment’s guarantee against self-incrimination applies in the modern context of electronic devices."

The Court has yet to decide if they'll hear arguments: https://www.supremecourt.gov/search.aspx?filename=/docket/do...

More info/commentary here: https://reason.com/volokh/2023/12/14/is-compelled-decryption... (But I recommend going directly to the primary source material—legal documents in Supreme Court cases are very accessible, even to non-lawyers.)

Multiple people have been held in contempt for refusing to provide an encryption password by US courts.

I use Firefox as my browser and 1Password as my password manager. On my iPhone, I use 1Password + Firefox.

I look at https://passkeys.directory/ every so often and switch my logins from passwords to passkeys. This has included a lot of my common logins like GitHub, Google, and Microsoft.

There is a lot of confusing terminology. For some reason sites will say "login with Touch ID" or "login with Windows Hello" instead of "login with Passkey".

Aside from that quirk, I love it. 1Password syncs my passkeys between devices. I can use them both on my laptop and my phone. It would be inconvenient if I needed to login to a shared computer e.g. at a library or friend's house, but I don't do that often enough to care (though of course some people do, which is totally valid).

- PayPal only allows one passkey and don't support logging in with it on Firefox on Windows. You still have to use your password.

- Twitter only offers it if you pay for a subscription.

- Playstation Network doesn't implement usernameless, and still asks for your email to log you in with a passkey.

It seems like we still have some way to go before we figure it all out.

I can believe it's easy. But just knowing this doesn't give you any understanding of potential downsides.

Years ago I lost access to various stack-exchange accounts when Yahoo stopped offering Oauth services. Thankfully not a biggie for me but it soured me on relying on third parties for access to a given account.

I don't think we should consider passkeys failed already. The widespread rollout just got started, and the ecosystem hasn't had a chance to catch up. Give it some time, and see if things get better.

Additionally, it makes 2FA quite a bit more convenient.

Lastly it's the only way to login to my Georgia Tech account without opening an app on my phone which is absurdly annoying.

I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not integrate well with password less so it’s best to stay where I am until things settle out better.

Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password.

By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain. They provide no way for you to copy and paste the passkey into a website, as you can with a password; there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy.

A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login to a website, but the website has no way of knowing/proving whether that happened; they just get the password.

You reset your passkey the same way you reset your password, because passkeys are just passwords that have to be managed with a password manager. Some sites make it easy to reset your password, some make it hard. You know the drill; there's nothing new or different there.

If you're happy with your password manager, there's no real need to switch, but even very "sophisticated" password users have been known to fall prey to social-engineered phishing attacks.

Are you sure you're never going to copy-and-paste your password into the wrong hands? I don't trust myself that much.

Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager. I think all the password managers kinda like that, and there's something good and bad about it.

I think that's what you're getting at in paragraph 3?

There's no reason you couldn't have an open source passkey manager that allows you to backup and view the key if you really want to. SSH works just fine that way.

The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).

That's simply false, and there are passkey managers that allow this - KeePassXC for example.

Perhaps this is something I shouldn't be feeling, but this bothers me and I do not know why.

I can see that you might not want it exposed to the user to prevent social engineering but at the same time, if I can't view then I don't feel like I actually own it. Is there a mechanism that might exist to help me not feel this way? I am totally new to passkeys as a concept as well, but I understand the larger goal.

Do you have a source for this? After reading the W3 spec[0] this seems entirely antithetical to the Passkey model and additionally raises concerns about the integrity of hardware mfa devices.

[0]: https://w3c.github.io/webauthn/

This part right here is what I fear the most about Passkeys. I've read too many horror stories of people getting banned from Google (often for no valid reason) and losing access to all of their data. It is absolutely insane to hand over all your passwords to a company like this.

Best practice is to register two keys to every website. Keep one physically in a safe.

With password managers I would say the same basic practice applies. Make sure you have a working offline backup of whatever secrets you hold dear.

There are some sites that only allow you to register a single passkey for an account (AWS Console last I checked) but these should be getting fixed as it becomes more popular

Well, this sounds convenient. Keep the second one in a safe, but register a key to it for every website you use.

Is this a practice we actually believe users will carry out?

I don’t bother with a safe. I have one key that never leaves my home desk and another I have on my keychain. It’s trivial to register the second key when I am home.

Yes it is less convenient than a digital passkey but there is absolutely no way for a remote attacker to compromise it

There are so many apps that don't get this right. Make a login on the website, store it in 1password, and then try to login in their mobile app and it doesn't show up as a password because the associated URL is mismatched on the mobile app. Like mybank.com and auth.mybankmobileapi.com

Better yet, while on mobile, search for the entry of the desktop site and have it fill. 1password will ask if you want to update the entry for this site

With passwords and logins, it seems like there are far too many edge cases to draw a hard line to say they are locked in the password manager forever. Having a way to copy it out, or export, is also a way to ensure portability, if the password manager being used ever becomes bad and a different option is needed.

Password managers put users in a vulnerable position, as once a user is invested, they've got you by the short hairs. The thing that keeps this from being a big problem, is that there is always a way out. Eliminating this way out, or raising the barrier to exit, can temp these password managers to extort their users, which is not good.

This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in.

You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey.

It’s a different mental model and the key is in the name. Passkeys are like keys. You can have more than one.

At least that's how I understand it.

But not the second: on Github for example you can have multiple passkeys for the same account.

SSH keys are asymmetric such that I can make a public half available publicly and then use that to generate signatures of any challenge the server sends.

With passkeys either the server needs to store the value raw(making it susceptible to data breaches or malicious actors), or store the hashed value(making it impossible to do a challenge-response, and making it susceptible to MITM/replay attacks).

It seems to be all the downsides of SSH keys(aka losing it having implications), with none of the upsides, plus additional downsides(hardware devices can only generate 25 unique ones instead of using 1 and sending the public to all services with confidence it hasn't exposed any private info).

Vaultwarden + bitwarden client apps (for desktop/browsers) have passkey support, and i've been using them for a month or two without any issues.

That being said, bitwarden client apps for android and ios are going through a rewrite (from xamarin to native iirc), and are yet to support passkeys. However, the bitwarden folk said passkeys are the next feature coming to these apps.

[0]: https://github.com/dani-garcia/vaultwarden

This is a deep, fundamental flaw in passkeys. It's just another example of enshittification disguised as denying end-user control "for their own good." There is no for-profit organization anywhere that I trust more than I trust myself, and there's no threat model where it's more likely I'll be socially engineered into giving up my long random password than that I'll suffer data loss.

I feel like most of the replies to your comment talk about the technical aspect of it.

What’s stopping me is that I don’t have a mental model of the management of the passkeys for the whole lifecycle of my account. Can I use it cross platform? Can I allow someone else to use the same account? What happens if I lose or don’t have access to my phone or laptop? What if I die, can my spouse log in my accounts?

With username/password, it’s very clear what I need. I could write it on paper and give it to someone and it’d work. I feel more at risk of losing access to my accounts if I were to switch to passkeys, because I don’t fully grasp their long term lifecycle.

It's my understanding that you can't switch password managers without generating a new passkey for each individual service you use (I'm not an expert here, so someone feel free to correct me). That's already enough for me to not switch.

>Externally there are other issues. Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.

So those are the real risks.

OK, so the simplest way to understand is to first know about the previous generation.

U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes.

In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compromised machine. You get a separate public/private key pair for every account and website (so it can't be used to track you between websites) and that key pair can be used to authenticate with the website. A physical button has to be pressed to authenticate, keeping it secure even if an attacker has control over your keyboard and mouse. The browser integration takes care of letting the USB key know which website is asking to authenticate. U2F keys have to be used alongside a username and password.

For a variety of reasons U2F keys never really took off. Partly cost, partly the 'what if I lose it' issue, partly lack of uptake by websites, partly difficulty using them on mobile, partly competition from 'log in with google' type systems.

So the trade group behind U2F said "Hey, maybe we could just emulate the hardware secure element in the smartphone's OS? And while we're at it, we could save the username, and use fingerprint/faceid instead of a password, eliminate that tedious button press, and automatically back up the public/private keypairs to the cloud". They kept a USB option about for the sake of tradition, but it's on life support.

So that's the mental model of a Passkey: It's like an impossible-to-clone USB hardware secure element that does challenge-response authentication to websites. Except it's emulated in OS software, and is no longer impossible to clone.

Another way of thinking of it is: It's very similar to using the 'Log in with Google' / 'Log in with Apple ID' buttons you see on many websites, you're authenticating to a service by proving you have access to a cloud account. The implementation details in the background are very different, but the result is broadly the same.

This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.

Think an SSH key protected by a passphrase. Your passphrase isn't the thing that actually logs you into the server, its just what you use to unlock your actual key material you use in your SSH handshake. Your fingerprint/face identity is just your local unlock of the actual key material stored in some other secure enclave.

What kind of failures did you have for the nanos? They just became unresponsive? Did they suffer any obvious physical failure or any particular kind of event cause their failure?

Your face or fingerprint being out there isn’t a concern because that’s not, ultimately, the thing being used to generate the keys or anything.

It’s an ease of use function.

On iOS for instance, as I understand it, these are being stored in iCloud Keychain. Which has a password. The derived key for iCloud Keychain is stored in such a way that the system has access if you allow biometrics to be used.

Biometrics then simply allow access, in essence, not part of the encryption process. The password for iCloud Keychain is necessary to add those items on a new device. Your biometrics aren’t stored by Apple anywhere other than in the device.

Honestly I am blown away how few people on this site understand how this stuff works. It’s fascinating and I’m surprised more people aren’t interested in understanding it. But so many people assume the biometrics are being used in the encryption process and that if your face is somehow stolen your whole life is doomed. These features have been on Apple devices for what.. a decade almost at this point? More? The process for Face ID is the same as Touch ID. Developers make zero distinction between the two in code, as that whole process is passed off to the system and effectively results in a bool value (or access to the secure item requested). At no point does a developer ever get your biometrics data.

I don’t know how Android or Windows do it but it is similar enough I suspect.

The FUD around passkeys feels like some sort of propaganda campaign to discredit it.

I mean there is plenty of FUD, but at the end of the day it's not terribly exciting technology.

Seems to me I need to be able to log in with a password from any place (my phone, my machine, my office, my wifes phone, her laptop, my friends laptop, etc.).

I mean, who knows when I'll want or need to get into Something.

Also, my wife and I share accounts (such as Amazon). So, it needs to work seamlessly across all of her devices.

Then there's always the "F-with it factor" that I loathe. At least I understand passwords. Can (mostly) always recover a password (I recall trying to recover my Apple ID password -- they bluntly said "ok, but you have to come back in 2 weeks", so I was locked out for 2 weeks).

And, of course the level of patience my wife has with Technology is less than zero.

I rely on my Safari auto fill, when I use another browser, I just copy the pw from Safari.

And I don't use any of the cloud services. I have an iPhone, but don't use iCloud.

It's possible this was a Mac OS problem, but I don't think it really matters. Either way, this stuff needs to be absolutely rock solid and frictionless if normal people are going to use it safely, and it obviously isn't.

https://1password.com/product/passkeys

The super simple explanation is: SSH keys for websites.

You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc).

The website only gets the public key, so unlike password auth your secret is never given to the website.

When accessing that website, the website can send a challenge which your browser answers using your private key associated with that specific domain.

(I'm not a passkey expert and there are a lot more technical details to this, but this is my 10,000ft mental model of what's going on)

Passkeys are great for consumers who use one or two devices (or browsers - I also switch browsers frequently). For anyone with more than one platform or one device in their lives they suddenly become added complexity, because even though you _can_ have more than one passkey per account per service, in practice there are all sorts of weird edge cases.

They're just not mature yet, period.

Similar to SSH keys. No reason to use the same key on all your machines, use a different key from different places.

The passkeys on my laptop are different from the passkeys on my desktop which are different from the passkeys on my phone which are different from the passkeys on my main yubikey which are different from the passkeys on my backup yubikey.

Edited due to acknowledging people may choose a variety of alternative workflows.

You don't need to log in to every app on every device the instant you register a new account. Just make a passkey on a couple of devices that you're likely to have around and you'll probably have what you need when you need it. When I register on a new site that uses passkeys, I might create a key on whatever computer I'm on and a portable authenticator like my phone or my security token.

So, say I'm at home on my deskop, and TotallyCoolService has the option for a passkey. I'll make one on my desktop, and then go ahead and make one on my security token. Later I'm out and I want to check in on TotallyCoolService on my phone. No worries, I just tap my security token to my phone and I'm logged in. Later I'm in the garage working on my motorcycle and want to reference something on TotallyCoolService on my laptop and my USB token is in my backpack inside. No problem, I can sign in with my phone. Now I've got security tokens on most of my common devices and its not like I had to spend time gathering all of them at account creation.

I don't instantly run home to my desktop and log in the moment I sign up for a new site while out and about. But I do go and sign in eventually, even if only to ensure there's a backup key there.

Whether you do it eventually or do it straight away. Unless you can predict which devices you will have and which sites you will need access to at any given point, then it degrades to needing everything authenticated just in case.

Sure, M devices can be quite large, but the odds of me being at only one device and not any of my portable devices is extremely small. As long as I have at least one other device I've previously logged in to somewhat handy, I can still easily get in. Maybe that initial login is marginally more complicated, but IMO the ease of future authentications more than makes up for the small bit of initial friction the first time.

And in the rare instance where I'm suddenly on the moon and realize I left practically every other computing device and physical authenticator on another planet, I guess I just won't have access to a DnD tool. Oh well.

What allows you to tap your token on your phone and register a passkey-stored-on-phone registered with TotallyCoolService? Did you previously set your phone and token to be "mutually trusted devices" in some way?

Or what's preventing a thief from tapping my token on their phone to register it on TotallyCoolService?

Not terrible for anyone whose threat model is not targeted attacks. But quite bad for people whose threat model is exactly that.

This effectively makes it impossible to do what you’re saying. It sucks.

Every other site I've come across that supports these things supports multiple. What common sites support only one or two?

If he's storing his passkey in his password manager, it wouldn't matter that he lost the device. They can't get to it, it's AES-somebigassnumber-ed up the wazoo. If the passkey is cached outside of the password manager, then passkeys are a horrible idea, where you have to "go home and call the 800 numbers to cancel the credit cards", and worse still, people with few devices might end up in circumstances where they have no valid devices left to bootstrap access.

I am resigned to the fact that I will die with humanity never having solved the problem of passwords adequately, but being that I will live another two decades minimum, I will get to see two more of the stupidest possible non-solutions.

If an attacker managed to get root on my machine right now, they'd get my whole password safe as its currently decrypted and in memory. However, they wouldn't be able to access any of my passkeys.

Then they privilege escalate, lock out all your other devices after adding a new one, it's the same issue. And it's opaque, reinforces the ideas that users are too stupid to do anything right, so that we shouldn't even try.

Its in-memory on my physical hardware token or a TPM or a secure-enclave, which only activates and unlocks after a valid identity challenge (fingerprint, physical touch, face scan, pin, etc.) not my main system's userspace memory. A massively different target.

So this typically means when I get a new device I'll have my Yubikey in a bag or something with me for a while and pull it out from time to time. Eventually practically every site I use gets enrolled on the new device and I never actually need to reach for the Yubikey or my phone or whatever.

I don't really make any concerted effort to go through each and every account when I get a new device, it'll pretty much just happen eventually. When I do sign up for a new account that supports passkeys I do try and make an effort make a passkey on at least two devices though, often at least whatever device I'm using to initially register and my yubikey. Then I'll make a point to log in sometime in the next few weeks on another computer and create a passkey there. Eventually I'll probably end up logging in and making passkeys on most of my devices.

Needing to auth with an existing passkey is a major part of the model. If you could just log in and create a new passkey with just a regular password, what's the point?

Or you can use a third party password manager like 1Password or KeePassXC.

First, I had to figure out how to get the website to request the passkey. Then I had to figure out that I didn't want to use the browser's passkey but 1Password's, which is different on different browsers and platforms. And good luck if I'm on mobile, I don't think it's ever worked.

At this point I'm taking a break from signing up new passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).

PS: Why is it that no financial institution lets you use anything more than a SMS U2F?

The physical device can be password protected. So you have two step authentication: 1. your physical device 2. your password to that device

Phones are currently being promoted for various reasons, but I believe something like Yubikeys or other FIDO2 fobs will be a better device. You can have multiple of them, you can store one of them in your bank safe. Someone stealing it of you is proper theft which can be traced in a usual manner by police. Stealing is not enough because you still need the password. The difficulty of asking you for password remains equal to difficulty of hitting you with a wrench. You don't need to remember stuff anymore, because you can just use your physical keys. You will need to travel with those keys, but its just same as your house keys. It is probably an extra key in your key fob.

To add to it, the U2F/FIDO2 standard will make it vendor independent, and so no lock-in.

So my problem is that I keep forgetting which device, browser or app I used when I created a particular passkey. I'm never asked where I want to store a particular passkey and where I want it to be available. This is all an implicit function of a combination of factors apparently.

It's like misplacing my keys has been taken to a whole new level of abstraction :-)

Personally I only use devices that don't sync and can't be copied for security reasons.

> Stealing is not enough because you still need the password.

But then:

> You don't need to remember stuff anymore, because you can just use your physical keys.

How are these statements both true?

Phishing resistance is improved over what a good password manager can provide (unique passwords per site, checking web origin before providing options). Since WebAuthn is a protocol, the origin of the requesting site is stamped into the authentication response; even if the user had the option to override a passkey to be sent to a different malicious domain, it is meant to be rejected if replayed on the legitimate website. WebAuthn really needs an attacker to compromise the legitimate site or to compromise DNS and TLS infrastructure for phishing to be successful.

The uniqueness is really two benefits in one - you don't need to think of multiple unique passwords (if doing manual password management), or suffer with password complexity rules (if doing either manual or automated password management). It is just a public key, usually a P-256 curve point. The security of the user authentication process is abstracted upstream, so it is secured with the local password/biometric or via an activation PIN (same as password managers).

The breach resistance means that if XSS gets onto the page, if a hacker gets read-only access to the password database, it is still infeasible for them to leverage anything they gain to answer future authentication challenges. If your passwords aren't unique, a breach is a big deal and can create a lot of lateral movement. Even if they are unique, attacker visibility of the password means account compromise. The private key in a passkey is separate from the website infrastructure, so that attacker is not going to be able to authenticate from anything they observe.

The basic logic here is pretty clear imo. Passwords are still symmetric factors, and they're also completely unstandardized. So you still have to do a significant amount of manual management crap that should not exist, deal with UI that should not exist, and you still have to do some stuff if the other side (service provider) gets hacked. If we used bog standard pub/priv keys instead, then everything could become universally better. There'd be no need to worry about password policies, whether there is a character limit or not, how well and consistently individuals handle it, or anything like that ever again. Nor care if a site is breached, literally no action required because the site would only have the public key, they could publish it in clear text and it still wouldn't help attackers authenticate a single iota. Plus things like phishing and so on go away, because same thing, if the user has their agent browser to a malicious link or the like, and then it presents their pubkey, it still wouldn't do anything and the agent can't be fooled by similar looking to humans domains or anything. The agent would expect the service to present the proper signed request and anything else wouldn't work. Conceptually everything could be automated and standard without any sort of silo, all software could speak the same standard simple key format and everyone could back that up and sync it any way they wanted.

Unfortunately as is so often the case these days there's a lot of perverse incentives and players who can't resist the urge to try to add extra functionality in on top rather then just going for the low hanging fruit in a solid way first. So we've seen a confusing muddle, of existing players with financial interests who make money by helping lower the pain of the garbage that is password based mutal auth, those who see new chances to try to silo, those who want to shove in attestation and differences in password backing for good and bad reasons, mixing in concepts of hardware backing that are unnecessary, etc. I'm still hopeful something will come out of it in the end but it's been a real bummer to see how it's played out.

1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password

2) In the second case when one service is breached you'd still have to manage rotation of public key somehow, how trivially is that done with current implementation ?

Why would you need to rotate your keys? If they're storing passwords/hashes it makes sense to rotate because they might be able to brute force the hashes on a GPU cluster, but you're not going to be able to brute force a randomly generated public key.

That sounds like a totally separate threat compared to "when one service is breached". In your last comment you were talking about your password manager being hacked, but in the post before that you were talking about the service (ie. the website you're using) being hacked?

Also, while I do agree that if your your password manager database were hacked you would need to rotate both passwords and passkeys, but I would hope that occurs far less frequently than some random service you use getting hacked.

I think I really need to implement it myself at least once to really grasp it. Maybe that’s stupid/slow of me but that’s how I learn best.

Here’s the issue: when a site rejects my password, I understand the potential reasons—wrong site, wrong account, or forgotten password update. But what does it mean when a passkey fails? How can I resolve this? Is it even fixable?

My lone attempt to use a passkey for login involved an unrecognized fingerprint authentication, leading to repeated failures and ultimately, a return to traditional passwords due to the opaque nature of passkeys.

For now, I’ll stick with what I understand.

Currently, I view the entire paradigm as asking me to trust resources (software, hosting, etc.) that I am not ready to trust. Both from a knowledge standpoint, or lack thereof on my part, and out of experience. Re the latter, third party resources die, go bad -- technically or morally -- and... just observing the nature of "online" resources over years and now decades.

I haven't been into passkeys as you see, but some easy login like that leaves me with a lot of questions.

- Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.

- Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up. So the passkeys are stored encrypted on disk, and the decryption key is stored in the keychain/keystore. Other options include passkeys actually stored in hardware (eg. Yubikeys, but then you can't back them up) or 3rd party password managers.

- Login: It's pretty seamless, just click "login with passkey". The browser handles finding the right passkey, and part of the signed challenge includes the domain the passkey is for, preventing MITM-style attacks. There's also a whole separate thing for authenticating a session on a different device via scanning a QR code or Bluetooth.

Here's a good fairly high-level breakdown of how it all works, if you want some additional detail: https://webauthn.wtf/how-it-works/authentication

As the article stated: "I want you to remember this quote and it's implications. Users should be able to use any device they choose without penalty."

As you've pointed out:

>> Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.

and again:

>> Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up.

How can I get my passkeys and back them up on my own storage media? (e.g. USB drive, encrypted cloud storage, burn to a disc, etc.)

How can I import passkeys generated elsewhere?

If you cannot backup or import the passkeys, then you do not control them. They are not your passkeys--they belong to Google or Apple, etc.

And as the article states, in most cases these passkey providers do a piss poor job of managing their passkeys that they claim belong to you.

It's probably possible to extract passkeys from a rooted Android device, but it would definitely be out of the grasp of 99% of users. I have not looked into it in detail, but I'd expect a Frida script hooking the keystore decryption function would get the raw data, then it would be a question of interpreting whatever proprietary format Google is using for their password manager.

Besides, give the Silicon Valley venture capitalists and Harvard MBA bros a whiff of the possibility of full control over something as important as your primary authentication material and before you can whisper Richard Stallman they're out having a happy Bacchanalia toasting the name of Portunus [1], whom I will now resurrect out of our ancient past to name him the God of Platform Lockin, and us users aren't going to get a word in edgewise over the debauchery and slides projecting Total Addressable Markets.

Fortunately it seems they all got a little too drunk with power this time, but honestly it's only a matter of time before they arrange another Portunus summoning lock-in party again. This target is irresistible and the annoyance people have with passwords is too good an angle to pass up.

[1]: https://en.wikipedia.org/wiki/Portunus_(mythology) And yes, I am aware of the stream-crossing between Bacchus and another god here. But who knows what a Portunalia even is any more?

A "corporation of one" is still just me, so I'm not talking about trying to technically hack around things by pretending to be a corporation.

When you see it this way it becomes really clear that Google, as a corporation, is an absolutely atrociously awful company to be the ones holding the keys to my identity. But there aren't any good, big, easy, safe options. I need to be able to self-service. Or we need to create much smaller, more local (in some sense, not necessarily geographical) holders of the auth material that I can convince I am me and they can reset it if something goes wrong. But that gets into a complicated web-of-trust and that's never worked out.

Every actual HSM I've ever used allows some sort of encrypted export. But actual HSMs are expensive and PKCS#11 is a terrible API so they suck to use.

To note: the key to start a car is provided with the car with no specific operation, is locked to no other device, doesn't care about who's handling it, can be duplicated and passed around. It would be closer to the traditional password system in all of its aspects IMHO.

To me the best explanation was just to go to the passkeys.io site, the subject is complicated enough that analogies tend to introduce a lot of cognitive noise IMHO.