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

591–600 of 600 posts

Re: Passkeys will come at a cost

#591

Post by froggit »

slaymaker1907 wrote: post #388
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 “…

Honestly, I think if you’re using 2FA, you should also have 2 different ways to provide a 2nd factor (like TOTP or notification to your phone).

Google supports this. I have hardware key, phone notification, TOTP, 2FA recovery codes and email notification to non-Gmail address all setup.

Losing access to my second factor has always been my biggest concern with 2FA.

Re: Passkeys will come at a cost

#592

Post by froggit »

jabbany wrote: post #96
microtonal wrote: post #55

Earlier quoted context omitted.

Apple opened up OS integration for other applications. 1Password is currently doing beta testing of their Passkey implementation. Besides that, the whole idea of Passkey (in contrast to what this blog claims) was that the key material can be synced between devices, so I am not sure how only the phone would be 'a passkey'. iCloud Keychain syncs my Passkeys between all my devices, including to my MacBooks.

The problem with cloud-sync-based managers like the iCloud Keychain is bootstrapping. Since you need to be able to log in to the services themselves to provision access to the passwords. This makes travelling a bit risky, since it's not that hard to lose/break/have your devices stolen during a random trip. This makes it immensely hard to recover, since you cannot just hop onto a public terminal and authenticate (whic…

"It's easy to lose devices when you travel so just get a shit ton of devices. If you're a big enough of a fuckup to lose them all then you've got bigger life problems anyway."

I like good advice that, upon hearing it, seems obvious enough it can be misinterpreted as a dig at one's competence. I'm much more likely to follow it and get my ass saved (I'm the kind of medium grade fuckup that would lose all but one of them).

Re: Passkeys will come at a cost

#593

Post by froggit »

tsimionescu wrote: post #305
jabbany wrote: post #143

Earlier quoted context omitted.

> I DO have to remember some passcodes which I otherwise never use but that's not too hard. Right, but you're giving up a lot of security to do this, since it implies with these rare passcodes someone else could also bootstrap your logins. With HW tokens, you don't have to worry about recovery passcodes being leaked/hacked (the recommended procedure today is to print out the recovery codes and destroy digital copies)…

This idea of printing out recovery codes seems so deeply out of touch with basically everyone leading a modern digital life that I can't believe serious security experts actually recommend it with a straight face. No one has a printer anymore, and I'm sure as hell not including a trip to a local printshop as a part of signing up to 2FA for some random site (yes, even Gmail).

grab a pen and something to write on (worst case: buy a pen and write on receipt paper). write down single recovery code to cloud storage thingy. store other recovery codes there.

Re: Passkeys will come at a cost

#594

Post by froggit »

bombolo wrote: post #320
tsimionescu wrote: post #305

Earlier quoted context omitted.

This idea of printing out recovery codes seems so deeply out of touch with basically everyone leading a modern digital life that I can't believe serious security experts actually recommend it with a straight face. No one has a printer anymore, and I'm sure as hell not including a trip to a local printshop as a part of signing up to 2FA for some random site (yes, even Gmail).

Print the recovery codes! For security! Of course to do that I need to go to a public library where I have no idea if they keep copies, and where someone might mistakenly take them from the printer, which is very far away from the computer you must use to print.

Don't explicitly label the codes with their corresponding accounts on the print out, just print the actual codes. Write the corresponding accounts in later. Recovery codes don't do much unless you know where to use them.

Re: Passkeys will come at a cost

#595

Post by froggit »

gooseyman wrote: post #584
Aeolun wrote: post #291

Earlier quoted context omitted.

It’s also make pickpocketing a lot more lucrative if you can grab someone’s wallet and have immediate access to their bank account.

I had never considered this. Somewhat terrifying IF no biometric/pw attached. I expect most people will store on phone, thus it won’t be a huge issue.

Would this not lead back to "losing your phone = can't log in anymore = buy a yubikey"?

Re: Passkeys will come at a cost

#597

Post by dwaite »

runeks wrote: post #381
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 problem with this argument IMHO is that a lot of sites take a policy of not revealing if an account exists or not. They don't, really. Because they have to prevent me from registering an account with the same identifier (username/email) as someone else, thus revealing whether an account exists or not. So the fact that the password recovery page doesn't reveal it makes no difference for someone who wants to know…

Some sites can do this by going as far as to say they've sent the activation email, then instead sending an email saying that there seems to be a registration attempt against their existing account.

How useful this sort of hiding is in practice is somewhat debatable. Github, forums, marketplaces and social networks all tend to have profile pages. I'm more likely to promote these as part of my public-facing persona as well.

The problem in this context I believe - if the largest sites on the internet think they need to protect information about valid accounts, most people will have passkey "slots" on a limited-storage key fob taken up by those sites.

Re: Passkeys will come at a cost

#598

Post by dwaite »

simooooo wrote: post #347
iFreilicht wrote: post #323

Earlier quoted context omitted.

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…

How wouldn’t one of them be the one you’re looking for? I.e. still revealing an account’s existence

I'll try to explain their argument under the assumption handles were convincingly fake, e.g. there wasn't a heuristic to tell real and fake handles apart.

The underlying protocol (U2F or CTAP) will send all received handles to the separate hardware authenticator. Some of these may be real, some may be fake. Some may have been created by other keys.

There is a process to convert correct handles to a correct private key inside the hardware. This _should_ have some sort of integrity to prevent taking incorrect handles and creating garbage private keys as well - those will fail, but the user experience will be sub-par and there are always cryptographic concerns about processing attacker-chosen data.

So when I make the gesture to authenticate, the valid private key which came from a correct handle is used to sign a response message to the authentication request. All the fake handles and those created by other keys would be ignored.

So if the handles are convincingly fake, the web site would be the only one which would know which were real or fake (so that it can still offer proper user self-service management). An individual piece of hardware would know which were real handles that it created. An attacker wouldn't know if they were all fake.

Re: Passkeys will come at a cost

#599

Post by throwaway892238 »

dcow wrote: post #217
throwaway892238 wrote: post #194

Earlier quoted context omitted.

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

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

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.

Post reply on HN