7

Give me few reasons why NOT to include email addresses in plain text form for unsubscribe link that gets sent out in our newsletters.

Right now it's: 

xyz.net/unsubscrible?uid=123&email=user@domamin.com

I am pushing for: 

xyz.net/unsubscrible?uid=123&key=(encrpted_email_md5hash).

I don't really like the idea of throwing email addresses in plain text, but need to convince my manager for possible threats.

Update: While all the answers were suggesting how I should secure it and NOT reason why I should secure it, I find do-ob's answer most appropriate.

xoail
  • 2,698
  • 4
  • 33
  • 65

8 Answers8

8

Because then you can unsubscribe somebody else. Ideally you want to use only a key:

xyz.net/unsubscrible?key=<some unique cryptographic hash>

I shouldn't be able to guess at ids and emails and cause some action to occur for somebody else.

Alex Howansky
  • 44,270
  • 7
  • 68
  • 92
6

For the same reason that banks don't have links like

bank.com/applycredit?ssn=123456789&name=john+smith&dob=19500101&married=true&address=...

it can easily be intercepted and interpreted.

  • Not fully correct. Emails have the destination address in plain text: it can be eavesdropped in the first place, so having it in URLs can be seen as a simple redundance – usr-local-ΕΨΗΕΛΩΝ Apr 26 '11 at 22:50
  • yeah... but I need to know why not to include email... as it is not that vital yet vital if something happens... need to know that something ;) – xoail Apr 26 '11 at 22:51
  • 1
    In that case the hacker wouldn't know the contents, whereas now, they know that `user@domain.com` was subscribed to `xyz.net` at some point and is unsubscribing. Information is gold. Replace `user@domain` with `abcd@senate` and `xyz.net` with `warezxxx.net` and you've got tabloid gold. –  Apr 26 '11 at 22:55
5

Pretty much every newsletter I get has a disclaimer at the bottom, something like:

This email was sent to YourName@Domain.com. To unsubscribe, click this link: xxxx

I find the explicit listing of my own email address in the newsletter to be helpful . Whether the email addy is in the unsubscribe link or not, seems irrelevant to me.

Suppose you don't publish the email address in the actual text of the message, or in the unsubscribe link. The email address is still in the email message header. As a result, I don't really see the need or reasoning behind obscuring it within the unsubscribe link.

Cheeso
  • 180,104
  • 92
  • 446
  • 681
  • Right, thats what my manager says, but I haven't come across a single unsubscribe link (in my subscriptions) that puts email in plain text... it really bothers me that my company does it in plain text and I just thought we should change... :) – xoail Apr 26 '11 at 22:56
3

Why not? Don't include it because it's not needed. What is that data being used for? Suggest that we don't include anything that we don't actually need on the querystring.

The only thing actually required is a unique identifier. It looks like you've got a unique identifier in the querystring already: uid.

A potential problem: what's stopping me automatically creating unsubscribe URLs and hitting ?uid= from 1 to 10 million?

Suggestion: create a user guid for each user in your table. Use that as your unsubscribe token. It won't be guessable or vulnerable to automated attacks.

foo.com/unsubscribe?u=<guid>
p.campbell
  • 91,713
  • 61
  • 243
  • 314
  • I was shooting to uid as key and another secure hash that will be used to make sure what you mentioned wont happen... guids will require maintaining them in database... not a bad idea but it will be awesome if I could avoid it... – xoail Apr 26 '11 at 23:01
  • @xoail: the good thing about the guid is that there's no maintenance; set a default value on the column (i.e. `NewID()` in SQL Server), or admittedly a change in your app when creating a new User. – p.campbell Apr 26 '11 at 23:06
  • yeah thats a good point... but back to my question.. why not to use email addresses in plain text? what would be the security flaws... – xoail Apr 26 '11 at 23:13
  • 1
    It's the most basic application of the KISS principle. Clearly, it's not needed, it serves no purpose, and it unnecessarily over-complicates the code. Without even considering security implications, you shouldn't have to justify why it should be removed. Your boss should have to justify why it should be added. – Alex Howansky Apr 27 '11 at 14:36
1

I'm guessing that uid is 'user id'. If you know the user id, then you should be able to determine the email address from that right? Seems like having the email in the url doesn't do anything. I guess if you don't have to include personal info, then best not do it.

Jason
  • 674
  • 4
  • 6
1

I agree that you do not need the email address if you have a different method of uniquely identifying the user. The only reason might be to indicate to the user the email address with which he/she is subscribed, but that it also obsolete since he/she obviously receives the email.

Leons
  • 2,524
  • 1
  • 18
  • 24
1

I could give you a very tricky answer, but you will find that having the full email address is not a so bad idea.

Having a URL containing an email address could be used by malicious proxies (ie. from public places) to store addresses and send spam. But if I suppose the public place has something malicious, better install a keylogger on the public computer and do even more bad.

Another point could be: if you are sending emails to valuable customers, an attacker may forge email addresses and unsubscribe them, actually reducing your communication strength. For this, you can add a crypto checksum to your URL (don't require CAPTCHA, people don't like it when unsubscribing), but then by encrypting (or just encoding in a non obvious way) the whole mail address you could solve the problem without using two parameters.

usr-local-ΕΨΗΕΛΩΝ
  • 23,317
  • 27
  • 132
  • 255
1

Since you're not using https, query parameters can be snooped on. This is a serious problem for mobile users, and users of laptops in places with free wi-fi like coffeeshops.

And since uid already maps to the email address, you don't need to expose identifying information like an email address to snoopers.

You do need to make sure that the unsubscribe doesn't happen as soon as they click on a link. That's a GET URL which should be idempotent (see section 9.1) meaning it shouldn't have authority to change the underlying database.

And I shouldn't have authority to unsubscribe you just by knowing your email address which I could do by forging a URL if uid is either guessable or not required.

Mike Samuel
  • 109,453
  • 27
  • 204
  • 234