What are the security implications of allowing guest checkout using an email bound to known account?

Question

For a webshop, we allow customers to place an order either as a logged in user, or as a guest.

Guest checkout in itself is a quite common feature for webshops. The webshop in question is selling physical goods, so customers will still be required to fill in their name, email and address information. As such, a guest order is by no means an anonymous order.

Analysis of web traffic has shown that even if the customer has previously created an account, the may, for various reasons, not want to log in when they make a purchase. In these cases, the fact that they created an account on an earlier date, serves as a barrier to what they want to accomplish: place an order.

Because we would like to minimize barriers (in order to optimise conversion), somebody suggested that we could allow guest-checkout for customers with an email address, even if the email address has previously been used to register an account. Registered accounts are bound to an email address. This registration functionality already supplies a would be attacker with an attack surface for email address enumeration.

In other words: even if an email address is bound to a registered customer, a customer should be allowed to checkout as a guest, with said email address, without logging in.
Orders placed this way would be treated identical to any other guest order, whioh means that they would not be visible in the order history, etc. that is available for users that placed orders while logged in.

So, my question is:
Would the above scenario open up any unexpected security implications?

Answer 1

There is no concern if you are not disclosing anything to anonymous users. When the email address on a guest order matches an existing account, you should proceed as if that account didn't exist. Prompting for a login after getting that information can indicate that the account exists.

Always guide users to the ideal workflow. The use of an established account will make auditing easier for both you and the customer. The availability of order status and history are frequently useful for reasons not directly related to your security. If the customer is expecting order history, then a gentle reminder to login is actually helpful.

When in doubt, ask. I would give the customer the option to login or checkout as guest as the first option after proceeding to checkout. This option should be given before asking for identifying information such as name, address, or payment details. You could encourage users to login by populating billing/shipping information from their account, if you were so inclined.

Mitigate brute force attacks. Regardless of whether you implement a guest option, your process for recovering registered accounts should not indicate whether that user/email is registered. This is somewhat tangential to guest checkout, but it is related since users may checkout as guests because they forgot their credentials. Personally, I would rather reset my password and use saved info than dig out my credit card.

E.g., ask for the email address associated with the account, then display the same message regardless of whether an account exists, e.g.,: "We are searching our database for an account associated with the [email protected] email address. If we find an account, we will send instructions for resetting the password to that address. This may take a few minutes."

The email can explain/link your password reset process on a match, or it can advise them to choose between creating an account or checkout as guest in the absence of a match. As long as the existence of the account is only disclosed in an email to the account owner, there is no appreciable risk.

Answer 2

I am by no means an expert on such systems but I'd like to share something that comes to my mind with this approach, maybe it will be of some use.

Depending on how this dual system is implemented, I think the concept of anonymity COULD potentially take a hit from this approach. For example, a customer enters some email address, [email protected]. Now, you say that you want the system to be able to checkout as a guest, even if [email protected] belongs to an existing consumer. Well, that's fine, but that means there must exist some internal logic that had to report this fact back to the application. Consequently, it is possible that someone "watching" this interaction take place now deduces that there is actually a customer in your database with such an email, and maybe decides to try and authenticate as this user. Obviously, this might not even matter, but perhaps it might be worth considering.

Answer 3

The scenario explained I can't see it opening up any unexpected implications as long as the new system is deployed correctly.

The main point to consider would be what the UID is that ties registered customers orders together? It is likely that if an existing customer is unable to place an order as a guest with the email address they have already registered with, this might highlight that the email address is the UID used, preventing you from moving forwards with your plans prior to any changes.