Hacker News Reader

Comment by bedast | Hacker News Reader

The weakest link in security is always going to be humans. Account compromise is is more often a human problem than a technological one (spamming requests, password reuse, simple passwords, (spear) phishing, direct social engineering, etc).

If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords. Easier to use. Easier to social engineer a compromise.

I get regular requests to get into my Microsoft account using their new login form that sends a key code rather than prompting for password. "Passwordless" just means that prompt goes to an app where a user unlocks their device to approve the login.

This seems like worse security, not better. I'm okay with an approval prompt if it's part of a multi-factor auth system. Not if it's the only auth.

View on HN

> If I'm understanding correctly, they're aiming to reduce multi-factor auth back down to a single factor that's "easier" than passwords.

It isn't only easier, it's significantly more secure. FIDO/U2F is basically immune to phishing, because there's no one-time code to type and steal; there's a cryptographically backed signing assertion guaranteeing the person with physical possession of the token is in control. This is so airtight (because almost all account compromise is done remotely, not through physical in-person attacks) that I would even be personally comfortable disclosing my password for accounts secured by FIDO/U2F.

In a multi-factor scheme, I would agree with you. I use FIDO/U2F myself...as a secondary factor.

There are active attacks that attempt to exploit human lack of vigilance in an authentication approval flow. With a password as a first factor, it reduces the chances that these attempts make it to the user.

You and I are probably fine in terms of vigilance. If I see an auth request, say, from my Okta app, that I did not initiate, I know it's something I need to investigate and will not automatically approve it. But consider the typical user...

There's a frequent misconception that hardware keys are no better than, say, a TOTP seed on a secure element of your phone.

The core practical difference between a hardware key and that TOTP code on a secure element is the hardware key, when registered with a domain, is programmed with the domain name in it. Lookalike domains - or anything besides the exact domain you registered the key with - fail to 2FA because they are unregistered. This essentially prevents (spear)phishing attacks from stealing login credentials.

Absolutely right - put another way: the responsibility of the user is reduced from "be absolutely certain that you're entering your credentials to the web site that you think you're authenticating at" to "provide consent to authenticate".

Doesn't TOTP use current time as part of the challenge? Why couldn't a refinement of TOTP add the domain name as a further element?

You can't rely on the end users to check the domain name, because

* Most users have no idea what a domain name is.

* It is tedious to compare the domain name character by character.

* Phishing sites have used many UI tricks historically to make their domain name look authentic (e.g lookalike Unicode characters).

That's pretty much what happened here. Obviously it's going to look a bit different afterwards because you have to mathematically tangle the time, key, and domain together. You can't really do that with the six digits of a traditional OTP code.

And like the other reply stated, if you can't mathematically tie them together, you have to rely on the user validating the domain (which you can't).

If a user manually enters a code from TOTP device/calculator into a website, that TOTP device/calculator has no way to know which exact website domain it is - if the user visiting notmybank.com thinks they are visiting mybank.com, they'll get the right code for mybank.com from their device and get pwned.

The key part of FIDO protocol is that it prevents the user from getting the code intended from one domain and sending it to a different domain.

But this seems like a technological solution to a very human problem. If I can trick a user into approving the login, then hardware fobs, secure elements, etc, are meaningless.

The audience here is likely to assume that the security is solid. And it probably is. But this is a technology targeting your average user. It'll certainly be easier for the end user. But it seems like it introduces a human-based attack vector that may be easier to exploit.

What I mean is: with modern hardware keys you literally can't trick a user into approving a remote login, or a login to a fake domain. It's not possible unless you can control the domain that the user is logging into (say you've got code execution on their machine or compromised their network and broken TLS, attacks which are significantly more complex than phishing). Hardware keys enforce that the device can only authenticate against the real domain, not a phishing domain. The core of this is a real improvement of how 2FA works at the protocol layer, rather than simply a change to how the user interacts with the device.

Hardware keys also require that the key can only authenticate a local session, so there's also no risk that your "hardware key tap" can be captured and used by a remote adversary who doesn't control the local computer.

But isn't the "thing" about FIDO (or maybe just security keys?) that the domain is also integrated into the challenge the client/key has to solve?

So from what I understand a attacker couldn't as easily fish me by pretending e.g. to be Google. With a password or even a TOTP code the attacker could just pose as Google and forward the credentials to the actual site.

You're looking at an exploit from a technological point of view, which I expect this community is likely to do. Think of it from the perspective of the average user. I know for a fact if my mom was told by an attacker "if you see an approval request for your account, just accept it" she would do so. It's taken time to train her not to give anyone her password.

I've read of attackers with valid passwords spamming logins in hopes to trick a user into approving the auth. Whether it's because it woke up the user and they're in a sleep fog, or they're busy and not paying attention.

Microsoft, at some point, changed their login flow so that, by default, when you enter your username, it sends a pin. I receive regular attempts at this. This isn't going to work out for the attacker because they have to get the pin. But if all that's required is a button press, the attacker could just make the login request and wait.

With multi-factor auth, where a password is in use, you have to get past the password before getting to that auth approval. It reduces how much noise the user gets and the chances of success for the attacker.

You don't understand FIDO/webauthn/etc. The scenario you describe is impossible. This is the genius - the user is totally cut out of the equation, there is no action your mom can take on phishing-website.com to send the credentials of google.com, because the key will refuse to do so.

What this article is about is authenticating the request with an app on your phone, not a hardware key. This ends up being a device totally disconnected from the device requesting the auth, and neither have to be in the same geographic location unless implemented alongside the spec.

Depending on how it's implemented it could still use the same mechanism, couldn't it? (genuine question)

For me the question is if this is a webauthn thing in general or a security key thing (to include the domain in the challenge to prevent phishing)

The article specifically discusses auth via app, but if it's involving the FIDO alliance, it'd be weird to exclude hardware keys, I guess. I still don't like the idea of going single factor, but if it's with a hardware key, I can see it being better than with an app since it has to directly interact with the process itself.

But, of course, if this is optional, I still have to reference the end users. I'm willing to pay for an authentic FIDO key, which can be a tad costly. Your typical user might be more inclined to go for a cheap one that does enough to get into the account, and may not be trustworthy, or would prefer not to do it at all.

My understanding is that the theoretical app being discussed behaves in the same way as a hardware key - it is simply a software-only implementation of the protocol (and thus comes with the same advantages).

That's why with webauthn humans are not part of the auth scheme anymore. All the auth is negotiated between machines(web browser -> domain name -> hardware key storage).

>"Passwordless" just means that prompt goes to an app where a user unlocks their device to approve the login.

Setup a yubikey with an attested cert/pub key. Require a pin to use said yubikey.Requiring attestation will prove that private key was generated on the device, and will only live on that yubikey. That's your best bet.

It also satisfies the multi-factor needs. The something you have is the yuibkey. The something you know is the PIN.

“The weakest link in security is always going to be humans.”

This is not true whatsoever.

Humans will always be a weakness for sure. But hardly the “weakest”, and hardly “always”

Reply on news.ycombinator.com