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

  • Thann@lemmy.ml
    link
    fedilink
    English
    arrow-up
    48
    ·
    11 months ago
    1. IP based rate limiting
    2. IP locked login tokens
    3. Email 2FA on login with new IP
    • Umbraveil@lemmy.world
      link
      fedilink
      English
      arrow-up
      22
      ·
      edit-2
      11 months ago

      IP-based mitigation strategies are pretty useless for ATO and credential stuffing attacks.

      These days, bot nets for hire are easy to come by and you can rotate your IP on every request limiting you controls to simply block known bad IPs and data server IPs.

    • CommanderCloon@lemmy.ml
      link
      fedilink
      English
      arrow-up
      15
      ·
      11 months ago
      1. The attackers used IPs situated in their victims regions to log in, across months, bypassing rate limiting or region locks / warnings

      2. I don’t know if they did but it would seem trivial to just use the tokens in-situ once they managed to login instead of saving and reusing said tokens. Also those tokens are the end user client tokens, IP locking them would make people with dynamic IPs or logged in 5G throw a fuss after the 5th login in half an hour of subway

      3. Yeah 2FA should be a default everywhere but people just throw a fuss at the slightest inconvenience. We very much need 2FA to become the norm so it’s not seen as such

      • unphazed@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        11 months ago

        2 factor beats the hell outta that “match the horse with the direction of the the arrow 10x” bs