14

I am thinking that I create a deactivation code put that in the unsubscribe link along with their user id. Then when a recipient of my newsletter clicks the link, I can look up their user id and see if the deactivation code matches.

Does this sound like the best way?

What are some other ways?

Tony
  • 18,776
  • 31
  • 129
  • 193

3 Answers3

16

From an end-user perspective, single-click unsubscribe is excellent.

However, using hash(id + secret) is insecure because a clever attacker can very quickly "brute force" the secret, then proceed to unsubscribe every user in your DB simply by incrementing the user ID.

It is much more secure to keep the user ID "semi-secret" on the server and use the e-mail address to lookup the user upon unsubscribe. This way, a successful unsubscribe requires pairing an email address with the correct user ID.

You can make this even more secure by saving a truly secret key or nonce for each user and using that instead of the user ID. This is especially necessary if the email + user ID pairs are published.

So, for example, your unsubscribe link would look like this:

http://example.com/unsubscribe?email={$email}&hash={$hash}

And a server-side function to generate $hash would look like this in PHP:

<?php
function unsubscribeHash($id, $email) {
    $hashSecret = 'Fz!Fx~36N66>io3B-vlPDshdRxos8JjCd4+Ld-s2^ca{19Q/5u';
    return sha1($id . $email . $hashSecret);
}
?>

Then, to complete the unsubscribe, you will lookup the user by email, and verify

$_GET['hash'] == unsubscribeHash($user_id, $_GET['email'])

jchook
  • 6,690
  • 5
  • 38
  • 40
11

You could just use an hashing algorithm to secure the userID (so that nobody can unregister all your DB with a nasty loop).

You'll end up with two params : userID and hash.

The advantage is that you won't need to store any mapping between deactivation code and userID.

MatthieuP
  • 1,116
  • 5
  • 12
  • Let me get this straight... the userID param in this case would be hashed with the hash param. So the params are userID and hash, and then hash(hashedUserID,hash) = userID ....correct? – Tony May 12 '09 at 18:24
  • 2
    I think he means url = /unsub?userID=x&hash=$hash(x + secret), where secret is something you don't reveal. – Chase Seibert May 12 '09 at 20:01
  • Then I have to keep the secret in the database which would essentially be the deactivation code. So what's the advantage? – Tony May 12 '09 at 20:52
  • 2
    No database involved, because you'll have only one secret for all your application. The secret will only appear (once) in your code. – MatthieuP May 13 '09 at 02:06
  • 2
    I would not include the userID from the DB, instead just use the email as this is an already exposed information in an email. See duplicate here: http://stackoverflow.com/questions/1240915/how-to-add-one-click-unsubscribe-functionality-to-email-newletters – Karussell Feb 19 '16 at 13:47
4

From a user perspective, do not require the user to input the e-mail address to unsubscribe. An approach that has all the information embedded in the link (such as you describe) is much better.

g .
  • 8,110
  • 5
  • 38
  • 48