Email unsubscribe handling security

Question

There is another question with similar title: Unsubscribe safely however my question addresses completely another issue.

I am trying to set up a notification system in the website, that will send emails to users based on different events on the webiste, it might be e.g. receiving on-site message from another user, someone purchasing your product, leaving a feedback etc. - there are a lot of things that might trigger a notification. Users from their account settings can choose for which exact events they want to receive an email.

I was reading email best practices from mailgun https://documentation.mailgun.com/best_practices.html#unsubscribe-handling

and I learnt that

It is important to give you recipients the ability to unsubscribe from emails. First, it is required by the CAN-Spam Act. Second, if you don’t give them this option, they are more likely to click on the spam complaint button, which will cause more harm than allowing them to unsubscribe. Finally, many ESPs look for unsubscribe links and are more likely to filter your email if they don’t have them.

Also, from gmail guidelines about Unsubscribing https://support.google.com/mail/answer/81126?hl=en

A user must be able to unsubscribe from your mailing list through one of the following means:

A prominent link in the body of an email leading users to a page confirming his or her unsubscription (no input from the user, other than confirmation, should be required). By replying to your email with an unsubscribe request.

So, I do want to have the unsubscribe option in the email. I would not really prefer to use the second option (By replying to your email) as it might have some technical difficulties (e.g. I have to the notification type in response email, have to check the email for inbox regularly and maybe smth else I have not thought of). I'm thinking of having a unsubscribe link in the email and because their notification settings can be changed only after they are logged in, it contradicts with gmail's no input from the user, other than confirmation, should be required point.

So, it looks like I am left with some "public" url for changing their notification settings. From as I read and used to handle similar cases - e.g. when confirming the email or password recovery, I am sending an email that in url contains only randomly generated hash(sha512), NOT in any way revealing the user info, which expires in less than 1 hour(I used to put 15 mins).

Now, in case of unsubscribe link, even though I include random hash (and maybe the notification type id as well), that is tied to the user in the database, because its public, if it the email/link accidentally shared or posted somewhere, someone else can edit that user's notification preferences. On the other hand, generating random hash with each notification and saving in the db, also expiring them after some time sounds overkill for me, also considering that as it expires, if the user clicks on unsubscribe link in old email, it will not work.

I could not find any useful information out there, so I am seeking some advice on how to correctly and securely approach user unsubscribing in general and specifically in cases similar to mine. Any help is very much appreciated.

Thanks

Answer 1

This is a good example for a case where usability and security do not go hand in hand.

A user wants usability: They want to be able to click the link and be unsubscribed. They want this to always work (not just X amount of time after receiving the email, and definitely not with X being 15 minutes or an hour).

You want security: You don't want an attacker do be able to force-unsubsribe your users.

Now lets analyze these needs:

Usability

The usability one is rather important. If you do not allow easy unsubscribe:

• your brand will suffer an image damage
• your emails will be treated as spam
• you are in violation of the CAN-SPAM Act (see eg here: The law also requires that the unsubscribe mechanism must be able to process opt-out requests for at least 30 days after the transmission of the original message)

Security

So you are using a securely generated, long, random token, meaning that an attacker cannot just brute-force your unsubscribe form to unsubscribe a large portion of your users.

At most, an attacker can unsubscribe single users after they somehow revealed their unsubscribe token.

So what's really to worry about? No attacker will use social engineering to get the unsubscribe token of users. They will also not hack into the email of your users or your database just to unsubscribe them from your newsletter.

So the only likely attack scenario is: A user accidentally posts your newsletter including their unsubscribe token to a website. Someone sees this and decides to unsubscribe that user.

This may cause a small annoyance to you and possibly the user, but it is a scenario which is unlikely to happen often.

Conclusion

A correctly generated random token is enough for an unsubscribe link.

The dangers of this token being revealed are low, and using any other mechanisms (such as requiring logins or expiring the token after a short time) are generally not acceptable.

At most, you could expire a token after 30 days. But that also means that you need to have more than one token per user.

Answer 2

I might be missing something, but I don't think you need to do the unsubscribe thing anyway.

The requirements and best practice relating to having an easy unsubscribe function relate to services which are essentially an email service e.g. a mail list, promotional emails from vendors etc.

In your case, you are talking about notifications sent to your users and have stated they can control the notifications via their account settings page. Essentially, you have already given them control and the ability to unsubscribe. All you need to do is add a link at the bottom of the notification emails to the URL for the account settings page. Job done.

Answer 3

Why not have the "unsubscribe"-link direct users to a page protected by your regular authentication methods?

Perhaps https://example.org/preferences/notifications/ where it is here that the email messages can be turned on/off.

This will be as secure as the rest of your user's preferences options, is straightforward to reach (presuming that your user is able to recall their login details) and will enable finer-grained abilities to adjust the email settings (e.g. selecting a daily/weekly digest) as opposed to the binary subscribe/unsubscribe.