7 ms·

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, pass

by bedast 4y ago

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.

j_san 4y ago
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.
- bedast 4y ago
  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.
  - cmeacham98 4y ago
    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.
    - bedast 4y ago
      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.
      - j_san 4y ago
        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)
        bedast 4y ago
        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.
        cmeacham98 4y ago
        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).
0daystock 4y ago
> 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.
- bedast 4y ago
  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...
vlan0 4y ago
>"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.
vngzs 4y ago
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.
- NovemberWhiskey 4y ago
  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".
- zozbot234 4y ago
  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?
  - netheril96 4y ago
    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).
  - somethingAlex 4y ago
    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).
  - PeterisP 4y ago
theplumber 4y ago
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).
imwillofficial 4y ago
“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”

by bedast 4y ago

j_san 4y ago

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.

bedast 4y ago
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.
- cmeacham98 4y ago
  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.
  - bedast 4y ago
    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.
    - j_san 4y ago
      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)
      - bedast 4y ago
        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.
        cmeacham98 4y ago
        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).

0daystock 4y ago

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

bedast 4y ago
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...

vlan0 4y ago

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

vngzs 4y ago

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.

NovemberWhiskey 4y ago
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".
zozbot234 4y ago
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?
- netheril96 4y ago
  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).
- somethingAlex 4y ago
  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).
- PeterisP 4y ago

theplumber 4y ago

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

imwillofficial 4y ago

“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”