Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Customer Accounts #33
A Customer can be a guest (has no associated User) or registered (has an associated User).
An account can be created in one of two ways:
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.
There are 2 questions to resolve regarding registration:
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):
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:
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: https://markitzeroday.com/enumeration/privacy/2017/06/20/to-be-enumerated-or-not-to-be.html
This answer basically says it is a non-issue: https://security.stackexchange.com/a/42874
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.
Email address verification
Email address verification is quite a common pattern. It usually works like this:
The purpose of this process is:
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
In general, much of the implementation will be contained in however we handle emails in general (issue to be created).
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.
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.