This is an anonymous question sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough questions to ask and answer.
url in email: somepage.html?someuuid=xxxxxxxxxxxxxxxxxxxxx
someuuid is directly associated with a user, and a credit card on file.
Click the link in the email, visit page with someuuid in url, click ORDER, and your card on file is charged, without authentication.
Share the email or the link with someuuid in url, and if someone clicks on it, it will place the order with the card on file, without authentication.
Marketing is arguing that there’s higher conversion, and a competitive edge by not making people authenticate, and is blocking authentication from being added…insists that it’s some genius feature. Yes, in 2017 these are the arguments.
Please comment on the a) legality b) PCI compliance implications c) privacy, and d) ethics of building and publishing an email ordering system in this way.
I need strong arguments. Marketing isn’t listening. Help.
Top comments (7)
Can they prove that conversion is better? Do they have actual data that supports this statement, or is it anecdotal? If it's the latter (and I suspect that it is) Make them trot out the evidence. When they can't show that it's more effective without authentication (because they don't have data on the latter), use that as leverage. If they don't have supporting data, it's a baseless claim. I wouldn't want you to pit yourself against your own marketing dept (no one wants a hostile work environment), but this is a problematic practice.
How are the UUIDs generated? Do they follow a pattern. Is the endpoint open to attacks from an interative attacker/bot? Is the page that opens a vulnerable attack surface (could an attacker/bot change what's being ordered, how much)
Is there a way to retrofit the system to a safer practice? Eg, push to login, with cookies to establish that you're already logged in.
Lastly, a terrible idea: Show the problem in action. If the marketing team is in support of it, have them put their money where their mouth is and send out the email with their account information to potentially interested parties. The risk will be theirs to bear, and describe it in real terms.
I'm not sure about the lagality of this, but it definitely seems insecure. This pattern is used for some should be POST request but this is a GET because of this constraint, but I'd doubt the legality of this and it just seems kind of dumb.
Can't help you more than just agreeing about it being a bad idea. What if a bot crawls the link?
There's a reason the web is built the way it is.
I would think that it would be hard to maintain PCI DSS compliance under this policy. PCI DSS 3.1 requires TLS 1.1 during the transaction. PCI DSS 3.0 required encryption as well (but with a lower bar for the encryption algorithm). Email is unencrypted. This means that the user's only interaction with your system is over an unencrypted connection.
If you move forward with this, they will likely lose their ability to process credit cards after the first audit.
My reading of the question was that the email contains a link that goes to the website where the transaction is handled.
The thing I'm trying to figure out is who would want to attack or abuse this system and why.
If an adversary manages to intercept emails and places unwanted orders that's going to make for some bad publicity. I have no idea about how likely this is. But it is possible. As Joe Steinbring mentioned, email 'in transit' is not guaranteed to be encrypted.
Another option is that someone can troll a customer if they have access to their inbox. Since the links bypass authentication the troll can place quite a lot of orders before being discovered.
There is a real risk for bad publicity. So the conversion improvement must be rather impressive to justify this order method.
...
I should add I'm not familiar with webshops being able to bill your credit card directly. Usually when I place an order I go through a third party payment provider.
How is that in this situation? For a regular order, does the customer have to go through a payment provider?
One may be able to generate bunch of URLs then make GET requests on the generated URLs and the customers will get charged without knowing it. As a result you will lost customers and they will probably sue the company into oblivion.
I'll just leave this right here: troyhunt.com/strawberrynet-privacy...
See also (at about 51:00): youtu.be/gVXEwfH6FLc