Hacker News Reader

Comment by Ajedi32 | Hacker News Reader

Is it even a good idea to use physical security keys as passkeys in the first place? Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them.

IMO physical security keys are better left as second-factor authentication, to be used _in addition_ to passkeys in certain high-security contexts; particularly where resistance to cloning is a critical feature. Resident keys aren't necessary for that use case since by the time you get to the second factor step you already know the account you're trying to log into.

Further, the autocomplete functionality afforded by resident keys is important for the UX of passkeys in my opinion. I don't think it makes sense to sacrifice that in order to to retain backwards compatibility with a small number of keys that only security nerds use. (Though if there were a way to maintain that UX without using resident keys I'd be cool with that.)

View on HN

Yeah, this is basically my take. At this point, the idea everyone is converged on is that you have a locally encrypted secure "vault" of some kind, that you can trust, and you need to verify identity with that system, perhaps with a password and perhaps with a key. It is easier to have some trust that your password manager of choice is more secure, rather than having to assume that every service in existence you create an account for is secure (or unphishable.) So, by the time you use a passkey, you're quite often in a more secure context where you've already established that identity: to your operating system, to your password manager that owns your passkeys, etc.

It also seems likely that places that didn't support hardware keys now or recently probably wouldn't have supported them in the near future. But the ROI for a Passkey solution is likely much higher since the buy in (just some software support) is much easier for people to achieve. Of course, this is only true for websites mainly; a Passkey is basically the equivalent of "Standardized SSH keys" for a website.

I see hardware keys as more useful for second factors like actually unlocking your vault with your passkeys inside of it, which might also want a password. I suspect hardware keys still have a bit of life left in them.

The Passkey login flow is actually super, super nice now that I can use it on GitHub, Gmail, etc as a primary method.

Password managers have already made passwords obsolete. I literally don't know any of my passwords except my master one. Passkeys are an insanely overcomplicated solution we don't really need.

Browsers just need a simple HATEOAS API for password managers to hook into, and web apps expose some HTML that triggers the browser. The password manager can then determine how to authenticate the user (however the user wants!), auto-inject the secret for that website, and the user is automatically logged in. E-mail reset if anything goes wrong.

From the "we're a website that wants super fancy security" perspective, I get that they want something more complex. But there should be levels of security that the user can opt-in to.

For example: most websites are fine with a simple password hash, assuming the password manager uses random passwords. Any website can implement that, every password manager can implement that, and it's better than 99% of regular users' password use today. So there's your baseline auth method.

Then if you want something like TOTP, OIDC, public-key crypto, etc the server can advertise it, the client can opt-in to it, and authentication can continue. But not every site needs to implement it, and not every user cares to use it. Basically, we don't need every site and every user to use the most secure methods. We just need to make it easier to get a baseline of improved security, and allow people to slowly opt-in to stronger security.

Frankly I don't like the website getting to determine how I practice my own personal security: that's just the path of corporate lock-in, and it also has exactly one outcome - everyone will select either "maximum" because "that's secure" or "minimum" because "user experience".

It's the worst of both worlds (i.e. the insufferable thing banks do where they try to force you to type in your password with the mouse).

> Passkeys are an insanely overcomplicated solution we don't really need.

This is simply not true. WebAuthN is not overcomplicated needlessly (I wouldn't even call it overcomplicated, it's literally just a signed challenge/response dance). It improves on Passwords+2FA in a few notable ways:

1. It prevents shared secrets from traversing the wire.

2. It naturally enforces that users are all using secure authentication keys without password rules nonsense.

3. It kills 2FA by allowing Relying Parties to request user presence verification as part of the primary challenge.

4. It is origin-bound which mitigates phishing.

Passwords don't have any of these properties. And since your password manager handles the details for you, why wouldn't you want it to improve its implementation under the hood making things better for you with zero effort on your part?

Now do the passkey (or is it webauthn?) failure modes. They are a nightmare as outlined in the top post in this thread by dmix.

They're no different than a password manager regardless of what shitty tricks Google is trying du jour.

All of that is for naught if it's too much of a pain in the ass for normal folks to use.

I'm desperately looking forward to my password manager integrating support for Passkeys such that I can:

1. Back up my keys to paper and restore them from paper

2. Disregard/end-run around the "user presence verification" challenge if I want to.

I already deal with a ton of "acknowledge this push notification" or "type in this TOTP code" to verify, and automating every one of those interactions has lifted a huge amount of distraction and hassle from my everyday login-access dances interrupting me every hour or two.

I worry that more and more security people will make their orgs require authenticator attestation, which basically compares a burned-in cert against those certs blessed by FIDO. If too many websites submit to that stupidity, the idea that you can use your Bash-scripted password manager for resident key auth becomes a figment.

Primary issue with FIDO is not the specs themselves but the extremely confusing nomenclature that FIDO put zero effort into clarifying.

That is all way more complex than you're acknowledging. I bet you that for the hundreds of millions of dollars that will be spent every year on all of that crap, and all of the pain it will cause in a variety of ways, it will prevent maybe 1000 actual attacks globally per year.

Security does not need to be an arms race. Good enough is good enough.

BTW, Apple have announced a Chrome extension for iCloud passwords.

https://chrome.google.com/webstore/detail/icloud-passwords/p...

When I use a Yubikey for passwordless authentication (FIDO2), it challenges me for a PIN before asking me to touch the device. If I give it too many incorrect PINs, the Yubikey locks up and requires a device reset, which invalidates all previous registrations to use that key for authentication. It doesn't seem like a big deal if someone steals my hardware token.

https://support.yubico.com/hc/en-us/articles/4402836718866-U...

That's not how my YK works. When I go to a new computer and login to my Google account, it asks me to insert it and press the button. Did I configure it wrong?

If you're only using it for two-factor authentication, you don't need a PIN. But when I tried to registered mine as a passkey (passwordless authentication), my browser prompted me for a PIN. I didn't have one set at the time, so it kept rejecting whatever PIN I gave it. I had to use the YubiKey Manager to set a PIN before I could register it as a a passkey.

https://www.yubico.com/support/download/yubikey-manager/

You can also manage this from within Chrome (Privacy and security -> Security -> Manage security keys).

I use YubiCo Authenticator for TOTP via my YubiKey, and have a PIN setup due to that. Quite nice really, I imagine it's the same PIN you're talking about? I've not used it as a passkey yet

Yubico sells Yubikeys where are smartcard devices loaded with several apps (keyboard emulation OTP, GPG, PIV card, and FIDO 2).

They also sell cheaper security keys, which are purpose-built for FIDO 2 only.

When someone says they are using a passkey with a Yubico device, they are talking specifically about the FIDO 2 functionality. This does not (at least currently) support import or export - partially because they want these devices to be sold in regulatory environments where hardware-bound and non-cloneable credentials are required.

It's optional and can be required by the service. Services like Microsoft that use security keys as a single factor rather than as a MFA are more likely to require it.

Are you sure you have a YubiKey (e.g. a "5 Series"[1]) and not a YubiCo "Security Key"[2]? The latter is a less expensive device with less functionality[3], though still good for arguably the most common 2FA situations.

[1]: https://www.yubico.com/products/yubikey-5-overview/

[2]: https://www.yubico.com/products/security-key/

[3]: https://www.yubico.com/store/compare/

The Security Key models have an access PIN just the same.

Something I noticed after reading this thread is that Google basically converted my YK from a 2FA security key to a Passkey. I'm so confused.

Now that is annoying, and I wish companies would not do that without asking.

Yes, you need to use `ykman` to set a PIN. This also allows some services (really only Microsoft Accounts right now) to use "passwordless".

The idea is you register 2 or 3 passwordless keys on important accounts. Keep one in the machine, one on your physical keychain, and one in a remote location.

It means though that your secure hardware token has a reliable way where the secrets all self-destruct. That someone can easily do if they get even brief hardware access. For people who have a problem keeping sufficient backups (almost everyone on earth) this seems like a horrific blocker, a show stopper for this entire intiative.

I personally think these things absolutely should be able to be exported & backed up separately. Many people guffaw that now the device isn't secure. But I just don't think I could realistically adopt nor do I expect others will unless users get some better affordances, unless we get some capability to manage trust as we see fit, not just be pushed top down into someone else's desired much narrower security behavior.

(Thankfully it seems like there is building interest in exports & portability, particularly as the OS/browser powered PassKeys arrives.)

> I personally think these things absolutely should be able to be exported & backed up separately.

I agree. The usual response is that you don't need to do this because you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup.

But managing that sounds like a real pain in the butt to me (honestly, the entire passkey system sounds like a real pain in the butt to me -- but that bit particularly so).

But it looks like the major companies recognize that this is an issue and won't be requiring that part.

It'd be awesome if you could ask to enroll a variety of other devices all at once, without having them on hand.

Requiring ongoing physical access to your crucial backups to do any account enrollment or changes seems like a way to make sure you have your crucial backup way too close to potential disasters. Ideally I wanty backup keys many states away from me. But then I can enroll them!

But it feels like there could be some kind of pubkey for those keys that I could also enroll at the same time as I'm getting my first device.

Except these devices don't have just one pubkey cause that wouldn't be secure. Maybe they pre-make & share 20 keys with a peer device or something. Somehow though data needs to at the end be able to get into the backup/other device too though. Ugh it's wild.

That would certainly be very convenient, but it would also retain/reintroduce several of the security weaknesses that passkeys are intended to mitigate.

The reality is that security is really, really hard. And it remains as true as ever that increased security comes at the cost of decreased convenience.

My personal attitude is that I make different security/convenience tradeoffs for different things. I do have and use hardware keys for very sensitive things. But they're rather inconvenient, so I don't use them for most authentication purposes. Does my account here on HN really need to have the best possible security? No, it doesn't.

So, in my opinion, both passkeys and the traditional username/password mechanism should be supported for most of the web. Which is likely how it's going to be for a long time.

I can see how remote enrollment makes it easier for a user to share a key in a way they shouldn't, but not all that much easier.

What other weaknesses will be introduced?

The ability to do auto-enrolment would break the per-site uniqueness of credentials (which makes them pretty strongly phishing resistant under most sane threat models where the browser isn't totally compromised)

Right now, the public key from one token is unique to that site (and specifically your registration attempt with the site, so you can have multiple unlinkable accounts using the one FIDO2 key). If you could do an offline and remote enrollment, you'd need to work with a single static public key (and corresponding private key) for all sites.

Despite all this, I still think this is a use case that's important - both the ability to have an offline backup key (even pairing all your tokens together at setup time to use a common internal root AES key wouldn't help as there's an anti replay counter in FIDO authentications from what I recall), and the ability to use passkeys portably across vendor ecosystems, without relying on a single ecosystem as your trust root.

There are some assumptions in your explanation that I'm not following.

For one, you could generate a new unique private key for the site login, and then encrypt that with the other device's public key. And you could sign it with the active device's key, so that third parties can't try to send you enrollment data.

If desired, you could handle this encryption in a way that makes it impossible for anyone else to tell what keys are being used.

Or instead of generating a private key, you could securely send a single-use token to the other device, and that token allows it to register.

Either way the fixed public key would only be used once, and only directly between the two devices. It doesn't get tied into the site authentication process. And you could replace or augment it with a symmetric key that's unique to that device pair.

> would break the per-site uniqueness of credentials

It wouldn't break things as I've described it. Each device would have a handful of pre-negotiated single-use public keys for the other device it could enroll with.

I tend to think there's no blockers and I just invented a better+obvious flow.

> It'd be awesome if you could ask to enroll a variety of other devices all at once, without having them on hand.

This is one of the feature goals Yubico said they want to implement.

> you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup.

The most common case where people are willing to spend $50-100 for extra security is businesses securing their networks. If you lose your passkey just stroll on over to the help desk and show your id and they'll enroll a new one for you.

If you're an individual using a passkey with free online service, like Github, just enroll a TOTP key first and print out the QR code. Then if you lose your passkey you can use the QR code to get access to your account.

True, but that just increases the inconvenience of the whole process. I'd do it for things that need very high security, but not for anything else.

> ... you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup.

Just some problem: As a backup, I would prefer to store it _away_ from my main hardware key. Everytime I sign up a new service, I need to go fetch the backup and update it...

Yeah the best would be if you could use one key to bless another as an explicit backup key in advance.

I struggle with this on a lot of 2FA. I change my phone every 1 or 2 years when I get an upgrade and the 6 months after I end up having to keep my old phone around to handle the 2FA apps that can't be ported over, it is incredibly annoying.

For me allowing a weak 2FA that moves you from the pool of people that can be trawled to the people that need to be specifically targeted is a huge improvement, but my fear of losing access to critical systems because I lose my phone fills me with dread.

Your 2FA app of choice doesn’t support export/import?

I was forced to create my first ever Microsoft account to be able to back up my Microsoft Authenticator app. I struck a small blow in return by using a very rude email address for it.

Wait until your account is flagged and disabled for violating some TOS that says to "be nice" or "be civil".

I use Aegis Authenticator on Android which does encrypted cloud backups, so changing phones isn't much of a problem.

I also only keep critical accounts there, the rest goes into Bitwarden. I realize this isn't as secure, but with those accounts I wouldn't even bother with 2FA otherwise.

If someone hits my cell-phone with a hammer a few times, it will probably self-destruct all the secrets.

Quite unlikely.

You can import onto a yubikey. At least the GPG keys which is basicly all I use it for.

GPG yes. Fido no.

Yubico has said that they're working on a standard to export passkeys and that future products will have that feature once the standard is decided upon.

If you think about it, the core problem can be described as "authentication of the biological being with an electronic system".

When passwords are used, the authentication interface is a keyboard and you don't have any actual guarantees that the person typing the password is the person who claims to be. The passwords could have been extracted in so many ways because it depends on easily transferable knowledge.

Moving the authentication interface to device2device is actually much better, you no longer assume that the easily transferable knowledge was not transferred. Instead, you assume that the biological being is capable of keeping track of the authentication device and people are naturally good at it.

You can increase the number of authentication channels to tighten it up a bit, you can restrict the authentication of the biological being with the device(FaceID) which will be used for authentication with remote systems but at the core I think it feels right to assume device(phone, key etc.) means the person.

It's also quite a human thing to do. At home, we share not only the Netflix password but one of the credit cards. For practical reason, one credit card stays with the spare keys and when there's something to buy for the house anyone can grab that card and use it. We trust each other that the card would be used properly, everyone knows the pin code but that's rarely needed since contactless payment is the norm anyway. It's much more natural than keeping track of the expenses and then pay each other the outstanding amounts. However, It's probably illegal and if the bank finds out about it, they will cancel the card.

IMHO, the IT systems desperately need to approach human behaviour by working in analogous ways with the real world. Since I'm involved with IT systems I don't struggle most of the time but people who are not that tech savvy are having hard time figuring out daily stuff like What is the iPhone's password for, What is the iCloud password for, what is the Gmail password for, why I need to enter a code in WhatsApp etc.

Actually, I think I struggle too - I never came along to understand Mastadon. I'm prbably defenceless against phishing attacks on Mastadon, I will type whatever the screen tells me to type.

> it's probably illegal and if the bank finds out about it, they will cancel the card.

In the US, anyway, this isn't illegal unless you have to sign something and sign someone else's name. So just sign your own (nobody actually checks signatures).

It might be against the CC issuer's terms of service, of course, but that's a whole lot different from being illegal.

IIRC if you give someone your card your authorizing them to charge the credit account. The bank is totally fine with this as long as you pay the statement.

> IMHO, the IT systems desperately need to approach human behaviour by working in analogous ways with the real world. Since I'm involved with IT systems I don't struggle most of the time but people who are not that tech savvy are having hard time figuring out daily stuff

I'm pretty much the website key master for everyone in my family. Since nobody else is "in computers" they really don't have a clue about what things need passwords and why. They would NEVER voluntarily complicate their lives with 2FA or even with a password manager. If it wasn't for me, they'd just use "hunter2" and share it across every single device and service they use. If I told them they couldn't just type in their Netflix password when Gmail was asking for a password, they would just look at me exasperated, like I was making their lives difficult.

The security community really needs to get a grip and start designing systems that are compatible with the extremely low-tech-interest population if we even have a hope of securing systems. If I knew what the solution was I'd be rich.

> The security community really needs to get a grip and start designing systems that are compatible with the extremely low-tech-interest population if we even have a hope of securing systems. If I knew what the solution was I'd be rich.

Most of that population seems to do fine managing house keys, car keys, locker keys, etc.

You sure about that? I inherited what feels like 1,000 keys when my in-laws passed away. Who the hell knows what any of them are for, and they sure as hell didn't.

...and from this you're concluding that keys are a broken technology?

It doesn't seem realistic to expect to build a tool that nobody misuses.

True but online accounts are usually in the dozens for most people so thats definitely more of a burden. Also, its a mental load while physical keys carry the "password" physically.

I have hundreds in my password manager.

99 percent of people dont use password managers

Which is the magic of UAF: you have one key that opens all the computing doors.

> Most of that population seems to do fine managing house keys, car keys, locker keys, etc.

I’m gonna have to disagree with you there.

People are constantly losing their keys prolly about as much as people reuse the same password for multiple services.

I can't imagine that anything less than subdermal implants will be reliable, for some people.

If the implant fails, you can just go back to the government office / mega corp, show your DNA, and get a new one.

On further reflection, person a) has an evil twin who steals their identity, and person b) doesn't trust the government / mega corp. Back to the drawing board.

> People are constantly losing their keys prolly about as much as people reuse the same password for multiple services.

But when they lose their keys, they have a pretty clear mental model of the security risk and how to mitigate it.

What happens when you lose your passkey?

Exactly.

There is nothing to remember except to bring the damn keys. Once they're in your pocket, you're done.

Yeah, except physical devices get lost, stolen or damaged. So there needs to be some accounts recovery procedure/alternative auth mechanisms.

...and there are, and they're remarkably similar to what you do with Yubikeys: you have extra keys, and when you lose one, you uses the other to get in, and then you invalidate the old keys (although in the physical world, this means getting a new lock and a new set of keys, instead of just getting one new key and removing the lost key as a valid key).

Except you'd have to invalidate a yubikey on countless websites.

I mean, if you're using a key to get in to countless physical things, then you have the same problem.

Do you have countless homes?

I do not.

None of the locks for my home are on a network where you can broadcast key updates either.

I also tend not to have one key that can access my house, my car, my safety deposit box, my safe, my bike, my locker, etc.

Because they don’t really have any other choice. You get a key with the lock. Even if they all happen to be the same blank, it’s substantial work and expense to get them all keyed alike for most people.

Maybe that’s our solution right there—when you register for a service instead of relying on users to select a secure, unique password we should generate a “correct horse battery staple” and only support rerolls, not setting arbitrary passwords. Guaranteed some minimum level of safety and complexity and no reuse.

> Because they don’t really have any other choice. You get a key with the lock. Even if they all happen to be the same blank, it’s substantial work and expense to get them all keyed alike for most people.

You have lots of other choices. You could use combination locks, time locks, biometric security measures, paired keys, etc. The simple key-based lock seems to be particularly simple and accessible to consumers.

Maybe the netflix password isn't so vital?

> Instead, you assume that the biological being is capable of keeping track of the authentication device and people are naturally good at it

That seems a dubious assumption.

It's far more often that debit/credit cards are physically lost/stolen than digitally lost/stolen.

(The only thing preventing cards from being a massive day-to-day issue are very aggressive fraud-detection systems and financial controls.)

Is that true though? AFAIK they sell CC info for pennies.

The good thing about the physical device is that you can easily tell if it's stolen.

For passwords, there are numerous services that keep track of the leaks and even Apple has incorporated that into their password manager but it all depends on mass leaks to work.

> Instead, you assume that the biological being is capable of keeping track of the authentication device and people are naturally good at it.

This is not something that people are good at.

Why do you think that?

I have some experience with people trying to keep track of objects.

Can you describe your experience? I know what you mean but if you describe it, I think we will be able to examine the implications.

All of the following are routine. We will name our example person "Bob".

1. Bob owns an important item. He believes that he knows where it is. He is wrong.

2. Bob owns an important item. He is well aware that he has no idea where it is.

3. Bob owns an important item. He knows where it is. He is right about where it is. Unbeknownst to Bob, other people frequently borrow or otherwise meddle with his item.

4. Bob has taken his important item with him, for security. Unbeknownst to Bob, it fell out of his pocket an hour ago.

5. Bob used to own an important item. When he cleaned his house, he confused it with a different, unimportant item, and he threw it away.

> Passkeys are meant to be a password _replacement_,

No. Passkeys parasitize on FIDO2 U2F standard, that was developed to be (as the name implies) the second factor. Resident keys are meant for on-device 2FA with PIN, a functional replacement of smart cards.

Someone (Apple maybe) thought it’s a good idea to consider WebAuthn being good enough to be the only authentication factor (no resident keys, no hardware bond, keys are roamed via iCloud) but TouchID/FaceID protected on device. And they branded them as passkeys.

> and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them.

You don’t. 2FA is not a goal on itself. The goal is to have user authentication that is protected from phishing, brute force and credential stuffing, and also not as hard to implement as smart cards.

FIDO2 does that. The problem with Apple’s, Google’s or Microsoft’s implementations is not that they are less secure on a protocol level between the authenticating site and the user’s device, that’s exactly the same protocol. The problem is that the site has now to trust user’s personal account in one of these platforms and that the user did the right thing and also the platforms will always be doing the right thing - e.g., they will handle attacks on user’s personal account properly.

> Passkeys parasitize on FIDO2 U2F standard

U2F authenticators and the U2F protocol cannot support passkeys. A passkey is a discoverable credential which supports user verification. U2F supports neither discoverability nor user verification.

Passkeys as a user-facing term is meant to describe a user experience. Second factor authentication using U2F is a different experience.

> The problem is that the site has now to trust user’s personal account in one of these platforms and that the user did the right thing and also the platforms will always be doing the right thing - e.g., they will handle attacks on user’s personal account properly.

That is in fact how passwords work today. You can't tell if my password came from my head or from a excel spreadsheet printout I carry around in my wallet; from a cloud synchronized password manager or if I use the same password for every website which will accept it (otherwise, I will add exclamation marks to the end until it does).

Microsoft Live allows me to sign in to live.com with nothing else but my Yubico Security Key. That's right, I don't even need to know my username; I just plug in the key and touch it and I'm logged in. And when I write "I" you should read "anyone who has physical possession of this key".

I think that's astonishingly bad opsec for a Big Tech cloud service. If I were a sane person, I would deregister that key as a FIDO2 device, but I guess I'll be OK for now. I shouldn't have posted this in public. This comment will self-destruct in T minus 10 minutes.

Microsoft is also the jerk who won't let me use the self-same key for logging into my Windows 10 Pro notebook, no how, no way. Windows Hello does not play nice with Yubico. My notebook has no fingerprint reader, and no infrared camera, so the Windows Hello alternatives are slim pickens.

Yes, that’s resident (or “discoverable”) keys the article author is talking about.

You don’t have to do it this way. I configured my Yubikeys to be the second factor and not to use resident keys. It’s possible, although I don’t know if Microsoft allows users to roll back from “passwordless” and discoverable keys.

I want to state it explicitly: FIDO as technology allows either. It’s particular platform choice to go with discoverable keys.

> Yes, that’s resident (or “discoverable”) keys the article author is talking about.

No, I said I'm using a Yubico Security Key. This is not a Yubikey. This key has no storage. How can it possibly store resident keys? The YubiKey Manager app can't even connect to this key. It's very basic, it has no TOTP slots, it has no configuration, it only does FIDO2. How would resident keys get in there in the first place? The article cites a strict limit on the number of slots, but it has zero slots.

Sorry, but Yubico Security Keys support up to 25 resident keys (https://support.yubico.com/hc/en-us/articles/360013647720-Se...)

You can use the Yubico Authenticator app's WebAuthn feature on the desktop to see resident credentials on their Security Key product, same thing with Chrome/Chromium's security key settings pane.

Nope. I have Windows Yubico Authenticator v5.1.0, and with the Security Key plugged in, all screens blank.

In Chrome 114.0.5735.199 on Windows 10 Pro, there is no "security key settings pane". The closest thing available is "Privacy and Security -> Security -> Manage phones (control which phones you use as security keys.)"

However, in terms of resident credentials, I thank the GP and I stand corrected, because Yubico's own specs say that this key sports 25 slots. I wonder how many are currently in use, and which version of the CTAP protocol it is using...

CTAP1 is only used for talking to old U2F keys.

Additionally, U2F/CTAP1 does not support resident keys anyway (IIRC).

So I just tried this with a blue Yubico Security Key with 5.4.3 firmware using Yubico Authenticator 6.2.0 on Linux, and I was successfully able to manage my resident credentials using the Authenticator after setting a PIN and saving a resident credential via https://webauthn.io.

I'd check your firmware versions, update your Authenticator, ensure you have a PIN set and ensure you're correctly saving a resident key on your device when registering with a service.

For Chrome, a visit to chrome://settings/securityKeys[1] should do it, but I just tried it in a Windows VM and it is not present in the menu, while it is present on Linux and macOS.

[1] https://chromium.googlesource.com/chromium/src/+/HEAD/device...

> It’s possible, although I don’t know if Microsoft allows users to roll back from “passwordless” and discoverable keys.

I don't know about Microsoft specifically, but it's possible to register the same FIDO2-capable security key with a service as both a passkey and a U2F token.

> And when I write "I" you should read "anyone who has physical possession of this key".

Add a PIN or password to the key and now anyone who has physical possession of the key will need to know your secret in order to use it.

Yubikeys, for example, will wipe their credentials after 8 wrong password attempts.

I've been trying to wrap my head around this and my layman understanding is that there's an assumption (but maybe not baked into any requirements/standard) that use of the hardware key is locked behind either a biometric check (FaceID/TouchID/etc) or password. In other words, there might be an implicit second factor baked in to the passkey itself.

A passkey is a discoverable credential (meaning - a website can ask the system for it without knowing who the user is first) with user verification (meaning, it can ask the system providing the passkey to verify the user).

For a platform like a mobile phone or laptop, this user verification might be a biometric or a system password/pin confirmation.

For a security key fob, they may have a fingerprint reader or a pin entry pad. Or, they may ask the browser/phone/laptop to prompt for PIN entry on their behalf.

One could imagine a wearable using a biometric scan, or even monitoring for continuous wear and only asking for a confirmation gesture/tap.

WebAuthn is an API to talk to authenticators, and authenticators are a box which could hold anything from a single factor to a full authentication process.

When using a resident/discoverable credential the authenticator is supposed to authenticate the user (using a pin, biometrics, etc.) This fulfills the multi-factor requirement. All passkeys/webauthn credentials are something you have and you can use a something to know/something to are to unlock the credential stored on the authenticator.

Platform authenticators have made it more obvious that some people took the multi-factor model as some immutable truth of the universe.

The modeling of authentication techniques as factors shows the strengths and weaknesses of the categories. The purpose of 2FA was to pitch instead to use authentication processes that counteract the weaknesses through layering.

Platform authenticators aren't just providing an authentication technique - they are a user-supplied authentication and recovery process.

Even understanding the entire workflow of that process, you may not have the ability to retrofit that into a _larger_ process to meet your regulatory and security requirements. But that workflow is actually per vendor, per device, configurable by the end user, and evolving over time.

This has been an ongoing problem for ages, because the 'knowledge factor' was actually often something the user didn't know, but something provided by a software agent (password manager) which had its own configurable authentication and recovery processes. It just eventually got ignored as people shifted to thinking of the second factor as 'the thing that makes up for all possible weaknesses of the password'.

IMHO this is why passkeys are pitched as a replacement for passwords, e.g. as a knowledge factor. It may eliminate your site's need for another factor if you were mostly concerned about phishing. It stops you from needing to use breach lists, and limits the impact if your credential table gets exposed.

It isn't a great fit for regulated/secure environments, which may still need to do all the same additional factors for risk mitigation or compliance. This is a very complex problem to solve, though - platforms are not going to want to act against their users' expectations, such as losing all banking credentials when you get a new phone.

> Passkeys are meant to be a password _replacement_, and for that you probably want the 2-factor properties afforded by phones or desktops which usually require "something you know" or "something you are" to unlock in addition to the "something you have" afforded by physically possessing them

Yes because the keys have a PIN just for this usecase. Similar to the ATM card or SIM card you already know

The impression that I get though is that the PIN's are typically short (especially if we have to enter them every time it is to access the key). Now, how physically save are hardware keys that the actual private key can't be extracted from them? In contrast to an ATM or SIM we essentially rely on the device to enforce the "max number of attempts", not an external entity.

Once the key is extracted brute forcing the PIN is not a problem, because it likely is going to be simple. Unless somehow the devices are going to enforce long PINs.

The PIN doesn't have to be long because the key will block itself after a very limited number of attempts. Just like with your bank card.

Extracting the key is another issue but the chips used in these are hardened. They are just like the secure element in phones.

Hardware security keys that implement FIDO2 UAF can be protected by PINs/passwords or biometrics, the former being "something you know", and the latter "something you are", with the security key itself being "something you have".

Until there is something like pre-registration ("here are all my keys from all my devices, trust them all" - not possible with current standards) mechanism - I suppose, yes?

I don't really understand if there's any other way to make all this work if not for portable authenticators. How one is supposed to log in from a different machine if it's from a different ecosystem that doesn't have the original passkey (e.g. log in on an iPhone if I've signed up from a non-Apple desktop computer)?

For the other direction (phone providing computer access), there is a hybrid flow. You select an option like 'use passkey from another device', and it will pop up a QR code. Scan that with your phone/tablet, and it will provide the interface to confirm and authenticate on your phone. That then lets your computer in.

Some sites may have flows to detect you used a credential from another device when your local device supports passkeys, and just prompt you if you want to register a second passkey to make things easier in the future.

There's nothing that prevents a computer from scanning a phone-displayed QR code to work in your given direction, except that it is not what a user would expect.

Dashlane and 1Password have support for providing passkeys via browser extensions, which provide different sync 'boundaries'. Android and Apple OS's both have beta API to provide these apps the ability to plug in at a system level. It's feasible that even Apple/Google could publish apps that use these API on one another's platforms.

> You select an option like 'use passkey from another device'

Is this a part of any standard? It most certainly not a part of any Webauthn spec, and sites I've seen that mentioned Passkeys did not offer this option.

This is implemented in various platforms/browsers, deployed over the last 10 or so months. I believe Microsoft may have added this in the latest Win11 previews.

I'll point to this somewhat random article for the pictures of it working on an Apple laptop (under 'Other options' in this case). https://www.pcmag.com/news/with-some-help-apple-passkeys-cou...

Realistically, I don't think this will completely replace Yubikeys, nor do I think that only "security nerds" use them.

In reality - the majority of leading organizations use Yubikeys to secure authentication across their company. While it's likely not as common for consumers, it is probably the most trusted solution in the enterprise today.

you can use yubikey 5s as passkeys

I don't see phones as being very different in terms of also being a physical security key.

I think the key (pun not intended) differences are that phones are something you'll always have on your person, Apple/Google will allow it to sync across devices, and phones require a pin/biometrics to authenticate with them.

Have you not heard of "SIM swapping?" [0]

The FBI (US) receives thousands of complaints, which I'm guessing means it's orders of magnitude more common.

[0]https://blog.mozilla.org/en/privacy-security/mozilla-explain...

Using phones as physical security keys != using SMS for 2FA.

SIM swapping lets you take over a phone number. It does not let you clone the keys stored in your physical phone’s secure storage / enclave / key storage.

So SIM swapping makes SMS verification vulnerable (that just depends on controlling the phone number), but doesn’t fundamentally affect iPhone/Android passkeys.

sim swapping doesn't move the authenticator app to the attackers phone, only your phone number.

this is why SMS-based 2nd factor has been considered insecure for years.

There are two separate problems - the first one is to make sure others don't have the access you don't want them to, while the other is to make sure that you/others have the authorized access.

SIM swapping means someone else might be able to have my phone number, but I'll eventually get this number back via legal means. So the number itself is something I own (at least in my country). Now if a site assumed this and phone numbers were meant to be constant, it'd mean I could always get my account back.

But of course this depends on which problem I consider more important. It's better to lose access to my FB account forever than to allow someone to gain access to it for a moment, because that might cause harm. Similarily, it's better to lose access to my bank account until I have to visit them in person than to lose all the money, but in this case the weakest link is probably not the key itself.

I'm quite concerned that phone numbers I don't own or addresses I no longer live at have legal "owners" and their friends/sublets who could decide to impersonate me with accounts that still have these old details, and its kind of hard to separate that from my new details having been the illegitimate hack.

I think most people wouldn't risk that unless they are pretty messed up and an average legal system to deal with that unless it is pretty messed up. A past residence in a mediocre city in the US provides all the crack heads needed for such a torturous comedy.

FWIW, some Yubikeys require a pin as mentioned elsewhere and some more expensive ones even have biometric fingerprint readers on the key.

Passkeys combat phishing and sell mobile devices that have secure enclaves, tho the mobile operating software is apparently syncing the master key between devices enrolled in the same subscriber account. However, during MOST urban assaults, phone theft/damage is among the first thing to happen. It’s why all of this phone-as-token crud combined with FaceID are bad ideas that put convenience above security. The government should be pushing everyone into a federal SSO so that this is not needed and so they don’t need to worry so much about encryption.

I'm not sure that a second factor was ever the goal of 2FA, but rather the desire was a key that users couldn't pick themselves (because they use their birthday, they tell example.com their Google password every time they log in, etc.)

That said, I don't feel great about letting security keys be the only factor. They can be stolen. So can phones, but phones make you unlock them before they'll be your password. (Windows Hello is the same thing.) That seems like the right balance to me. Your phone can authenticate that you are you; a USB dongle can't.

Modern security keys (made in the last 5 years or so) support CTAP 2, which will support setting and using a PIN even if there is no hardware keypad. The client system will prompt for the PIN before letting you use the credential.

Chrome I believe will walk you through setting up a PIN the first time if a site requests user verification, while last I checked Apple platforms require it to already be configured.

i think they could be great for websites i don't really care about and already use weaker passwords. but for important sites where security matters? nope

Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. For "important sites where security matters" they are literally better in every way than a password, it doesn't matter how weak or strong. You can use a pure software solution, and soon probably even your existing password manager, to handle them. Again, you should think of them as replacing passwords. You can still enforce post-authentication requirements like SMS or calls to known numbers, bank account deposits, magic follow-up links in a confirmed email, push notifications, etc.

SSH keys are the best analogy. "SSH keys are great for useless servers, but for important servers? no way!" No! That's exactly where SSH keys are most useful. And you also happen to encrypt your SSH keys locally with a password, don't you? This is the exact same principle, but applied to arbitrary websites. Nobody goes around randomly generating login passwords for SSH'ing into each and every server they use, and then pats themselves on the back.

> Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design.

Let's assume a "passkey device emulator" written in software; quite realistic IMHO for someone to use, considering the cost of hardware authentication devices (phones, YubiKey etc.)

If someone using such emulator gets hacked and has their passkey emulator data stolen, is there anything preventing a credential leak?

The software you're describing is called a "Password Manager", and several do support passkeys already in newer versions. There's no real "emulation." 1Password 8 supports them just fine, your browser has APIs so third-party software can integrate exactly for that. So, the answer to your question is pretty much "exactly the same scenario as your password manager getting leaked", which is basically unsurprising and already well understood when you frame it this way, I think.

The particular case I was referring to (and probably should have been clearer about) was when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use. But like, that's actually a major issue in practice, because the value of hacking a service operator is often far greater than just one user. That exact scenario was one of the motivations for using password managers in the first place, too, to mitigate operators getting hacked and common passwords getting reused between users, thus turning a single compromise for many users into multiple compromises for many users. So, it all has come full circle in a sense; now we've finally recognized that instead than shoehorning passwords into becoming psuedo-random strings that might as well be base64 encoded bytes from /dev/urandom, you might as well go "all the way" and just get those raw bytes from /dev/urandom directly and then use them as key material for a public key exchange.

Again, the best analogy is to just imagine that you used SSH keys to log into a website. That's all this is. It's software. Then you remember: oh yeah, SSH key synchronization and enrollment across machines sucks ass, and normal people would hate doing it. Hey, you know what, we already use passwords to encrypt SSH keys -- so what if we added a storage synchronization layer between your machines to keep those SSH private keys synchronized, encrypted with that password, and stored using $FAVORITE_SERVICE_PROVIDER? That's pretty much it, in a nutshell. You just reinvented modern Passkeys. Most of the threat models at that point are well understood: what service provider or software to choose, how secure is the local encryption, should you use two-factor authentication to further improve unlock safety, etc.

> when a website operator gets hacked; in that case the only information an attacker gains from your user account is a public key, which isn't of much use.

How is that different from situations where a website gets hacked and all the attacker gets is a well-hashed version of a unique password? In either case it isn't doing the attacker any good.

It isn't, if the website implements it correctly, and the user uses a strong password, and there's a salt -- then yes, probably, they aren't getting much information. But if you could always rely on all of those, a lot of these problems would not ever be problems; alas, here we are, in this particular world.

And if passkeys were only equal to passwords in practice, it would still -- IMO -- be worth upgrading to passkeys because they're, for this case, a better foundational basis to work around (public key cryptographic authentication versus sharing symmetric keys), and less error prone for users and operators. But in practice they are aiming to actually be better, faster to use, and more secure since every Passkey implementation is basically designed around syncing (iOS 17 TBD) and device authentication, and they are phishing resistant, which seemingly nothing else can hope to solve so we just gave up on solving it and don't ever mention it because it's the users fault that they did it. (No, seriously, did we all just give up on that entirely?)

I will keep invoking the SSH key analogy, here. Very few people are paranoid about SSH keys being some weird psychological "trick" to take Freedom Loving Passwords away from them or whatever (not referring to you), and most people aren't splitting hairs over "Well, you know, if /etc/shadow and /sbin/login the system is set up correctly, and the machine is secure, then there's no real point to using an SSH key, because my password is safe on disk, and you can just trust that." OK, and? It doesn't matter whether you're logging in as root or a normal user, on your VPS or a friends box. People just use SSH keys instead. Everything works around SSH keys today. People do not want to deal with your secret key material. Passkeys are in many ways just SSH keys for the browser. There really isn't much here to think about when you look at it like this, because the whole basic idea has been around for decades now.

With passwords, the user choosing a unique password or the site choosing to use a recommended process for hashing passwords is proper hygiene, but requires knowledge and is a choice.

With passkeys, there is no opportunity to have bad hygiene. The user does not pick a password. The site does not have secrets to store unprotected.

If the device is exploited, they can also install a keylogger and steal regular passwords.

I think this would be where hardware based authentication via TPM or similar would be useful. This would allow the device to be taken over and the private key material would still be safe.

They could also look at your SMS and Email OTP.

The secrets in the password vault can be used to authenticate and change settings in various trusted systems, like configuring call forwarding.

Cloud-based backups or the local filesystem could theoretically be inspected for software TOTP secrets.

Responding to the potential for bad user choices and full compromise quickly gets you to the point where your options are separate hardware or requiring in-person confirmation. NIST 800-63-3 AAL3 is probably most appropriate to look at if your risk profile mandates this.

for my important accounts the password is long, unique, and not recorded anywhere, that is one way that passkeys are not better. there is literally no credentials to leak until i go login and type it where passkeys are recorded somewhere? otherwise how would they work. someone gets my private SSH key that is a bad time (which is why we password protect them, or at least you really should be)

to follow the ssh analogy, you (should) only use SSH keys to gain access to a unprivileged user account at which point you elevate permissions via sudo and another factor (password/MFA) and really theres an argument to be made the unprivileged account should have MFA for login as well.

nobody puts their ssh public key in the root account of a server and pats them selves on the back that its secure so why would passkeys be any different for accounts you truly need to be secure?

You seem to be making up a bunch of scenarios that aren't really relevant (what if someone did this and that with sudo, what if the bytes were stored here). You don't want to understand the actual security model, which is fine, but only on Hacker News can someone say with confidence "actually unphishable public keys that can't be leaked, are not good for security." Again, you might as well be arguing against SSH keys. That won't get topped for a while.

I understood the parent poster to be saying that since his passwords are unique and are not stored anywhere, then if his device were to be compromised, the attacker could only steal a password once it is manually entered, in which case it wouldn't automatically compromise his other passwords.

Conversely, if he were to use a password manager on his device to store passkeys, the attacker could compromise all his passkeys once one of them is used.

Admittedly, it is an unusual use case (I mean, how do you generate and remember unique, sufficiently long and random passwords without storing them anywhere?) but I can see how passkeys could be worse for him if this is really what he does.

*her, but correct.

I don't think a compromised device, and thus access to local data and potentially your password manager, is such an unusual situation, but at that point it is true you do have bigger things to worry about. A device like a computer is also far more likely to get compromised then a phone.

that all said its fairly easy to remember a 20-30 length unique password if you use a passphrase and only have a couple places that are "that important" such as banking, broker, icloud, email, etc. everything else can go in keychain

obligatory https://xkcd.com/936/

> *her, but correct.

Sorry.

> I don't think a compromised device, and thus access to local data and potentially your password manager, is such an unusual situation

Right, but what I meant is that it's unusual to have unique passwords for each service *and* have them memorized/not stored anywhere (well, sufficiently long and unique that if an attacker knows a few of them, it doesn't help him guess the others).

That's not what the vast majority of people do.

> that all said its fairly easy to remember a 20-30 length unique password if you use a passphrase and only have a couple places that are "that important" such as banking, broker, icloud, email, etc. everything else can go in keychain

Many of these services don't allow such long passwords where you can use passphrases. For example, both of the banks I use (in two different countries) only allow a fixed size 6 digit numeric password. Somewhat strict password length requirements are not very unusual.

> obligatory https://xkcd.com/936/

While funny, the problem with this xkcd, besides the password length problem, is that 1000 guesses per second is way, way, way underestimating how fast you can crack passwords nowadays if the service uses password hashing algorithms that are still commonly used. Billions to hundreds of billions of guesses per second is more in line with the right magnitude, given a couple dozen GPUs which can affordably be rented in some cloud service.

When you need to memorize passwords or passphrases for two to four services, you're already in the same entropy requirement ballpark as having to memorize one bitcoin seed (i.e. 128 to 256 bits, depending on how paranoid you are) and therefore you run into the same dilemma: if you can memorize it long-term, it means you don't have enough entropy, and if you have enough entropy, it means you can't memorize it long-term (easily/reliably).

Which is why all but the most clueless or the most paranoid (or those who can afford to lose it) store their bitcoin seed somewhere more permanent than their brain [1] -- unless, say, you only do it very carefully and only temporarily, e.g. if you need to cross a border with a large amount of BTC and you really don't want to attract attention, no matter how scrutinized you'll be (and even then it's probably much better to store the seed somewhere in some creative and imperceptible way).

[1] Bitcoin brainwallets were a lot more popular many years ago, but nobody recommends them anymore due to their severe problems: https://en.bitcoin.it/wiki/Brainwallet

> That's not what the vast majority of people do

and thats fine, but some of us do for the sites that are important, and that is better then storing something in a password manager weather it be passkey or password.

> For example, both of the banks I use (in two different countries) only allow a fixed size 6 digit numeric password. Somewhat strict password length requirements are not very unusual.

that is a problem with the banks, mine is happy with my 30+ one and has MFA. Banks that can't even support a decent password are unlikely to support passkey anytime soon

> way underestimating how fast you can crack passwords nowadays if the service uses password hashing algorithms that are still commonly used

if the provider (bank) is compromised and salted passwords leaked it doesn't matter, they have already compromised the bank and your account. And i still do not think you can quickly crack a password such as "This15aVERY!!securepasswordEH?!!?"? i could be wrong here

> if you can memorize it long-term, it means you don't have enough entropy, and if you have enough entropy, it means you can't memorize it long-term

not talking about bitcoin seeds here, just accounts.

like i'm not arguing against passkeys just that they have the inherent flaw of existing on a device/somewhere vs something that doesn't.

I agree with your post. I'd just like to add a couple of comments:

> if the provider (bank) is compromised and salted passwords leaked it doesn't matter, they have already compromised the bank and your account.

It matters if the only thing that was leaked/compromised was the hashed password database, but not much else.

In fact, the ones who leak the hashed passwords may not be the same as those who hack your accounts, just look at all the leaks tracked by https://haveibeenpwned.com and consider that anyone could download those hashed passwords and crack them.

> And i still do not think you can quickly crack a password such as "This15aVERY!!securepasswordEH?!!?"? i could be wrong here

You could be right, but I wouldn't be surprised if you were wrong here...

Decades ago, the "John The Ripper" cracker was already very good at cracking these kinds of passwords (when CPUs were single core and much, much slower, and it wasn't even possible to run software on a GPU).

John the Ripper was already capable of using many extremely extensive word lists (in different languages) to quickly run through many such passwords, and simply mutating the password by using l33t speak and adding a few numbers, symbols or using mixed case are extremely popular password strengthening techniques which the software was still capable of cracking very quickly, since that doesn't add much entropy.

Although at the time it probably couldn't crack such a "long" password, I'm sure this type of software has become better and the hardware has definitely become many orders of magnitude faster and more parallel, so I wouldn't be surprised if the example you mentioned is well within "can crack quickly and relatively cheaply" territory, even when using salt, as long as the service is using a traditional password hashing algorithm (and not one of the newer compute-hard or memory-hard KDFs).

I mean, to have an idea of the magnitude of the problem, the brainwallet cracking stories of a decade ago were already pretty mindblowing (even considering that it's a "no salt" scenario).

I don't remember the exact details, but I think there were cases of people using an airgapped computer to compute the SHA-256 hash of some obscure passage of some obscure book or poem in some obscure language and the bitcoins were stolen within seconds of being transferred to these wallets (although, yes, due to the "no salt" problem, it stands to reason that all of these wallets were pre-computed by the attacker).

But still, personally I'd feel a lot more comfortable just using and storing a completely random password with a perfectly known amount of entropy, just to be safe, and deal with the compromised device problem in some other way (such as having a dedicated password management device, like a hardware wallet, if you're really that paranoid).

you were the one that compared it to ssh keys and again: you do not secure root accounts with an ssh keys. Or are you arguing that you should just drop public ssh keys into /root and enable root login?

so how are passkeys are different then ssh keys? there is a private and public key, and if someone gets your private key they get access to everything it unlocks.

they can be sync'd between devices (ie from a secure to compromised), exported, etc exactly like a private ssh key

also i'm not here arguing against passkeys - just pointing out that a long, unique password used in 1 place, that is also not saved anywhere digitally and only exists in my head is going to be more secure then passkeys due to the nature of how they work.

Nobody allows password login to root accounts with ssh either, and that's effectively what using passwords is based on your analogy.

There's no reason you can't password protect your passkey, or even use a TPM or yubikey also.

Which is why the author mentioned using a pin or biometrics to unlock the hardware security device.

Physical security keys can have pins.

Reply on news.ycombinator.com