Live data from Hacker News

Passkeys will come at a cost

fy.blackhats.net.au

91–100 of 600 posts

Re: Passkeys will come at a cost

#91
post #48

> rk=required why does that even exist, that shouldn't be an option this stuff is why I have been so worried/skeptical about Passkeys and the people related to it. They have the responsibility to design their protocols to not be a tool well suited for big coperations like Microsoft to seriously mess up security, compatibility and enact all kinds of "bad faith" market practices to kill competition. But instead again a…

I'm pretty sure the goal here is to turn your phone into your passkey, _and nothing else_. Everything written in that article makes sense if you keep that in mind.

This is a terrible idea though.

I had the misfortune of getting into a cycling accident which broke my phone display (completely lost display output and touch input), and it meant I lost access to all my OTP 2FAs for a couple of days (which is actually kind of scary).

I was able to fix it myself by getting parts and going through an ifixit guide (right to repair anyone? ;-), after which I promptly exported my 2FA seeds to (1) a backup phone (2) KeePass, which apparently supports them, who knew... and (3) a QR code on a printed piece of paper.

Re: Passkeys will come at a cost

#92

Earlier quoted context omitted.

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

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.

Re: Passkeys will come at a cost

#93
post #61

Earlier quoted context omitted.

Passkeys are for the people that don't even use password managers outside of what Apple or chrome provides by default if at all. Passkeys are trying to eliminate those ad hoc solutions by providing a different system. The transition will be slow and messy requiring most people to use passkeys and passwords (and maybe password managers) for a while.

But if the passkeys are copyable off of where you are storing them, then I'm not entirely clear on how they truly up the security? I mean, I get the obvious ways that a challenge system is better than a bearer token. But I feel a ton is lost as soon as you move to the exportable keys. Love to see an exploration on these topics. I confess I have not been following them much, lately.

I think the general idea is that the vast majority of people have a smart phone, so the security model is to let people use the phone as the "key" to access services and take advantage of the biometrics/pin security as the main component of security access. This means that there are a lot of security compromises that make sense in the name of ease of use.

This model has been tested to some extent with Apple pay and Google wallet which people take relatively seriously since there's money involved. I think the model makes sense to improve security for the masses, but it's not good for people that want and demand more (like people that already bought YubiKey products).

Re: Passkeys will come at a cost

#94
HTTPS only like this blackhats.net.au site comes at a cost too. If there's a browser/server SSL mismatch the text becomes completely unavailable. While if it was an HTTP+HTTPS site I could simply visit the HTTP endpoint. Instead to protect against hypothetical downgrade attacks they've made their content inaccessible and effectively DoS themselves for a small fraction of visitors.

Re: Passkeys will come at a cost

#95
post #91
post #48

Earlier quoted context omitted.

I'm pretty sure the goal here is to turn your phone into your passkey, _and nothing else_. Everything written in that article makes sense if you keep that in mind.

This is a terrible idea though. I had the misfortune of getting into a cycling accident which broke my phone display (completely lost display output and touch input), and it meant I lost access to all my OTP 2FAs for a couple of days (which is actually kind of scary). I was able to fix it myself by getting parts and going through an ifixit guide (right to repair anyone? ;-), after which I promptly exported my 2FA see…

Maybe I'm getting tinfoil-y here, but I think the horribleness is the point: consider how eager Apple in particular is to get people fully enmeshed in their services ecosystem. You're a lot less likely to try to roll your own backup, or otherwise exit the walled garden, if doing so means your entire auth story is irredeemably fucked.

The thing that strikes me about this whole story is that during a lot of the initial discussions of passkeys, a common point brought up on the anti-lockin side was the ability to use non-phone providers like yubikeys. If the actual implementations make this less viable, as discussed in the article, then that shifts power towards lock-in.

Re: Passkeys will come at a cost

#96
post #48

Earlier quoted context omitted.

I'm pretty sure the goal here is to turn your phone into your passkey, _and nothing else_. Everything written in that article makes sense if you keep that in mind.

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 (which might involve entering 2FA codes etc that you cannot get anymore).

This is why physical tokens are still quite useful. They're rather unattractive to thieves, don't require its own Internet connection to work, and they're relatively small and cheap so you can get a bunch them to stuff in various places increasing your chances of having one still available to you.

Re: Passkeys will come at a cost

#97

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.

you don't need to backup a shared secret to gain exactly what you get from backing up a shared secret, except more secure you have a backup of a _different_ secret with a similar degree of "authority" (or if it's "copyable" with the only authority to be used for restoring 2FA once or similar) then if you backup gets stolen you can just go into you account management API and disable/delete/flag it, in that case even i…

The main issue I see happening here with a large list of keys is the lack of an automated way of making these backups: this would require a standard way for a backup system to use one set of secrets to authenticate another set of secrets, which AFAIK doesn't exist for webauthn (it must be initiated by the site, all of which will have different methods of doing so). Otherwise you would have to manually enroll multiple devices for each account, which is both painful and error-prone.

Re: Passkeys will come at a cost

#98

Earlier quoted context omitted.

I'm not sure why current keys cost so much...

My hunch is low volume and an enterprise-leaning customer base. Engineers aren't cheap, and those who can build security-sensitive products even less so. When I bought a (single) Yubikey from their website late last year, it was Fedexed to me directly from their Palo Alto downtown office, not some distribution center in the middle of nowhere. That can't be cheap.

If you order a key and it comes from an Amazon warehouse, are you going to be worried about a supply chain attack? Maybe that's a benefit of sending by direct FedEx?

Re: Passkeys will come at a cost

#99
post #50

Earlier quoted context omitted.

Why not just store the master key in the tamper resistant storage and then have some regular old consumer grade storage to store all the derived keys?

This allows to copy derived keys easily, which ruins the purpose of the whole security key idea.

only if the master key can be extracted (assuming the keys are encrypted by such)

Re: Passkeys will come at a cost

#100
post #27

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…

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.
Post reply on HN