3 ms·

Is it? Couldn't the backend (or even a human attacker) just type the credentials you provide into the real login page, giving you the "tap yes" push notificatio

• dragonwriter 6y ago
  Come to think of it, you're right. I was mentally combining that 2FA method with “new device attempted login” detection, but the latter is usually separate from 2FA. If a login system uses that and provides notice and requires confirmation through a side channel, rather than merely providing informational notice, it will stop (or at least, make it easier to stop; a second user mistake or preexisting side-channel compromise is still possible) the attack. If it's just notice, it at may limit the impact or streamline recovery from the attack. But now that I think about it, it would make sense to combine new device notification with push-notice 2FA for exactly that reason, since you've got a push channel that takes a confirmation already, flag unexpected devices in that channel as well and it becomes much more secure.
• AntonyGarand 6y ago
  It absolutely is: https://github.com/kgretzky/evilginx2 https://github.com/kgretzky/evilginx2
  • tialaramex 6y ago
    Yup. Notice that this can't work on WebAuthn (or its predecessor U2F), which is why everything should do WebAuthn and you should ignore attempts to downgrade you to any other method. An attacker can play the legitimate WebAuthn request from the real site, which will (statistically certain) be nonsense if played by their phishing site. Or they make their own request, which doesn't help them because it's not valid on the real site they want to sign into so it's pointless.
    • GoblinSlayer 6y ago
      In this case the application shows real facebook in a webview and after user logged in, the application retrieved the session cookie from the webview. How webauthn will behave here?
      • tialaramex 6y ago
        If you can steal the session cookie and the session cookie is what you needed then WebAuthn doesn't change anything.