How can I secure a reply-via-email system?

I am working on setting up a reply-via-email system (similar in functionality to what Basecamp uses) in which a user can reply to an email generated by the system in order to add a message to a thread.

In order to do this, our system needs two pieces of information:

1. the thread ID


2. the user ID for the person sending the reply email

I have a setup in which emails are forwarded to a webhook, and I can get the thread ID and user ID out of the "to" header in that email, so getting the information is not a problem.

My goal is to secure this so that the potential for damage through accidental or malicious misuse is minimized.

My initial thoughts are:

• create a database record for each thread ID/ replying user ID combination whenever a new message is created. The record contains the thread and user ID, a timestamp, a random salt, and a token.


• the token is a hash of the rest of the data in the record (including the salt)


• set the reply-to email address to use this format: thread_id-token


• When the system receives a reply email, we look up the token in the database and make sure that the token exists and matches the thread_id sent with the email.


• If it does, we add the message to the thread, and if not, we ignore it (or maybe log it)

My reasoning:

• a token prevents sending messages just by guessing a thread_id and user_id combo


• the salt and timestamp will make it very hard to guess a token if a valid thread_id and user_id combo is known or guessed


• including the thread_id and verifying that it matches the token will make it very hard to randomly guess a valid token


• the timestamp also allows us to set an expiration time for tokens if we wish

In this scheme, I think that there are only two vulnerabilities:

1. Someone can steal the token


2. With database access, all tokens are known

I don't see a way to prevent token theft since it's in the email header and we have no control over the email chain once it leaves our system. It is basically a very limited-access password equivalent that would let a malicious user send messages to a specific thread. For the database possibility, if they have complete access, then they can do much worse then send unwanted messages. However, limited access to the token table would allow them to impersonate any user in any thread and send messages.

My questions are:

1. Is there a best-practices (or maybe just better) way to do this?


2. If not, are there low-cost ways of mitigating the threat of token theft or token-table access?


3. Are there vulnerabilities I haven't thought of but should be concerned with?