Live data from Hacker News

Passkeys and Modern Authentication

lucumr.pocoo.org

131–140 of 212 posts

Re: Passkeys and Modern Authentication

#131
post #105

Earlier quoted context omitted.

I get the lack of trust with TooBigTech, but I personally use passkeys with security keys (Yubikeys). WebAuthn is just a bunch of protocols that can run independently from TooBigTech.

It's hard for more people to verify whether this is actually independent from big tech. With a password, you can write it on a piece of paper. You can then type it back in. If any character doesn't match, it doesn't work. This seems like a trustworthy demonstration that it is actually independent. Passkeys have too much magic to understand in this way.

But passwords are hell for most people: they never remember them, for some reason (I don't understand it either) they really don't want to use a password manager, and they get phished.

Passkeys mean that most people can just FaceID or their fingerprint everywhere and they are happy. They are happy to be locked in if it just works.

For those of us who don't want to be locked in, we still have the possibility to not be locked in because we understand how it works.

I don't think we can do better: try to explain to normies how they should enjoy using a CLI and see how they react.

Re: Passkeys and Modern Authentication

#132
post #104

Earlier quoted context omitted.

How is that effectively ceding control of your online identity? You can buy a security key (that does not have your name on it), have it generate a FIDO2 key and use it as a passkey. You can have 100 Yubikeys for 100 different websites if you want. But you can't ever export the private key from the Yubikey, and that's a feature. That's the whole point of the Yubikey.

I think there is a difference between a specific implementation of passkeys not allowing export as a feature and the article’s linked GitHub thread with a threat of potentially blacklisting an implementation if it allows export [1]. Imo users need the fundamental freedom to choose. [1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

Where is the threat to blacklist? I missed that so I lack context.

Re: Passkeys and Modern Authentication

#133

Earlier quoted context omitted.

@alphazard, what are your thoughts on using self-signed X.509 certs, since 95% of the infrastructure is already there?

I'm opposed to using certs where public keys will do. Certificates especially X.509 are more complicated than the public keys that they reference. They include things like domain names, serial numbers, version numbers, etc. The complexity of X.509 belongs in the domain name system. If a bunch of large corporations want to come up with complicated formats so they can decide who gets to call themselves what on the inte…

DNS for key management is nonviable due to the lack of uptake of DNSSEC. Though it's an interesting hypothetical question whether that would still have been the case without X.509.

Re: Passkeys and Modern Authentication

#134

Earlier quoted context omitted.

Yes, because financial institutions are responsible for losses incurred via account takeover.

And yet they are still out here offering voiceprint authentication

JP Morgan Chase does this, regrettably.

Re: Passkeys and Modern Authentication

#135
post #101

Earlier quoted context omitted.

SSH does have certificates, but in practice most people using SSH don't use SSH certificates and don't check the fingerprints. Not sure if we can say it's solved if nobody wants to use it by choice (certificates are probably mostly used in enterprise setups, but in my experience it's not even that common there).

If you have a small, stable number of hosts, an SSH PKI doesn't make a lot of sense. With a large fleet, and/or if you want to tie your fleet into an OIDC IdP, certificates are pretty common; the most common way of solving this problem, I think?

I think it's the case in big companies. But most companies are not big :-), which means that a lot of people are using SSH without ever checking the fingerprint. That would be my intuition.

Re: Passkeys and Modern Authentication

#136
post #79

> One slightly more concerning issue today is that there is effectively no way to export private keys between authentication password managers Not being able to use the passkey manager at all is a bigger concern. For example Keepassxc works with some sites but not with others. It's super annoying and way worse than situation with passwords.

I use Bitwarden and have never had issues saving or using passkeys with any site I can recall via the Chrome extension.

Well, see here: https://github.com/keepassxreboot/keepassxc/issues/10374

I'm pretty sure a lot of this stuff are arbitrary decisions that sites make when they implement passkey support and you never know where it will work. Also some sites likely don't care about fixing it since they think they deliberately are "improving security" or they just don't care. So I'd say it's an ugly mess. I wish it would work though.

Re: Passkeys and Modern Authentication

#137

Earlier quoted context omitted.

This is actually the first I've heard of this, re considering TOTP to be not worthwhile. Can you recommend some links to material for me to read to get up to speed with the argument?

Basically everything ever written about U2F, WebAuthn, and phishing-proof authentication generally is about the weaknesses of TOTP. The principle component of the problem is phishing.

There are sites requiring TOTP to mitigate careless users using dumb passwords, because the sites can't guarantee passwords aren't reused but they can enforce TOTP.

Even for phishing, doesn't it count for something that TOTP prevents asynchronous phishing (collect credentials on a fake site, try them in batches later)?

Re: Passkeys and Modern Authentication

#138
post #135

Earlier quoted context omitted.

If you have a small, stable number of hosts, an SSH PKI doesn't make a lot of sense. With a large fleet, and/or if you want to tie your fleet into an OIDC IdP, certificates are pretty common; the most common way of solving this problem, I think?

I think it's the case in big companies. But most companies are not big :-), which means that a lot of people are using SSH without ever checking the fingerprint. That would be my intuition.

SSH has always relied on key continuity for this problem; you're exposed when you're first introduced to a host (on a particular client) but then fine from that point on.

This of course breaks down with cattle fleets where ~most logins are to hosts you've never hit before, which is why cattle fleets tend to use SSH PKI.

Re: Passkeys and Modern Authentication

#139

Earlier quoted context omitted.

Basically everything ever written about U2F, WebAuthn, and phishing-proof authentication generally is about the weaknesses of TOTP. The principle component of the problem is phishing.

There are sites requiring TOTP to mitigate careless users using dumb passwords, because the sites can't guarantee passwords aren't reused but they can enforce TOTP. Even for phishing, doesn't it count for something that TOTP prevents asynchronous phishing (collect credentials on a fake site, try them in batches later)?

No, it does not. Everybody agrees that password + TOTP is better than just plain passwords. Everything is better than just plain passwords. But I've personally worked on large, high-stakes projects where TOTP phishing was a continuous problem, and it's really difficult to solve. Since we have options besides TOTP that aren't susceptible to phishing, people shouldn't be pushing TOTP anymore.

Re: Passkeys and Modern Authentication

#140
post #132

Earlier quoted context omitted.

I think there is a difference between a specific implementation of passkeys not allowing export as a feature and the article’s linked GitHub thread with a threat of potentially blacklisting an implementation if it allows export [1]. Imo users need the fundamental freedom to choose. [1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

Where is the threat to blacklist? I missed that so I lack context.

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 push for provider attestation in the future, potentially ending keypassxc as a viable password manager.

Perhaps I'm reading things in a worse light than you but I believe the potential for abuse is so high and the value of user freedom is so high that these comments shouldn't be taken lightly. I say this a user and huge fan of Yubikeys (I use them precisely because of the feature of not being able to export the private key for security). But I think users have the right to build/use software that works how they see fit.

Post reply on HN