16
[EURid registry] Is a 6 character lowercase alphanumeric password (31b entropy) which randomly changes every 2 hours safe enough for online service (possibly) without proper rate limiting? (lemmy.sdf.org)
submitted 1 week ago by to c/cybersecurity@sh.itjust.works
8 comments fedilink hide all child comments
 

I've recently registered a .eu domain name.

EURid registry has a portal where you can generate a transfer code, thus not fully relying on access to registrar (as well as check and verify your info).

Welp, security.

The only security is a code sent to e-mail associated with the domain. While the portal requires entering this address to log in, it can also be pulled from WHOIS where it is mandatorily published.
Regardless, e-mail (as a string) should not be affecting security.

The code, as I mentioned, is just lowercase letters and numbers. Precisely 6 of them. This is valid for 2 hours and one use.
While there is a "Request new code" button, I wasn't able to generate multiple codes for one 2 hour window, so that's good.

But now we get to rate-limiting. After 9 attempts, I get:

You have exceeded the allowed number of requests.
Please try again in 10 minutes.

Sounds good, BUT, clearing cookies bypasses this.
I have not (yet) tried any automation, I just quickly manually repeated this tomfoolery from same IP 3 times without actually being rate-limited.

I find this... at least strange. Especially since everyone is doing at least 2FA, while some sites even support physical security keys, and then there's "we email you 6 characters".

you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 1 week ago (3 children)

Just based on the math, assuming the 2 hour time frame is honored and there is no backend ratelimiting in place, in order to brute force, you'd have to try ~123,264 requests per second ((31^6)/7200) to try every possible verification key within the 2 hours. This seems unrealistic, but if you just tried 1% of the possible codes within the two hour period, and kept regenerating keys every two hours, I'm sure someone better with math can calculate how long it would take for the odds of guessing the key to be > 50%

Of course this would assume that the webserver could handle 1000 requests per seconds consistently and would not raise red flags with the registrar or the person whose email is getting the verification codes.

  • permalink
  • fedilink
  • source
  • hideshow 3 child comments
    •
  • [–] [S] 1 point 1 week ago* (last edited 1 week ago) (1 child)

    (31^6)/7200

    Small correction:
    36^6^. It's roughly 31b of entropy (log2(36^6^) ≈ 31.019550008654), which would make it 302,330.88/s to go through all combinations.

    Also, while it might raise red flags, there is nothing to do. This is the only security, and the log in can't be disabled.
    Best I can do is a support request.

    Perhaps I should try contacting them anyway.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 week ago*

    I would have to imagine the system they have in place can not handle 302,330 requests/s even if you could issue them that quickly, but obviously that's not a security measure, just a practical limitation. There also may be other rate limits imposed which they do not advertise, but will kick in after 50 requests from any given IP address in a 5 minute period. I would assume if you could get away with trying 1,000 or 10,000 requests in a 2 hour period, that would be something you could demonstrate to them and have them listen. With what you've described now doesn't seem actionable, since performing 20 guesses is not the same as thousands to prove the exploit.

    Also, I am not sure what regulations they need to follow as part of ICANN, but would imagine there is some documentation around what a registrar needs to adhere to for the security of transfer codes. This may be the minimum standards, and in that case, it would be on ICANN to update their guidance.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 week ago

    and would not raise red flags with the registrar

    That's the real determing factor here, they are visibly limiting to 10 tries every 10 minutes, but if there's another limit such as 100 failed tries per password (per 2 hours) absolute max or whatever, that can make a huge difference.

    If you want to hope for unicorns and rainbows, you might even think they use the higher failure limit as a flag to start investigation into where the abuse is coming from and doing what they can to stop it at its source - you'd want to encourage the abusers to keep trying in order for that kind of scheme to work.

    I just had an idea for a system which lets you try 10 times in 10 minutes, lets you bypass that limit by tossing your cookies or whatever, but - after 100 failed tries on this 2 hour password, even if you guess correctly it doesn't let you in anyway, just acts like you put in another wrong guess, but... for attackers that continue to try it initiates a backtrace...

  • permalink
  • fedilink
  • source
  • parent