Mitigating email address abuse in website registration pages.

Introduction

Attackers are carrying out data mining exercises on websites using the registration page. Registration pages can allow the attackers to use an automated process to ascertain whether an email address exists on the system. Using the registration page can be quicker for initial activities.

• The attacker can enter the email address along with some other random name data.
• The attacker can then submit the registration form.
• The attacker can then check the response to see if the email address exists.
• If the email address exists, the attacker can then add the email address to the list for a rainbow attack on the login page.
• If the email address does not exist, some sites then end up emailing the unsuspecting user to confirm registration. But the attack doesn't care, they are finished with the email address at this point.

The reason for using the registration page rather than the login page (or forgot password):

• A login page typically gives a vague error message that the "username or password" may not match. Where the registration page is more informative for the attackers needs.
• A forgot password page is usually just as vague saying it will send an email if the email address exists.
• Registration pages may not have the same intrusion detection methods, rate limiting etc.

Common Pitfalls

• Providing overly specific error messages (e.g., "Email already registered") that aid attackers.
• Failing to monitor registration logs for suspicious activity.
• Not testing a registration flow against automated tools.
• Assuming that CAPTCHA is a silver bullet; it can be bypassed by advanced bots.
• Assuming that the big organizations have all the answers, or follow "best practice". The initial version of this article was put together after both a major social media platform AND an online only Financial services organization both triggered emails to a honeypot email address in a short space of time.
• Not considering the user experience when implementing security measures.
• Not considering that the security landscape changes.

Mitigation

There are a number of ways to mitigate this issue:

Use a web application firewall (WAF)

A WAF can be configured to detect and block automated requests that are trying to abuse the registration page. This can include rate limiting, blocking known bad IP addresses, and more. Major providers have a source of known bad actors, and \ or patterns used by them so can apply a level of automation to the blocking.

Make multifactor authentication mandatory

By requiring multifactor authentication you reduce the value of attacking the site using just an email, then email + password rainbow attack. The attacker still won't be able to use the site without the MFA token.

Use CAPTCHA on the registration page.

Adding a CAPTCHA to the registration process can effectively prevent bots and scripts from automating registration attempts. While it may add a slight inconvenience for legitimate users, it significantly enhances security by ensuring that only humans can interact with the form.

Change your registration flow to be multistep and email first.

This might seem counter-intuitive, but if the attacker can only enter the email and the site responses with a vague message that an email will be sent if the email address isn't already registered. You will end up sending an email, but the value to the attacker is reduced as they still can't work out if the email address was registered in the first place, they are back at needing to use the login page. If an attacker was to still use the page, you need to combine with other measures such as allowing the email to be reported via a link, along with other measures

Apply rate limiting.

Implement rate limiting on the registration endpoint to prevent excessive requests from a single IP address. This can help mitigate brute-force attacks and automated scripts that attempt to abuse the registration page. There are very few use cases where the same IP address needs to attempt multiple registrations, especially in a short space of time. The only real use case would be a shared network such as an office, school. What needs to be assessed is the chance of there being multiple registrations from a single location in a short space of time. A family may potentially register a few people if you are offering a family based service \ subscription. Colleagues or friends may register in a short space of time. You need to think of the chances of that and set an appropriate threshold for a rate limit. For a family based offering, you may initiate additional logins via an invite based flow. For corporate based offerings you may want to consider a more corporate based login mechanism anyway.

Defer your registration to after a 3rd party authentication mechanism has taken place.

By getting the user to trigger a login flow from a popular authentication provider, you are removing a flow to generate emails from your site. You're also reducing the appeal of your sites login mechanism and taking advantage of security investments by the bigger 3rd parties. If you're offering a PAAS solution to corporate clients, this would be a stronger way to go anyway as you can offload all user enrollment to their IT department. If it's using SAML, Azure AAD, etc. the authentication mechanism is in their control and fall in line with any user offboarding, account locking, removal that they carry out.

Conclusion

Securing your registration page is essential to protect user data and prevent abuse. Regularly review your security posture and stay informed about emerging threats.

For more information, see the OWASP Account Enumeration page.