3 ms·

The article you linked talks about the MFA fatigue attack. TOTP is not vulnerable to this attack since it doesn't send a push notification approval request. Wou

The article you linked talks about the MFA fatigue attack. TOTP is not vulnerable to this attack since it doesn't send a push notification approval request. Would you elaborate on the viable MITM attacks that are possible with TOTP and mitigated by an active authenticator?

DaiPlusPlus 3y ago
TOTP doesn’t perform mutual-authentication: a lookalike on-screen prompt can be used to capture individual codes from unwitting users.
- zvolsky 3y ago
  Number matching doesn't prevent phishing. When a potential victim enters their password into a fake login page, the attacker simply needs to initiate a login using the provided password and forward the number challenge to the fake page. Sibling thread mentions alternatives that prevent this albeit at the cost of additional technology in the user agent, authenticator, and relying party.
saltcured 3y ago
Stopping phishing-based MITM attacks is one of the main things addressed with FIDO/U2F/Webauthn versus TOTP. Imagine an imposter website that is impersonating the real relying party as part of a phishing attack. With TOTP, the user is relaying a short-term secret code from their authenticator into the relying party's UI. But there isn't any authentication step to ensure that the user is really interacting with the expected relying party, and there is a time window where this code can be replayed. Once the attacker has this code, they could initiate multiple authentications with the real relying party during that window (approximate 1-2 minutes). With Webauthn, the relying party origin is used as part of a cryptographic signing step by the authenticator. There is also a per-request salt to prevent replay attacks. The imposter website would not be able to initiate a useful authentication step with the authenticator, since it would not be able to impersonate the real origin to the authenticator protocol. The various push-based authenticator apps have the opportunity to offer similar security, since they can authenticate the relying party challenges, show the user a trustworthy challenge prompt, and ensure that the response is not usable for replay attacks. A different category of attack might be to compromise the user agent itself. Then real sessions could be hijacked to perform operations not intended by the user. The non-replayable responses can partially mitigate these attacks too. The user can be prompted in real-time to reauthenticate for high-value operations, and may notice spurious prompts when they were not intentionally doing such actions. However, fatigue can set in if the user has too many relying parties registered with an authenticator and/or too many challenges and/or have non-determinism between UI actions and challenges. Then, the user could be confused into approving a challenge for the hidden attack operation happening in the background between their own intended actions. AFAIK, the only way to fully protect against this would be to include details of high-value operations in the challenge/response signature and have a way to display this detailed context in a trustworthy prompt. I.e. a mobile phone authenticator might be trustworthy even with a compromised desktop browser. But if your mobile browser is compromised, I would suggest you also should not trust the authenticator app on the phone. A dedicated hardware authenticator with a screen could show you challenge context, even if the user-agent is trying to fool you. This would be an improvement over the typical security key that at most blinks an LED and leaves it to the user to guess what is being authenticated.
- Arnavion 3y ago
  TOTP can also be safe against an impostor website if the TOTP implementation validates the domain name of the request before filling out the TOTP code. KeePassXC's browser extension does this, for example. Of course, if the impostor has hijacked the user's DNS request for the real website's domain name, and the impostor has presented a TLS cert for the real website issued by a CA the user trusts, then what I described will still leak the TOTP code. But in that situation WebAuthn would also be broken. The advantage WebAuthn has is that it's built into the browser, so the browser gets to enforce that the user isn't involved in ways that could weaken the security. With TOTP the browser has no way of knowing if it's a domain-name-checking implementation like KeePassXC or the user is copy-pasting codes from another program or another device without applying sufficient care.
  - GoblinSlayer 3y ago
    No, no, you can't mitm tls by just presenting someone else's public key.
    - zvolsky 3y ago
      Indeed, if the key is signed by a trusted certificate authority that the user agent recognizes, as OP implied, a MITM attack is possible.
- zvolsky 3y ago
  You raise some valid points, but I don't think that Microsoft Authenticator implements FIDO/U2F/Webauthn. My point was that the number matching implemented by Microsoft Authenticator is no safer than TOTP.

DaiPlusPlus 3y ago

TOTP doesn’t perform mutual-authentication: a lookalike on-screen prompt can be used to capture individual codes from unwitting users.

zvolsky 3y ago
Number matching doesn't prevent phishing. When a potential victim enters their password into a fake login page, the attacker simply needs to initiate a login using the provided password and forward the number challenge to the fake page. Sibling thread mentions alternatives that prevent this albeit at the cost of additional technology in the user agent, authenticator, and relying party.

saltcured 3y ago

Stopping phishing-based MITM attacks is one of the main things addressed with FIDO/U2F/Webauthn versus TOTP. Imagine an imposter website that is impersonating the real relying party as part of a phishing attack. With TOTP, the user is relaying a short-term secret code from their authenticator into the relying party's UI. But there isn't any authentication step to ensure that the user is really interacting with the expected relying party, and there is a time window where this code can be replayed. Once the attacker has this code, they could initiate multiple authentications with the real relying party during that window (approximate 1-2 minutes). With Webauthn, the relying party origin is used as part of a cryptographic signing step by the authenticator. There is also a per-request salt to prevent replay attacks. The imposter website would not be able to initiate a useful authentication step with the authenticator, since it would not be able to impersonate the real origin to the authenticator protocol. The various push-based authenticator apps have the opportunity to offer similar security, since they can authenticate the relying party challenges, show the user a trustworthy challenge prompt, and ensure that the response is not usable for replay attacks. A different category of attack might be to compromise the user agent itself. Then real sessions could be hijacked to perform operations not intended by the user. The non-replayable responses can partially mitigate these attacks too. The user can be prompted in real-time to reauthenticate for high-value operations, and may notice spurious prompts when they were not intentionally doing such actions. However, fatigue can set in if the user has too many relying parties registered with an authenticator and/or too many challenges and/or have non-determinism between UI actions and challenges. Then, the user could be confused into approving a challenge for the hidden attack operation happening in the background between their own intended actions. AFAIK, the only way to fully protect against this would be to include details of high-value operations in the challenge/response signature and have a way to display this detailed context in a trustworthy prompt. I.e. a mobile phone authenticator might be trustworthy even with a compromised desktop browser. But if your mobile browser is compromised, I would suggest you also should not trust the authenticator app on the phone. A dedicated hardware authenticator with a screen could show you challenge context, even if the user-agent is trying to fool you. This would be an improvement over the typical security key that at most blinks an LED and leaves it to the user to guess what is being authenticated.

Arnavion 3y ago
TOTP can also be safe against an impostor website if the TOTP implementation validates the domain name of the request before filling out the TOTP code. KeePassXC's browser extension does this, for example. Of course, if the impostor has hijacked the user's DNS request for the real website's domain name, and the impostor has presented a TLS cert for the real website issued by a CA the user trusts, then what I described will still leak the TOTP code. But in that situation WebAuthn would also be broken. The advantage WebAuthn has is that it's built into the browser, so the browser gets to enforce that the user isn't involved in ways that could weaken the security. With TOTP the browser has no way of knowing if it's a domain-name-checking implementation like KeePassXC or the user is copy-pasting codes from another program or another device without applying sufficient care.
- GoblinSlayer 3y ago
  No, no, you can't mitm tls by just presenting someone else's public key.
  - zvolsky 3y ago
    Indeed, if the key is signed by a trusted certificate authority that the user agent recognizes, as OP implied, a MITM attack is possible.
zvolsky 3y ago
You raise some valid points, but I don't think that Microsoft Authenticator implements FIDO/U2F/Webauthn. My point was that the number matching implemented by Microsoft Authenticator is no safer than TOTP.