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

191–200 of 212 posts

Re: Passkeys and Modern Authentication

#191

Post by jrochkind1 »

tptacek wrote: post #139
harshreality wrote: post #137

Earlier quoted context omitted.

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.

What is your current to use at this moment preferred option for a general (not especially sensitive domain like banking) consumer site?

Re: Passkeys and Modern Authentication

#192

Post by parliament32 »

NoGravitas wrote: post #182
parliament32 wrote: post #177

Earlier quoted context omitted.

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 c…

If a user can use any TOTP app of their choice, what's the mitigation for them installing a malware TOTP app that ships their private keys directly to CCP HQ?

Duo is regularly audited by independent third-party assessors to attest SDCL, data protection in their datacenters, etc.[1] Audits aren't a guarantee but they provide a reasonable amount of assurance that their software products and infrastructure have at least basic data protection measures.

> if your android phone is rooted, you can export Duo Mobile keys

This is the exact reason why personally owned devices, in most organizations, require MDM enrollment and attestation before being granted access to corporate resources.

[1] https://duo.com/solutions/compliance

Re: Passkeys and Modern Authentication

#193

Post by NoGravitas »

parliament32 wrote: post #192
NoGravitas wrote: post #182

Earlier quoted context omitted.

>> 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 c…

If a user can use any TOTP app of their choice, what's the mitigation for them installing a malware TOTP app that ships their private keys directly to CCP HQ? Duo is regularly audited by independent third-party assessors to attest SDCL, data protection in their datacenters, etc.[1] Audits aren't a guarantee but they provide a reasonable amount of assurance that their software products and infrastructure have at least…

If you can't use a TOTP app of your choice, what's the point of there being a standard? Pick an audited app using a proprietary scheme, you don't need interoperability, and if you don't need interoperability, you don't need a standard.

Re: Passkeys and Modern Authentication

#194

Post by palata »

tuckerman wrote: post #175
palata wrote: post #166

Earlier quoted context omitted.

> but this is essentially a threat of blacklisting an entire password manager I don't think they could blacklist the entire password manager. They can't prevent it from giving you a username/password... Refusing some passkeys is, to me, similar to refusing passwords that are too short. It may make sense to only accept passkeys backed by a secure element. Companies already force their employees to use a specific MFA a…

What if websites start adopting passkey-only with instead of offering a username/password option? We could live in a world where services are inaccessible unless you use Google/Apple/1Password/etc as your password manager

> We could live in a world where services are inaccessible unless you use Google/Apple/1Password/etc as your password manager

If services want to force you to use whatever authentication they want, they can. That's what already happens with any service that is serious about security. In big companies, you have to use their authenticator app, their mail client, their messaging system, etc. Often it's Microsoft software. Banks have their own systems, etc.

Now, if a service allows you to use a passkey instead of their own 2FA app, I'd say it's a win. I'm happier using a security key than a Microsoft authenticator. But if they give up on using their own app, they may well set conditions on the passkey you use. And that condition may be "it has to be backed by a trusted secure element".

You won't be able to use a passkey that's deemed unsecure just like right now, you already are not able to just use a weak password with some services.

Again, I'm not saying that being forced to depend on TooBigTech is not a problem: it very much is. But nothing says that services have to do it with passkeys: they could (and should) also accept secure passkeys that don't come from TooBigTech. But they still have a say in what they find secure or not, and that part is okay.

Re: Passkeys and Modern Authentication

#195

Post by palata »

NoGravitas wrote: post #179
palata wrote: post #165

Earlier quoted context omitted.

> passkey are designed in a ways that the attestation party is visible Are you talking about the relying party? I don't think it works the way you describe...

I believe they mean that relying parties can use attestation to verify that the client implementation is one they choose to support.

The thing is, it's already the case today, without passkeys. Banks routinely force you to use their own app to login, for instance. And for those that allow you to choose your own password, I'm pretty sure they force you to use some other factor of their own. And it actually does make sense for services that do need the security.

The fight should be "now that we have good third-party authentication thanks to passkey, you should allow us to use those that are secure enough". Not "we don't want that new technology that is superior in many situations because services could force us to use it the way they want, exactly like they already do without this technology".

"Now that I can login using my Yubikey, please don't force me to use your MFA apps because they are provably not superior to my Yubikey".

Re: Passkeys and Modern Authentication

#196

Post by palata »

NoGravitas wrote: post #188
palata wrote: post #108

Earlier quoted context omitted.

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.

Without passkeys, a service can force you to use their own proprietary app as a second factor. It's been like that for years with banks and at big companies.

They already do select the security they want. And it does make sense when security matters to them!

Say you managed to put into the law that "it's illegal to discriminate passkeys, either you accept all implementations or none of them". What would happen then? Those services would just not use passkeys, because they already have a solution they control today (with their own authenticator apps).

What the standard provides is a way to have certified/audited passkeys. So that instead of using the authenticator app of my bank to log into my bank and the Microsoft authenticator to log into my company SSO, maybe (just maybe) I will someday be able to use a passkey. Not any passkey, that's very clear, and it actually does make sense in terms of security. But maybe instead of using Apple or Google, you will be able to use a security key like Yubikey.

And the fight should be to give a fair chance to those third-party systems for getting certified. Not to refuse the passkey technology because instead of being forced to use the Microsoft passkey, we really like it better when we are forced to use the Microsoft authenticator app.

Re: Passkeys and Modern Authentication

#197

Post by palata »

NoGravitas wrote: post #187
palata wrote: post #162

Earlier quoted context omitted.

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

The difference is the security requirements. Services that are fine today with you using just a username+password won't care at all if you use a passkey that is considered unsafe.

Re: Passkeys and Modern Authentication

#198

Post by palata »

dandanua wrote: post #189
palata wrote: post #164

Earlier quoted context omitted.

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.

> Niеther an ssh MITM can use your private key on a legit server

Of course they can: that's precisely the meaning of MITM.

They don't get direct access to your private key (because they wouldn't need to stay in the middle anymore at that point), but they will ask you to sign the challenge sent by the legit server, which you will happily do if you don't realise that you are not talking to the legit server.

WebAuthn prevents that MitM part.

Re: Passkeys and Modern Authentication

#199

Post by palata »

NoGravitas wrote: post #184
palata wrote: post #99

Earlier quoted context omitted.

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.

It feels more like people object for the sake of objecting. I often have this feeling: people first don't care (about security, about renewable energy, ...), and the moment they start caring, there is a high risk that they will just object to everything, sometimes without good reasons.

Sure, we are being abused by TooBigTech and surveillance capitalism. It doesn't mean that all security is bad. Security is a compromise. Yet many people go "this added security comes from a governement/TooBigTech so it proves that it is a lie". Which is wrong: it doesn't prove it. Sometimes there are good things coming from governments/TooBigTech.

The world is more nuanced than people seem to realise.

Re: Passkeys and Modern Authentication

#200

Post by tuckerman »

palata wrote: post #194
tuckerman wrote: post #175

Earlier quoted context omitted.

What if websites start adopting passkey-only with instead of offering a username/password option? We could live in a world where services are inaccessible unless you use Google/Apple/1Password/etc as your password manager

> We could live in a world where services are inaccessible unless you use Google/Apple/1Password/etc as your password manager If services want to force you to use whatever authentication they want, they can. That's what already happens with any service that is serious about security. In big companies, you have to use their authenticator app, their mail client, their messaging system, etc. Often it's Microsoft softwar…

I don’t think we should create standards that make it easier for companies to erode user freedoms and I’d support legislation to restrict what certain companies can/can’t do (banks, Google/Apple, etc)

The discussion about what happens in big companies is completely unrelated to this discussion. In that case the company is the user. They can do/enforce whatever they want and nobody is having any freedoms infringed.

Post reply on HN