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".

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.

It all comes down to how many times you are practically allowed to try and what percentage chance is "good enough" for your purposes.

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...

(31^6)/7200

Small correction:
36^6^. It's roughly 31b of entropy (log~2~(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.

I think the area of the risk you might not be taking into account is the question "how do codes get generated?" If they are anything like the registrar I use, you only get a code when you are logged into the site as an administrator for that domain name and specifically request one. So, the attack chain requires that I somehow either compromise the admin's account or convince the legitimate admin to generate a code. In the former case, I probably already have 90% of what I want anyway, unless this is a very valuable domain name and I can't compromise the admin's email and/or change the email on the account. In the latter case, the admin who was socially engineered into generating the transfer code is probably also not going to have a problem handing over the transfer code as well.

So, the attack surface is really a domain which is already being transferred and some attacker knows the time window in which that transfer is happening and they need to beat the legitimate recipient's use of the code . It seems like one of those cases of "technically yes, but realistically no" scenarios. Sure, they could make things harder (including rate limiting and having the code expire after too many guesses). But, it's probably not something that is going end up actually having an impact.

Sorry if I wrote something in a confusing way.

This is concerning My .eu portal, which is a completely separate portal of the registry, that also allows generating tranfer codes without involving the current registrar (as well as showing all private info).

This is the login page: https://my.eurid.eu/en/auth/login/?next=%2Fen%2F
The only needed information is e-mail address associated with the domain and the domain name. While both are needed, and the domain name alone is not enough, the e-mail address is available in the WHOIS information.

When the Registrant is a natural person the Registry publishes the Registrant´s e-mail
address and language.

Source [PDF]

This mean anyone, at any time, can generate authorization code, and attempt to use it at the My .eu portal.

Based on EURid's info, entering the portal is enough to get access to the transfer code.

From the My .eu platform: You can also issue the transfer authorization code yourself on the My.eu account. Please do not confuse the access code you will receive by email (which will enable you to enter the My .eu platform) with the transfer authorization code (which you will issue once you are on the platform).

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.

Sorry if I wrote something in a confusing way.

Nope, I just failed at reading comprehension today. This does seem like a bad oversight on their part. That a transfer code can be created by anyone other than the current owner is just bad from the start.