How long should a email confirmation code be to avoid brute forcing

Question

Let's say we want to new users to confirm their email address on a secure website (one that we don't want users making fake accounts impersonating other users). For UX reasons we may want:

• Short as possible codes in case user types it in
• alphanumeric codes for easy typing
• Does not require user to re-enter their email address when confirming the code

A code that is too short is vulnerable to brute force attempts to confirm it. For example the code 1234 could be easily guessed. The attacker just registers [email protected] and then spams verification codes until hitting the target (and may verify many other random emails).

There's a number of strategies to fight this including:

• Use a long code that can't be guessed - perhaps forcing the user to click a verify link instead of typing it in manually
• Expire code relatively quickly - giving the attacker less time
• Force the user to identify who they claim to be by either logging in or typing their email before the confirmation code. Then expire the code after X attempts. This forces the attacker to have to constantly restart their guessing - removing possibility for an exhaustive search. However it's potentially a UX papercut. Maybe a user clicks the confirm email on a phone after signing on with their desktop. The phone would require logging in and is a slight barrier to sign up.
• Make use of capcha, rate limiting, or other strategies to deter automation. This is probably not guaranteed to solve the issue alone.

Each strategy can potentially harm the UX however. What is a reasonable balance of UX without compromising security?

Answer 1

Provide a URL with a long identifier, user not having to login, and a short 4-digit code, where the user has to log in, and limit to for instance 5 attempts per 24hr.

And it's not like it's hard to get an e-mail account today, so it's of limited overall value.

Answer 2

Put your necessary parameters like (user's email , request time , user ip , ...) in an array and add some random data as seed in your array. Then encrypt your array by AES-256 and add the output to your url.
Now just send the unique url to user email.
If the received data just decrypted successfully then you can validate the email address.

So your identification code is not vulnerable to bruteforce. Also you can add any other security parameters to url and implement extra security checks.

Answer 3

I don't think having the user enter their e-mail is bad from a UX perspective. Many sites require the user to enter BOTH the code & e-mail, yet remain usable.

On registration, generate a secure hash and store it along the user's unique ID in a database.

Send them a link: "site.example/verify/$hash". On this page they will simply enter their e-mail, as that hash will never match up with another e-mail. Expire codes after a short interval, or if the account has been verified (which ever comes first).

Alternatively, you could require almost no user interaction if you like, this could be achieved by sending them: "site.example/verify/$hash/$mail" which may automatically fill the e-mail field.

To add onto this, you're probably best using a captcha/rate limiting as well. Even though a bot may never guess the hash (hopefully you choose a secure algo), it may cause application DOS by flooding your database with requests.