One of the raised issues for a Web API is that for an e-mail based authentication (e-mail and password) the Register user method returns something like "the registration e-mail has been sent" regardless of the e-mail being used or not for an account:

  • there is no account using that e-mail: the e-mail is actually sent and an OK is responded
  • an account using that e-mail exists: nothing is done and the same response is issued (OK)

This means that the client cannot understand what actually happened.

One of the project owners replied that this was intended to avoid a malicious party from checking if various e-mails are used for account of that service.

I am wondering if there is a middle ground between high security and a decent UX for the client.

I found a way that prevents batch checks by a third party by using an IP rate limiter (all requests for that endpoint are throttled. for example max 2 requests per 10s and 5 requests per minute from a certain IP). It is based on this answer and this library.

If an IP abuses that API method, it gets an HTTP 429 Too Many Requests response.

This does not prevent checking a small number of e-mail addresses, but it should prevent checking a large number of them.

Is there any better solution security-wise? I am asking especially because the referenced SO Q&A is rather old and things might have evolved in the meantime.

  • Just checked a big provider's (Gmail) signup form and they do not seem to bother with abuse, at least not when manually checking of 20-30 e-mail addresses. Now I am wondering if such a concern makes sense for a way smaller service.
    – Alexei
    Oct 17, 2021 at 15:39
  • Why not send an email reminding them of their account if it already exists? Oct 17, 2021 at 17:39
  • @user2313067 That's actually an interesting idea. Basically, an e-mail is being sent in both cases, just a different one. The UX is still kind of crappy because the user does not understand what happened, but at least they can their e-mail and find out. Thanks.
    – Alexei
    Oct 17, 2021 at 19:14

1 Answer 1


I don't believe vague messages such as, "Email has been sent if the account exists", and other variants, have negative impact on UX or user-experience. The only case I can think of is a user who used multiple email addresses, and forgot which one was used to register on the website, and the response isn't indicative if it's correct or not, so users are forced to check multiple email inboxes. The solution to that is usually just searching the suspected inboxes for a registration email address. Nonetheless, these functionalities should not be relied on to remind users what credential sets were used within the application, so I'm not sure that's a fair criticism.

Rate limiting & throttling will only really be possible by the source IP address because there is no active session identifier when these functionalities (login, password reset, registration) are typically used, and source IP filtering is easily bypassed via proxies.

With those points in mind, I don't believe the convenience is worth the risk. Bear in mind that every application is different and has different security standards. For example, you mention Gmail seemingly accepts this risk. Knowing whether someone is registered to Gmail (almost everyone) or not isn't a huge privacy invasion, but being able to figure out if someone is registered to an online dating application, or a banking application, can be greatly invasive. Furthermore, if the application is designed for employees only, one can deduce internal naming conventions of usernames and emails.

During red team engagements, user enumeration is extremely helpful and often leads to further attacks.

  1. Discover naming conventions of usernames/emails.
  2. Enumerate valid emails.
  3. pass the emails to a service like dehashed.com to check for any breaches and curate password lists with permutations based on a password policy.
  4. Bruteforce, password spray, etc..

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .