New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customer Accounts #33

michaelbromley opened this Issue Oct 24, 2018 · 4 comments


None yet
1 participant

michaelbromley commented Oct 24, 2018

A Customer can be a guest (has no associated User) or registered (has an associated User).

Account creation

An account can be created in one of two ways:

  1. Ad-hoc account creation by the customer outside the order process
  2. Conversion of a guest account into an authenticated account after the placing of an order.


As the diagram shows, a customer does not need to create an account after placing an order. Indeed, the customer is free to only every do guest checkouts. For the checkout, however, the email address would be used to create a guest Customer, and then on subsequent checkouts with the same email address, the same guest Customer would be assumed.

At any time, the guest Customer can be converted into an authenticated Customer by registering in either of the two ways outlined above.

Registration process

There are 2 questions to resolve regarding registration:

  1. Do we support 3rd party authentication methods in the future (social login, Google account etc)? If so, what (if any) changes to the current User entity would be needed?
  2. Do we require email account verification? If so, what is the purpose? Do unverified users have a restricted set of possibilities compared to verified ones?

Account Deletion (GDPR)

A user should have the ability to delete their account, as should an administrator. In this case, we want to keep the physical row in the DB for the purposes of data consistency and reporting, but we should completely remove any personally identifiable information (PII):

“[A]n identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.” source


This comment has been minimized.


michaelbromley commented Oct 24, 2018

Issue: Account enumeration attacks

Since Customer's emailAddress is constrained to be unique, and we allow the customer to change their emailAddress, this opens the door to an enumeration attack. Consider:

  1. Attacker creates an account with the email address ""
  2. Attacker goes to own account page and attempts to update own account with new address ""
  3. If a customer with the email "" already exists, we cannot allow this change as it would violate the unique constraint. We return an error of some kind.
  4. Now the attacker knows that Joe Smith has an account with us.
  5. Attacker repeats this process (likely in an automated fashion directly against the GraphQL API) to build up a list of all of our registered users' email addresses.

The same process could also be taken against the "create account" endpoint, but would be a little less efficient since it would create a lot of new accounts for non-matching email addresses.


In the case outlined above, the disclosure of the existing email address is necessary and unavoidable. However, is it so bad?

Many well-known sites also allow such enumeration:

This answer basically says it is a non-issue:

I tend to think it is of low severity since email addresses are public information in general.


The most practical mitigation I can think of would be some kind of throttling on the frequency that a given Customer may attempt to change their emailAddress.


This comment has been minimized.


michaelbromley commented Nov 6, 2018

Email address verification

Email address verification is quite a common pattern. It usually works like this:

  1. User signs up with email address and a password.
  2. An email is sent to that address with a verification link. The link contains a unique token which is usually time-limited.
  3. Clicking the link tells the site that the email link has been clicked, so we can safely assume that the person who registered under this email address does indeed control the account.

The purpose of this process is:

  • We ensure the user actually owns the account. Spam prevention & also protection against a mis-typed email address.
  • We can decide to withhold certain critical information from a non-verified account, so that, e.g. if an email address was mis-typed, the inadvertant account holder now does not get lots of unwanted correspondance.
  • If a person accidentally creates an account under a wrong email address, and later wants to reset the password, there will be no way to do this since the password reset email will go to an inbox not actually controlled by the user. Requiring registration up-front better alerts the user to the mistake earlier on, before potentially many transactions are made.

How to handle

Some companies may want to implement email verification and others not. We should make it optional, i.e. a Customer entity would have a verified property, and the developer can choose to use this or not when deciding whether certain functions are permissible.

In general, much of the implementation will be contained in however we handle emails in general (issue to be created).


This comment has been minimized.


michaelbromley commented Nov 9, 2018

Review this discussion on the Sylius repo for another argument for verification: Sylius/Sylius#6883


This comment has been minimized.


michaelbromley commented Nov 20, 2018

Customer Registration Flow


In the diagram above, the password is only set after the verification link has been clicked. This works in the same way as a typical the "forgotten password" flow.

The reasoning is that there is no additional security to setting & then verifying a password on registration, since the user could also register with a password and then after that invoke the forgotten password flow, which we must provide, otherwise a forgotten initial registration password would render that email account void and unusable.

Therefore there is no additional security to be gained by requiring a password up-front.

Token expiry

The verification token expires after a configured time period (7 days in the current default config). After expiry a new token can be issued to the email address. Why then bother with an expiry if a new token can be immediately issued? The reason is that this prevents the scenario where the initial token is leaked somehow (email address compromised, email traffic intercepted) but now then real owner once again has control over the email account and the attacker does not.

michaelbromley added a commit that referenced this issue Nov 20, 2018

feat(server): Implement basics of User email verification flow
Relates to #33. Edge cases need checking and test should be written.

michaelbromley added a commit that referenced this issue Nov 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment