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

Passkeys for Infrastructure

goteleport.com

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Passkeys for Infrastructure

#41

Post by vouaobrasil »

Personally, I both love and hate the idea of passkeys. In terms of security, passkeys definitely have some real advantages, not to mention the convenience of never having to type a password or remember one again.

Still, they have a serious flaw: practically, you need a hardware device with you, and practically it will be a phone. I hate having to rely on having my phone handy to log into anything. What if I lose it? With a password I can log in from anywhere.

I feel like passkeys are a double-edged sword, like all of technology. On the one hand, they introduce new convenience and security, but on the other hand they make us even more tied to systems and devices. It's a lot of infrastructure that someone else has to maintain, and it's a single-point of failure in case you want to keep all your passkeys in iCloud, so you can migrate them to other iDevices.

We are crafting increasing complex systems with tighter and tighter integration into our lives and I think we need to be cautious of passkeys before accepting them so readily.

In short, there is no such thing as free convenience. There is always a cost, but we usually ignore that.

Re: Passkeys for Infrastructure

#42

Post by sebk »

noahtallen wrote: post #36

A lot of comments in this thread are discussing vendor lock-in with Apple or Google. 1Password is working on passkey support already ( https://www.future.1password.com/passkeys/ ) and I imagine others will follow suit. Vendor lock-in isn’t part of the spec, it just happens that in these early days, the OS-level authenticators are the main ones implemented (as are other hardware authenticators). In the mid to long ter…

1Password's and Dashlane's implementation keeps the key material and does crypto in software, meaning it's less isolated from the operating system than hardware-backed implementations. That might be an acceptable tradeoff for some, but definitely not for all, and I doubt that was the original intention of FIDO2 when it was designed -- the spec only mentions virtual authenticators in the context of testing.

I hope the FIDO alliance members come up with a solution that has both hardware backing and third-party vendors. I'd love to have 1Password syncing passkeys to Yubikeys or secure element that can be used independently of the 1Password app and subscription itself.

Re: Passkeys for Infrastructure

#43

Post by account-5 »

pat2man wrote: post #40
account-5 wrote: post #38

Nope. I still can't see me using passkeys. Unless someone can explain how I use them without a Google/Apple/Microsoft account, or without being reliant on some third party and a hardware device then it's useless for me. I would only ever use this if like my password manager the authenticator was software based (hardware independent), platform and vendor independent, open source, and offline.

Any password manager can support them. 1Password has announced a beta already.

If/when keepassxc supports them I'll likely start using them. As it stands I'm not putting all my eggs(keys) in a third-party basket, one that might decide to shut my account with them for no reason or recourse (Google). Or to a device that can be lost, stolen, or broken. Having multiple devices and third party services to "fix" this is not the answer.

Re: Passkeys for Infrastructure

#44

Post by pat2man »

vouaobrasil wrote: post #41

Personally, I both love and hate the idea of passkeys. In terms of security, passkeys definitely have some real advantages, not to mention the convenience of never having to type a password or remember one again. Still, they have a serious flaw: practically, you need a hardware device with you, and practically it will be a phone. I hate having to rely on having my phone handy to log into anything. What if I lose it?…

Ultimately, passkeys are just certificate based authentication. Certificates are generally more secure because they contain more entropy (and because they contain metadata). But nothing is stopping you from using something like a mnemonic phrase that you remember to generate a certificate. It would be trivial to create a browser extension that allowed you to use a "password" on a passkey enabled site. If thats the experience you want I am sure someone will provide it.

Re: Passkeys for Infrastructure

#45

Post by willio58 »

zacharyvoase wrote: post #30

I see a few obstacles with Passkeys as-implemented: * They effectively entrust the keys to your entire digital life to (right now) either Google or Apple. Account compromise, or a ToS-related suspension, becomes catastrophic. * Domain changes happen (acquisitions, rebrands, etc.), and there is no way to share or migrate passkeys between domains. Right now the best you can do is a highly manual process involving the u…

> They effectively entrust the keys to your entire digital life to (right now) either Google or Apple.

Yeah this seems like a big one. Of course password managers will add support too but that isn't an actual solution since those often cost money and require extra effort on the user's part.

Part of me feels this needs to be legislation that requires tech companies to settle on a standard that works cross-browser cross-device. I imagine something like the EU's recent moves to force Apple to support USB-C could work well here.

Re: Passkeys for Infrastructure

#46

Post by vouaobrasil »

pat2man wrote: post #44
vouaobrasil wrote: post #41

Personally, I both love and hate the idea of passkeys. In terms of security, passkeys definitely have some real advantages, not to mention the convenience of never having to type a password or remember one again. Still, they have a serious flaw: practically, you need a hardware device with you, and practically it will be a phone. I hate having to rely on having my phone handy to log into anything. What if I lose it?…

Ultimately, passkeys are just certificate based authentication. Certificates are generally more secure because they contain more entropy (and because they contain metadata). But nothing is stopping you from using something like a mnemonic phrase that you remember to generate a certificate. It would be trivial to create a browser extension that allowed you to use a "password" on a passkey enabled site. If thats the ex…

Your proposed solution isn't a very good one. Actual password systems use server-side things like salts and other mechanisms like hashing. Having "trivial" client-side extension to generate a certificate would make brute-force a lot easier. So, if passkeys are the only way of logging in, then no, a browser-based certificate generator would not work to emulate passwords.

Re: Passkeys for Infrastructure

#47

Post by smw »

arianvanp wrote: post #6

I wish SSO providers were able to hook into this Passkey mechanism. Instead of storing Passkeys in iCloud for sync instead we could store them at the SSO provider

Then how would you authenticate to the SSO provider?

Re: Passkeys for Infrastructure

#48

Post by [deleted] »

candiddevmike wrote: post #8

> I predict that 2023 will be the year of Passkeys. I remain unconvinced that Regular Users will find passkeys as necessary/useful as the rest of the industry does, especially older users. Will be interesting to see how pervasive passkeys become.

[deleted]

Re: Passkeys for Infrastructure

#49

Post by jmcnulty »

sebk wrote: post #42
noahtallen wrote: post #36

A lot of comments in this thread are discussing vendor lock-in with Apple or Google. 1Password is working on passkey support already ( https://www.future.1password.com/passkeys/ ) and I imagine others will follow suit. Vendor lock-in isn’t part of the spec, it just happens that in these early days, the OS-level authenticators are the main ones implemented (as are other hardware authenticators). In the mid to long ter…

1Password's and Dashlane's implementation keeps the key material and does crypto in software, meaning it's less isolated from the operating system than hardware-backed implementations. That might be an acceptable tradeoff for some, but definitely not for all, and I doubt that was the original intention of FIDO2 when it was designed -- the spec only mentions virtual authenticators in the context of testing. I hope the…

My biggest anxiety with hardware-backed security is what happens if someone breaks into my house and steals my laptop and phone. Today I would buy a new laptop, login to Bitwarden using my strong memorised master password and carry on. If everything about me is linked to hardware-backed passkeys then my digital life walks out the door with the thief.

Re: Passkeys for Infrastructure

#50

Post by sebk »

jmcnulty wrote: post #49
sebk wrote: post #42

Earlier quoted context omitted.

1Password's and Dashlane's implementation keeps the key material and does crypto in software, meaning it's less isolated from the operating system than hardware-backed implementations. That might be an acceptable tradeoff for some, but definitely not for all, and I doubt that was the original intention of FIDO2 when it was designed -- the spec only mentions virtual authenticators in the context of testing. I hope the…

My biggest anxiety with hardware-backed security is what happens if someone breaks into my house and steals my laptop and phone. Today I would buy a new laptop, login to Bitwarden using my strong memorised master password and carry on. If everything about me is linked to hardware-backed passkeys then my digital life walks out the door with the thief.

This is a totally valid concern. A mitigation is to have some other device or mechanism to generate a device that's part of sync fabric in escrow somewhere else. Of course, this introduces two new problems: Where do you keep it in escrow, and how do you authenticate to that escrow service given that your authenticators are gone. Safe deposit boxes are one alternative: They're authenticated by your presence and government-issued ID. Apple uses a 24-character key and keeps the encrypted record in its HSMs. Crypto wallets tend to use a 24-word recovery phrase to derive a key. These last two options you could also escrow with a third party or maybe even memorize.

For what it's worth, it's not an inherent problem with hardware backed security, at least not in the context that I was talking about. If you were using pure software implementations of WebAuthn, you could also authenticate to that sync fabric only using WebAuthn and you'd have that exact same problem you're describing.

Post reply on HN