1

I wonder if it would be a good idea if a shopping system would reuse existing user accounts across multiple orders. For example:

  • A person buys a concert ticket in an online shop. The ticket is mailed to them.

  • The person does not create a user account. Instead, an anonymous user entity is created and associated with the order.

  • A few weeks later, the person buys another ticket using the same e-mail address.

  • The system recognises the person by the e-mail adress and links the new order with the existing entity.
  • If the person has entered a different name etc. the system would also update this information in the existing entity.

Now you might ask: Why would I want to re-use the existing account instead of creating a new one? Because users can decide to “activate” their previously “anonymous” account (by requesting an e-mail with an activation link). It would be nice if they could then see the orders they made before the activation.

Yes, we could auto-activate the account after the first order and send the user their credentials. But they’d delete/forget/ignore the e-mail and would have to go through account recovery during the next checkout process, which would obviously be a horrible conversion breaker.

Therefore I wonder, is reusing the account a good idea from a security standpoint? If not, how could it be implemented otherwise if I want to make history available without hurting the UX too much?

lxg
  • 111
  • 5

1 Answers1

1

What you are proposing is basically having an account without any authentication. As long as you enter in a persons email, you are using their account.

If just entering an email address allows you to do anything of value (like viewing order history or personal info, placing new orders on the same credit card, change anything about past orders, etc.) you have a huge security problem. Anyone who knows the email of another person can impersonate that person. That is bad. Very bad.

If it does not allow you to do anything of value, the phrase "reusing the same account" becomes utterly meaningless since there isn't really any account to speak of. The only thing that happends is that two orders will have the same email in your database.

Now, if someone were to later create an account with that email (and verifying it in the process) you can not just assume that those orders were placed by the person who created the account. While you can have in your terms of use that the account is personal, an email isn't nececarily that. So you might be in legal trouble if you e.g. want to get the person who created the account to pay for the orders placed before the account was created.

Think about this scenario: Person A order something (potentially embarassing) using the email of person B. Person B later activates an account on that email. The item A ordered is now in the order history of B.

Anders
  • 64,406
  • 24
  • 178
  • 215
  • Thanks, but I don’t follow: When the account is activated, the user receives an e-mail with the password. Unless the attacker is a MITM, account access is confidential. And until the account is activated, nobody can access its confidential information. Could you describe the attack vector and the benefit of abusing such a feature? – lxg Dec 15 '16 at 20:38
  • @lxg Yeah, I realize this wasnt as clear as it sounded in my head... If you have to cerate an account to be able to view the order history (and account creation involves verifying the email) I don't think there is any security problem. But you can not know that the past orders were actually placed by the person creating the account, so there might be legal issues involved. – Anders Dec 15 '16 at 20:50
  • Ok, thanks for your thoughts. I clarified in my post that account activation requires e-mail verification. Sorry if this was unclear. – lxg Dec 15 '16 at 20:53
  • @lxg I also updated my answer, trying to make it a bit more clear. – Anders Dec 15 '16 at 21:01