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

361–370 of 600 posts

Re: Passkeys will come at a cost

#361

Post by tzs »

upofadown wrote: post #5

This raises a question for me. Why are hardware keys so limited in storage? How much extra would it cost to have a secure processor that could access a mass storage device also built in to the key. This mass storage device would of course be strongly encrypted by the secure processor with a key that would be erased at the same time everything else is erased.

Maybe even make it modular. Sell something that looks like a thumb drive but has a slot in the back that you can plug a small security key into (think something with a form factor like a YubiKey Nano).

When a security key is plugged into the slot the thumb drive provides storage for the security key and appears to the computer as a security key.

When a security key is not plugged into the slot the thumb drive functions as an ordinary thumb drive.

You would ordinarily keep the security key plugged into the slot, but if you ever decided you needed more storage you could by a bigger storage module, remove the security key from your old storage module, plug the old module into the computer, copy the encrypted files, plug in the new module, copy the files to it, then plug in the security key.

Re: Passkeys will come at a cost

#362

Post by tzs »

morelisp wrote: post #9
upofadown wrote: post #5

This raises a question for me. Why are hardware keys so limited in storage? How much extra would it cost to have a secure processor that could access a mass storage device also built in to the key. This mass storage device would of course be strongly encrypted by the secure processor with a key that would be erased at the same time everything else is erased.

I don't know if this is the only reason, but mass storage devices seem to have a ludicrously unacceptably high failure rate and short lifetime to be something I key large potions of my life to.

Mass storage for resident keys would not need to be written to often. Just when you create an account at a new site. I'd guess that would greatly lower the failure rate.

Re: Passkeys will come at a cost

#363

Post by vel0city »

mgkimsal wrote: post #349
BiteCode_dev wrote: post #316

Earlier quoted context omitted.

After I deleted my personal google accounts, I was left with work google accounts I would have to maintain. I have been bitten by this problem more than once, resulting in: - losing some accounts forever - losing temporarily access to accounts, preventing me to work for some time - forcing me to go through recovery procedures with tedious docs and hostile UI, wasting my work time I eventually found a trick: buy 3 yub…

Somewhat unrelated, but I got one of those Google Titan fobs. The one time I needed it to work - authenticating from a new-to-me- computer - it just... didn't work. I plugged it in and... nothing. No popups, no reaction at all. Thought it was broken, but it worked back on another computer when I tried it later. No idea how that this future is supposed to be better. Perhaps titans are just duds? A couple yubikey-focus…

The only time I've had frustrations with my yubikeys is not being able to redirect them in some RDP sessions when logging into an account that's wanting a yubikey to authenticate. Otherwise, my keyring one that I use the most (original NFC) is nearing a decade old and never fails.

I use it almost exclusively in Windows and ChromeOS.

Re: Passkeys will come at a cost

#364

Post by vel0city »

wholinator2 wrote: post #337
Barrin92 wrote: post #317

Earlier quoted context omitted.

>Then the whole "answer some questions" dance starts. Google literally does provide you with backup codes that they tell you to keep offline available, which is pretty common practice for any 2FA scheme.

What? I've never been given backup codes, nor any notification that such a thing even existed.

It makes you get backup codes when you add a TOTP or webauthn authenticator.

Re: Passkeys will come at a cost

#366

Post by androidbishop »

0x4e53 wrote: post #218

For context, we run a YC-backed passwordless company, and have rolled passwordless out at major organizations. While I think passkeys will definitely be the answer for consumer passwordless, I'm not sure this is quite reflected in the enterprise yet. Passkeys are wonderful for consumer use, because they're meant to enable your own ability to break glass, by backing up the credential to other devices. You can do this…

yubikeys (5) can be used as passkeys

Re: Passkeys will come at a cost

#367

Post by androidbishop »

0x4e53 wrote: post #215
Ajedi32 wrote: 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…

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

Re: Passkeys will come at a cost

#368

Post by yomlica8 »

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

Can't you just print them to PDF?

Re: Passkeys will come at a cost

#369

Post by gre345t34 »

torstenvl wrote: post #161

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…

The article assumes quite a bit of knowledge of FIDO2 and your confusion is understandable.

> How/why? What's the connection to passkeys or HSMs?

Passkeys are implemented on top of FIDO2 and specifically utilise the "resident key" functionality of the FIDO2 spec (according to the article; I don't personally understand passkeys). FIDO2 hardware authenticators are not HSMs exactly, though they are similar and some devices (like Yubikeys) are both HSMs and FIDO2 authenticators.

> Yeah okay... does this imply that all resident keys are discoverable keys? Or that all discoverable keys are resident keys? Or both?

In FIDO2 "resident key" and "discoverable key" are synonymous. "Resident key" is the term used in the spec, however "discoverable key" is commonly used. One of many such cases of FIDO creating confusing terminology.

> No. Does "keys" here mean passkeys? Or keys stored on HSMs? Or both? Or something else entirely?

Neither, it refers to FIDO2 hardware authenticators (e.g. Yubikeys) which are commonly referred to as "security keys".

> Okay so an HSM can apply to an unlimited number of accounts because it can store... some kind of key wrapped in another key (of the same type? different type?)

A FIDO2 hardware authenticator (which is not a HSM per se) can be registered with unlimited accounts because it is effectively stateless; it doesn't store anything (assuming that you are NOT using resident keys, which must be stored).

When the authenticator is registered with an account, it generates a key pair on the device (e.g. an EdDSA key pair). Instead of storing the key pair, it encrypts the private key with the onboard master key (e.g. an AES256 key). It then sends the plain text public key and the encrypted private key to the "relaying party" (e.g. google.com) who stores it. When authentication is attempted, the encrypted private key (i.e. the "wrapped" key) is sent to the authenticator where is decrypted onboard and then used to produce a digital signature.

Note: The FIDO2 does not actually specify how to implement non-resident keys - wrapped keys are just one way of doing it. FIDO2 only requires that the private key must be securely derivable from the credential ID (where the credential ID is actually arbitrary data which may or may not be a wrapped key).

Re: Passkeys will come at a cost

#370

Post by yomlica8 »

jabbany wrote: post #45
dathinab wrote: post #16

> 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 think this is not as bad as attestation abuses. My guess of what will happen is if a service sets `rk=required` and you are on a platform that doesn't want to (or can't) enable/support it, the process would always fail and you wouldn't even be able to register. Which seems like a shoot-yourself-in-the-foot kind of move if the goal is to onboard users and get more business...

Didn't they already figure this scam out with phone verification? You let the user signup easily and then rug pull them a week or so later forcing them to do the thing they would have balked at if it was an upfront requirement. Now they have to jump through a bunch of hoops to get something they've already put time into working again.

Even if they abandon the account you still made your signup metric go up and probably collected some usage info and maybe PII. And you can also block them from signing up again until they do what you want.

Post reply on HN