Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passkeys will come at a cost

fy.blackhats.net.au

Post reply on HN
Print view View original

371–380 of 600 posts

Re: Passkeys will come at a cost

#371

Post by ericjmorey »

forty wrote: post #327
slau wrote: 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.

The passkey security model is designed with the assumption of the passkey ties to a device. Using a password manager that's tied to a centralized service that's accessible from any web browser with an internet connection makes the security model different. It seems to me like a passkey on a password manager is no different than a username and password with NO 2FA security model.

Re: Passkeys will come at a cost

#372

Post by ngrilly »

> Now, the primary difference here is that resident/discoverable keys consume space on the security key to store them since they need to persist - there is no credential id to rely on to decrypt with our master key!

The article is glossing over the biggest drawback of non-resident keys: If you lose your security key, you lose your master key, and you can't decrypt anymore the credentials sent by the relying parties. To mitigate this, you need to register at least two security keys, and stored them in different locations. But wait, how can you register both keys in a new service, while keeping them in different locations?... I don't have much experience with those keys: am I missing or misunderstanding something here?

Re: Passkeys will come at a cost

#373

Post by dwaite »

iFreilicht wrote: post #323
dwaite wrote: post #268

Earlier quoted context omitted.

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 ex…

Fake handles are possible, but nobody has attempted it yet that I have heard of.

There is no standard for credential handles (unlike what the article implied), so through heuristics you may be able to get some knowledge of which authenticator created them - and might be able to detect fake ones. You might want to pad both real and faked account lists to have the same number of returned values. These fake handle lists would also need to have some sort of heuristic to them - real accounts can change slowly over time, while fake accounts would be simpler to either always look static, or to regenerate on every call.

The system optionally saving a username is a nice convenience but doesn't really solve any deployment or security problems. Sites would be unable to rely upon that, and it doesn't help with information leakage.

You can save credential information in the client outside a security key and use that to 'upgrade' to discoverability - but you then have that security key only function on certain websites when using that client. You brought your own security enclave but are still platform-bound.

Re: Passkeys will come at a cost

#374

Post by dwaite »

drdaeman wrote: post #258
dwaite wrote: post #245

Earlier quoted context omitted.

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 s…

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

Re: Passkeys will come at a cost

#375

Post by JohnFen »

ngrilly wrote: post #372

> Now, the primary difference here is that resident/discoverable keys consume space on the security key to store them since they need to persist - there is no credential id to rely on to decrypt with our master key! The article is glossing over the biggest drawback of non-resident keys: If you lose your security key, you lose your master key, and you can't decrypt anymore the credentials sent by the relying parties.…

I think you understand it right. Or, if you are misunderstanding something, I am misunderstanding as well.

Re: Passkeys will come at a cost

#376

Post by wkat4242 »

cycomanic wrote: post #289
wkat4242 wrote: post #173

Earlier quoted context omitted.

> 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 PI…

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.

Re: Passkeys will come at a cost

#377

Post by wkat4242 »

0x4e53 wrote: post #216
wkat4242 wrote: post #199

Earlier quoted context omitted.

Apple doesn't do attestation so if you require that you're already leaving out the biggest platform. But it's a bad thing for self hosters anyway. Because parties will make exclusive deals or only wish to deal with authenticators they trust (eg that pay them for 'certification')

At least for the enterprise - this decision should be up to the company. (i.e, flip a switch on your identity provider to enable or disable support for "no attestation") Some companies are comfortable with the idea of a two-factor method that can be airdropped to friends. Major organizations (AWS, among others) are not huge fans of passkeys for enterprise use. When passkeys released, our initial response at AWS was t…

Well for the enterprise yes, but they shouldn't force these decisions on their customers.

They can provide the total hardware package for their employees to sign in with anyway.

Re: Passkeys will come at a cost

#378

Post by JohnFen »

dmm wrote: post #205
JohnFen wrote: post #118

Earlier quoted context omitted.

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

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

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.

Re: Passkeys will come at a cost

#379

Post by dcow »

eep_social wrote: post #237
dcow wrote: post #217

Earlier quoted context omitted.

> 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 over complicated, 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…

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.

Re: Passkeys will come at a cost

#380

Post by dcow »

dmix wrote: post #235

This is a bit unrelated to the harder crypto stuff but my mom called me freaking out she couldn’t get into her gmail. It turns out Google auto registered her new android phone with a passkey and made that the default Google login with a confusing passkey based interface (expecting her to know to click the second option to login via password or understand wtf a passkey is was too much IMO). It turns out when it said “…

To be fair, this is really just Google being idiotic with their product UX and has nothing to do with passkeys. I think most anybody would be confused if Google randomly changed their login UX to something users aren’t familiar with.
Post reply on HN