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

Passkeys and Modern Authentication

lucumr.pocoo.org

Post reply on HN
Print view View original

181–190 of 212 posts

Re: Passkeys and Modern Authentication

#181

Post by NoGravitas »

tptacek wrote: post #43
dan-robertson wrote: post #29

What do security professionals think about passkeys? In particular, those who were not involved in designing them. Lots of the arguments in this article feel very much like the sort of thing one would expect from someone into open source (not saying they are wrong, and I think they are well explained here) but I feel they will inevitably be the product of different concerns than those a security practitioner might ha…

Security people are generally pretty positive on Passkeys. Eliminating passwords has been the white whale of information security for over 3 decades. Practitioners are generally positive about FIDO2 (Yubikeys are fetish objects for them). I think message board people would probably be surprised at security practitioner attitudes towards Apple and Google authentication lock-in (locking my team into Google authenticati…

> I think message board people would probably be surprised at security practitioner attitudes towards Apple and Google authentication lock-in

We're not surprised, but I think many of us are horrified. I think it's a culture clash, partly between Free Software and Enterprise communities, partly between developers and security professionals. Given that it's a culture clash, I don't actually see any resolution that will make everyone happy.

Re: Passkeys and Modern Authentication

#182

Post by NoGravitas »

parliament32 wrote: post #177
dan-robertson wrote: post #29

What do security professionals think about passkeys? In particular, those who were not involved in designing them. Lots of the arguments in this article feel very much like the sort of thing one would expect from someone into open source (not saying they are wrong, and I think they are well explained here) but I feel they will inevitably be the product of different concerns than those a security practitioner might ha…

Compliance/security role at a company you've heard of here. Passkeys are absolutely fantastic. Pretty much every complaint you see in these threads is seen as a positive in an enterprise context. > Attestation restricts passkey clients GOOD. I need a way to prove passkeys live on hardware-backed crypto devices (see NIST SP 800-63B), attestation makes that possible. > But auth lock-in GOOD. All our corporate sign-in e…

>> But auth lock-in > > GOOD. All our corporate sign-in events should be through our single IDP using SSO. Of course we want lock-in.

My workplace uses Duo Mobile for a second factor, which is functionally identical to TOTP, and probably uses TOTP internally (if your android phone is rooted, you can export Duo Mobile keys to your choice of TOTP app). But as long as I'm being a good corporate citizen, I can't use my choice of TOTP app. What actual security (non-theater) interest does that serve?

Re: Passkeys and Modern Authentication

#183

Post by NoGravitas »

agwa wrote: post #27
alphazard wrote: post #6

Unfortunately the tech community is full of people who pride themselves on being aware of and advocating for the latest standard put out by whatever company. That's how we end up with lots of complicated nonsense like most of what is sent in HTTP headers, or the contents of a TLS certificate. On the topic of authentication, it's solved. SSH nailed it, any further complexity is strictly worse . Signing up is uploading…

The simplicity of SSH's public key authentication comes with a significant privacy downside: https://www.agwa.name/blog/post/whoarethey https://words.filippo.io/whoami-updated/ This isn't such a big deal in the SSH ecosystem, but it would be a disaster on the Web where there is an enormous incentive to track users. Part of WebAuthn's complexity comes from addressing that.

Use a different public key for every site, specify which one in your .ssh/config. Only offer keys for the site(s) they correspond to. Done. This is already best practice, but could easily be improved by simple tools to manage it. You do not also need things like attestation and restriction of backups.

Re: Passkeys and Modern Authentication

#184

Post by NoGravitas »

palata wrote: post #99
alphazard wrote: post #33

Earlier quoted context omitted.

> authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding? No, it's just how you authenticate with signing keys. Given that a secure channel has been set up with ephemeral keys, you can sign a commitment to the channel (like the hash of the shared secret key) to prove who you are to the other party. > let users authenticate via SSH and then return a short-lived token t…

The thing is, if you want to use SSH with a secure element, suddenly you're using FIDO2, right? OpenSSH already supports it. And WebAuthn is using FIDO2, it's not that different, it's just that WebAuthn adds some stuff like a relying party.

It's the stuff it adds that most people object to.

Re: Passkeys and Modern Authentication

#185

Post by NoGravitas »

tadfisher wrote: post #35
alphazard wrote: post #24

Earlier quoted context omitted.

There are multiple solutions to this, with tradeoffs. Doesn't change the fact that the service should only want a public key, and you should only give the service a public key. That's where this new complexity is being forced on users and developers. You need to be able to sign in, or let your users sign in, but you can choose how complicated of a key management strategy to have. You can either have 1 key pair per se…

You are describing passkeys. All of this applies to the passkey scheme. Actually, a benefit of passkeys is the standardization of client-side cross-device authz operations via caBLE and similar; your secret keys never leave your primary device, but are usable from other devices over a variety of transports.

Except that passkeys also add other things, like attestation, relying parties, and restrictions on how keys are synced, and so on. I don't think anyone disagrees that the basic idea of "we should be using site-specific public/private keypairs for logins" is good.

Re: Passkeys and Modern Authentication

#186

Post by NoGravitas »

AlexandrB wrote: post #44
AnotherGoodName wrote: post #3

> there is effectively no way to export private keys between authentication password managers No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today. You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on goo…

> Otherwise people would be tricked into giving away passkeys much like they are with passwords today. Is this really a common attack vector vs. a company leaking their whole customer database and a bunch of password being revealed that way?

Not yet. It's a more complex variation on phishing, but not complex enough that it wouldn't happen if scammers needed it to.

Re: Passkeys and Modern Authentication

#187

Post by NoGravitas »

palata wrote: post #162
tuckerman wrote: post #140

Earlier quoted context omitted.

My reading of the the linked github thread is: 1) A member of the FIDO alliance says that provider attestation is bad because relying parties could block specific providers 2) This FIDO alliance member doesn't like that keypassxc has implemented a feature for their users that weighs user freedom/security different than they would prefer and 3) they insinuate that if keypassxc doesn't change this, they could decide to…

> But I think users have the right to build/use software that works how they see fit. They have, I don't think anyone denies that. But the other side has the right to refuse working with them if they find them insecure. I don't think it is limited to passkeys... I have always been forced to use the authentication chosen by the IT at work, it's not like I can come and say "You know what? Instead of your SSO coupled wi…

Work IT is different from services being offered to the public, though.

Re: Passkeys and Modern Authentication

#188

Post by NoGravitas »

palata wrote: post #108
AnotherGoodName wrote: post #3

> there is effectively no way to export private keys between authentication password managers No exporting really is a feature. Otherwise people would be tricked into giving away passkeys much like they are with passwords today. You can always register multiple passkeys with providers though. Already have a passkey with google but want another one via a different password/account manager? Just go into settings on goo…

I don't get the downvotes here. I feel like people mix up the protocols and the implementations. Because one can share their passkeys with a Google password manager does not mean that they have to. Passkeys are just WebAuthn, which works on its own. Since I'm getting downvoted as well: I am using passkeys with Yubikeys, without depending on any TooBigTech.

> Because one can share their passkeys with a Google password manager does not mean that they have to.

The standard provides the means for the relying party to choose what password managers it will accept, so you may very well have to use the Google password manager.

Re: Passkeys and Modern Authentication

#189

Post by dandanua »

palata wrote: post #164
dandanua wrote: post #143

Earlier quoted context omitted.

WebAuthn won't help you if you are signing-up on a phishing site.

Well if you sign up on a phishing site, they won't be able to access the legit site with your credentials...

Niеther an ssh MITM can use your private key on a legit server. A middleman doesn't need it in most cases, however. My point was that the situation with ssh is basically the same as with webauthn.

Re: Passkeys and Modern Authentication

#190

Post by NoGravitas »

Dr4kn wrote: post #26
dan-robertson wrote: post #20

> Obviously, one could pay for an authenticator like 1Password, which at least is ecosystem independent. However, not everybody is in a situation where they can afford to pay for basic services like password managers This argument was made in the context of moving out of the Apple ecosystem (are there other ecosystems one would want to leave where the only option is paying for something like 1password?). I don’t real…

There is also keepass, which you can sync with whatever free cloud storage you want. It might not be the nicest password manager you can use, but you can always use it for free. Bitwardens free tier is also generous enough that a lot of people won't have to pay

KeePassXC has been repeatedly threatened with blacklisting by the WebAuthn alliance. Once for allowing exports of passkeys, once for not requiring reauthentication of an already unlocked vault when providing a passkey.
Post reply on HN