Live data from Hacker News

Passkeys will come at a cost

fy.blackhats.net.au

321–330 of 600 posts

Re: Passkeys will come at a cost

#321

Earlier quoted context omitted.

passkeys are really defined by the FIDO Alliance Based on FIDO standards, passkeys are a replacement for passwords that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices. Unlike passwords, passkeys are always strong and phishing-resistant. [1] https://fidoalliance.org/passkeys/

This does not tell me what a passkey actually _is_. The marketing around passkeys is absolutely infuriating.

>This does not tell me what a passkey actually _is_.

Right!

And that is why I submitted this on HN:

ELI5 Passkeys, Please:

https://news.ycombinator.com/item?id=36715358

Re: Passkeys will come at a cost

#322
post #86

Earlier quoted context omitted.

The point is you would have a different key on different devices, each of which can access your account. This gives you a backup, in fact a better one, because if one is comprimised and locked out you can still use the others. The main challenge is automating this process so you can properly mirror your keyring across multiple devices, which I don't think there's a standard solution to. So it would be a manual proces…

> The point is you would have a different key on different devices, each of which can access your account. How would you sign up a new service under this scheme? Enroll with one device, swap the hardware key, and enroll with the other key? What if two device are not in the same physical location?

At the moment, yes, that's the process, annoyingly. Ideally, you would sign up with one and then be able to automatically enroll the others, which is in principle possible if you don't use resident keys and instead each device has the public key of the other devices you want enrolled at the same time, but I don't think is currently supported by the standards.

Re: Passkeys will come at a cost

#323
post #268

I'm not a security or crypto guy at all. I found this very difficult to follow, and I suspect others might too. My questions probably seem weird to someone with enough background context to understand the post, but I am getting wrapped around the axle every sentence or two. > It all comes down to one thing - resident keys. How/why? What's the connection to passkeys or HSMs? > we need to understand what a discoverable…

I believe the primary point is that WebAuthn is being pushed to use a "passkey" model where each site creates a credential that consumes storage. Displayable site and user account names, a user record handle, and the private key all take up storage, along with a few other items. A mobile phone could store 10 thousand passkeys without breaking a sweat. Modern hardware keys might only be able to store 25 total in avail…

The discoverability argument is somewhat weak because your browser already stores and probably prefills the username.

About not revealing whether an account exists: A site could always reveal a set number of potentially fake handles. So say a user has two handles registered, and the set number is ten. If the account exists, the two real handles will be in the list, alongside eight fake ones. If the account doesn't exist, all ten handles will be fake, but it's impossible to tell which case you're observing unless you have the key matching one of those handles.

Re: Passkeys will come at a cost

#324
post #86

Earlier quoted context omitted.

The point is you would have a different key on different devices, each of which can access your account. This gives you a backup, in fact a better one, because if one is comprimised and locked out you can still use the others. The main challenge is automating this process so you can properly mirror your keyring across multiple devices, which I don't think there's a standard solution to. So it would be a manual proces…

> The point is you would have a different key on different devices, each of which can access your account. How would you sign up a new service under this scheme? Enroll with one device, swap the hardware key, and enroll with the other key? What if two device are not in the same physical location?

There have been many proven approaches how to solve this.

For example "blessing" the enrollment of a device using another one, potentially across physical locations (i.e. similar to what discord and steam did at least for a time as far as I remember).

> How would you sign up a new service under this scheme?

the same way you do now, there is no difference

Re: Passkeys will come at a cost

#326

Earlier quoted context omitted.

> You don't want to ever share the shared secret across devices (or back it up) Hard disagree there. I do not feel comfortable unless I can backup a key. Phones get lost/broken/stolen all the time. Is it less theoretically secure? Sure, whatever, but I am not James Bond.

That's what the one time use backup keys are for

yes, that too

and then use it with a backed up secure cold secret storage

OR (if you can, only for technical versatile people not a general solution at all):

as strange as it seems even with all the fancy new technology as far as I can tell the most reliable solution for long term account recovery(1) is to get a very small number of long ungussable one time use recover keys you encrypt in a blob and print out base64 encoded as a qr code(s) or similar and then put into a save, maybe in a bank, maybe more then one print

This solution while AFIK more reliable then any fancy technical solution is imperfect as in:

1. it isn't viable for everyone (i.e. you need a reasonable accidental damage save place which is preferable not in your home)

2. it requires the user to do the right thing

3. has some initial one-time time cost

This means it's not viable to be used for every single service.

Through you don't need it for that either, instead you can use it e.g. for a slow fallback to access encrypted blob storage in which you stored a database with one time code for resetting you various services. Then every time you sign up new services you extend that storage using you hardware bound keys and if you ever loose access to all hardware bound keys (unlikely to ever happen if you just act with a bit of care) you can go through the annoying process of getting you papers, scanning them, decrypting then and getting your one time reset codes.

Through now that I have already gotten way off topic, what I want is neither passkeys or having separate keys enrolled with tens of services. I want to have widely used standard interface where I can use the identity provider *of my choice* with *any* service (which is also easy to integrate for services).

There is AFIK no technical reason this doesn't exist and if we had that there wouldn't be any need for discussions about passkeys and password etc. Because for most people there would only be one or two logins + 2FA.

Re: Passkeys will come at a cost

#327
post #314
post #298

Possible solution: use your hardware security key to login to your password manager and use the password manager for Passkey login. (Disclosure: I work for a PM which implements Passkeys)

I don't want to store passkeys in my password manager, the same way that I don't want my TOTPs to be stored in my password manager. If my 1P/LastPass/BitWarden gets hacked/compromised/pwned by someone across the globe, they still can't compromise my critical services because they don't have my hardware token. I just have to rotate all of my passwords. If you store everything in your password manager, you've just turn…

Passkeys are not MFA, Passkeys are expected to be used as a single authentication factor.

Re: Passkeys will come at a cost

#328

Earlier quoted context omitted.

Because secure tamper resistend storage is expensive. I would even go as far and say from a security POV the best security key is the key which has 0 storage. Because in my experience any protocol which injects and stores a secure token into a security key/enclave/whatever instead of deriving it from shared secrets etc. has serious flaws. Sometimes it's fundamentally security flaws (like TOTP). Sometimes it's complex…

What do you mean by fundamental security flaws with totp?

it's prone to MITM attacks when setting up (in a way you are very unlikely to detect if done well)

it's prone to MITM attacks when being used (in a way you are very unlikely to detect if done well)

it's MITM attack vectors are not just usable with "on the wire" MITM but can be archived with social engineering making them IMHO pretty bad

it's also prone to certain kinds of brute-force attacks in certain situations and protecting against them without making your login trivially DDOSable is very very hard

from a security POV it's better then SMS but still a pretty bad design

Re: Passkeys will come at a cost

#329

Earlier quoted context omitted.

Using "something you have" as an extension to "something you know" is essentially the point of all of 2FA. That's why backup 2FA methods are essential; if it's not extremely hard to get access to your account(s) after you lose all of your second factors, 2FA is pointless and you could've just sticked to just using passwords. That said, passkeys aren't necessarily second factors; they can be a relatively secure first…

See, this where the metaphor breaks down. At no point was the phone "lost". The 2fa tokens are perfectly safe yet there's no way to get to them... even though you still "have" the things, you can't prove you have it. Which is why having 2FA _solely_ on a phone (like OP implies) is a bad idea. It's a fragile device that can easily render you unable to prove yoh still have it.

If I break my house key I can know exactly where the broken parts are but I still can't unlock my front door. "Broken" and "lost" are the same things here.

Of course you shouldn't rely solely on your phone, that's what the recovery keys any decent website makes you save or print out are for, or the other alternative 2FA options.

Re: Passkeys will come at a cost

#330
post #327
post #314

Earlier quoted context omitted.

I don't want to store passkeys in my password manager, the same way that I don't want my TOTPs to be stored in my password manager. If my 1P/LastPass/BitWarden gets hacked/compromised/pwned by someone across the globe, they still can't compromise my critical services because they don't have my hardware token. I just have to rotate all of my passwords. If you store everything in your password manager, you've just turn…

Passkeys are not MFA, Passkeys are expected to be used as a single authentication factor.

Oh and for SSH, SSH CA and short lived SSH certificate is the only right way ^^ (I recommend Hashicorp Vault for this purpose. It also works for the host key)
Post reply on HN