My phone died a few days ago, and the Cisco Duo app overwrote 2FA key backup after connecting my old phone to the internet.
Lemmy has no backup codes, nor can you disable 2FA even while logged in without a valid token.

Anyway, I noticed there’s no rate limiting on 2FA attempts.
So following Lemmy API docs I wrote this exceptionally stupid script (look at my foolish way of parallelization and no auto-stop).

I got the JWT token from logged-in Firefox session, using cookies.txt extension to export it.

Anyway, just make sure your password is secure enough, It’s obviously (potentially) better than 6 digits, probably with 3 valid combinations at each time (current 30s, past 30s, future 30s windows), if I am guessing how it works right.

My attempt also clearly involved a lot of luck with just 21,830 attempts (less than 5 minutes). But, if you’re lucky enough, you may guess it on first attempt, or never if you aren’t.

  • bamboo@lemmy.blahaj.zoneEnglish
    38·
    2 months ago

    Not do downplay this issue, but based on the description, OP had a valid session cookie, and was updating their profile to disable MFA since they lost the code. They weren’t brute forcing logging in.

    I haven’t looked into the source code, maybe this is an instance by instance configuration, but login attempts are rate limited. After a few failed attempts, I started getting this message:

    Lemmy Error: You’re being rate limited, wait a bit before trying that again.

    • u/lukmly013 💾 (lemmy.sdf.org)@lemmy.sdf.orgOPEnglish
      27·
      2 months ago

      I just did a manual test with sh.itjust.works comparing it to lemmy.blahaj.zone.

      sh.itjust.works keeps accepting attempts
      lemmy.blahaj.zone blocks after I think 3 attempts (I forgot to pay attention)
      lemmy.ml also blocks after 3 attempts

      sh.itjust.works and lemmy.blahaj.zone even use the same version, lemmy.ml is on a 0.19.6 beta.

      Going further, lemmy.world: no blocking (as far as tested)
      lemm.ee: no blocking (as far as tested)
      sopuli.xyz: after 10 attempts

      Summary: SDF is using old version, the rate limiting seems to be variable suggesting a setting

      Analysis: lemmy.ml, lemmy.blahaj.zone and sopuli.xyz appear to be exposed directly (.zone doesn’t respond without SNI, other 2 show NGINX page). NGINX can pass client IPs in headers. The rate limiting appears to be IP-based.
      sh.itjust.works, lemmy.world and lemm.ee are all behind CloudFlare.

      Hypothesis: Either a problem with passing client IP headers from cloudflared or the instance admins simply trust CloudFlare to provide some rate limiting.

      • Darkassassin07@lemmy.caEnglish
        4·
        2 months ago

        a problem with passing client IP headers from cloudflared

        I’d be willing to bet this is it. My nginx proxy needs special config to pass client IPs correctly to backend services. Otherwise the backend just sees the IP of the proxying cloudflare server.

        proxy_set_header X-Real-IP $http_cf_connecting_ip;

        A cloudflare specific header. The typical $remote_addr I use elsewhere has the cloudflare server’s IP when cloudflared is involved.