Hope this isn’t a repeated submission. Funny how they’re trying to deflect blame after they tried to change the EULA post breach.

  • Zoolander@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    2
    ·
    edit-2
    11 months ago

    So forced MFA is the only way to prevent what happened? That’s basically what you’re saying, right?

    Their other mechanisms would prevent credential stuffing (e.g., rate limits, comparing login locations) so how was this still successful?

    • sudneo@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      10 months ago

      Yes, forced mfa (where forced means every user is required to configure it) is the most effective way. Other countermeasures can be effective, depending on how they are implemented and how the attackers carry out the attack. Rate limiting for example depends on arbitrary thresholds that attackers can bypass by slowing down and spreading the logins over multiple IPs. Other things you can do is preventing bots to access the system (captcha and similar - this is usually a service from CDNs), which can be also bypassed by farms and in some cases clever scripting. Login location detection is only useful if you can ask MFA afterwards and if it is combined with a solid device fingerprinting.

      My guess in what went wrong in this case is that attackers spread the attack very nicely (rate limiting ineffective) and the mechanism to detect suspicious logins (country etc.) was too basic, and took into account too few and too generic data. Again, all these measures are only effective against dumb attackers. MFA (at most paired with strong device fingerprinting) is the only effective way there is, that’s why it’s on them to enforce, not offer, 2fa. They need to prevent the attack, not let just users take this decision.