Is there a reason why creating an account with an email already registered doesn't return an error?

Is there a reason why creating an account with an email already registered doesn’t return an error?

Update - more information

Running the following mutation multiple times with the same credentials always returns success.

mutation Register($input: RegisterCustomerInput!) {
  registerCustomerAccount(input: $input) {
    __typename
    ... on Success {
      success
    }
    ...ErrorResult
  }
}

fragment ErrorResult on ErrorResult {
  errorCode
  message
}

Here are the two cases I could think of:

1. If the user registered, but has not yet verified his account. Any subsequent registration attempt with the same credentials returns success. Also, multiple verification emails are sent. If different passwords were specified during the registration attempts, the first one is the one recorded in the database. You could see how this might confuse customers.

2. If the account is verified, any subsequent registration attempt returns success.

Looking at the error codes currently used, it seems like it should return:

• EMAIL_ADDRESS_CONFLICT_ERROR for case (2)

• Either EMAIL_ADDRESS_CONFLICT_ERROR or NOT_VERIFIED (subject to issue #500) for case (1), although I prefer the latter as it is more informative to the customer.

I’m now aware of commit b1ffa1e that makes the registration mutation silently fail to protect user data. You’re trading off extra security for customer experience. As a user, I often forget if I have an account on a particular website - especially if I don’t use it often. I’m curious to hear what you think.

_Originally posted by @marwand in https://github.com/vendure-ecommerce/vendure/issues/33#issuecomment-713831098_

[ssex-dev]

Thank you very much for the fast reply! Ok I understand, I freaked out for a moment, sorry.

[michaelbromley]

@usama8800 this class of attack is known as an an enumeration attack - basically a way to extract data from the system which we don’t want to expose, e.g. all the email addresses of our customers. Good write-up on it here: https://www.upguard.com/blog/what-is-an-enumeration-attack

My proposal is this:

I think long-term, this behaviour should be configurable via a strategy (defaulting to current behaviour), but a strategy-based approach would allow merchants to make a judgement call on their usability/security tradeoff and even implement e.g. a rate-limiting mechanism to mitigate the security risk.