Authenticating sender of emails using hashes in the email address

[amyxzhang]

One thing we care about is making sure people aren't spoofing the email address sender field.

The way we've come up with how to do this is:

• for every pair of email addresses, they can get a hash (randomly generated string). So in murmur this would be a hash for every person in the list that is trying to send an email to the murmur list. In squadbox, this would be a person trying to contact squadbox owner.
• Not sure exactly the workflow, but we would have both parties verify and agree upon said hash. This hash would be stored with the email address in the system. An initial email can be sent to the user from that address (email+) so that the user can add it to their contact list.
• Then, the emailer would send all their email to email+@murmur/squadbox.csail. If an email comes by from someone with that email address but no hash, then it is flagged or returned. Benefit of this approach is that email with the hash gets stored in the user's contacts so they don't have to remember it.
• If the hash is compromised (it appears that someone else is sending emails through with the correct hash) - then a new hash can be generated using the same method.

[karger]

We can also arrange for murmur to check pgp signatures and such, to provide multiple channels for authentication.

On 01/24/2017 04:15 PM, Amy Zhang wrote:

One thing we care about is making sure people aren't spoofing the email address sender field.

The way we've come up with how to do this is:

• for every pair of email addresses, they can get a hash (randomly generated string). So in murmur this would be a hash for every person in the list that is trying to send an email to the murmur list. In squadbox, this would be a person trying to contact squadbox owner.
• Not sure exactly the workflow, but we would have both parties verify and agree upon said hash. This hash would be stored with the email address in the system. An initial email can be sent to the user from that address (email+) so that the user can add it to their contact list.
• Then, the emailer would send all their email to email+@murmur/squadbox.csail. If an email comes by from someone with that email address but no hash, then it is flagged or returned. Benefit of this approach is that email with the hash gets stored in the user's contacts so they don't have to remember it.
• If the hash is compromised (it appears that someone else is sending emails through with the correct hash) - then a new hash can be generated using the same method.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/haystack/murmur/issues/135, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFpXvmKDV6k8Fk14FJX3N_Vs0hLjUo6ks5rVmoMgaJpZM4Lsy26.

[oliverjd]

@amyxzhang @kmahar

Here's how I'm thinking of going about doing the email sender verification using hashes in the address. Let me know if you think it's an appropriate way to go about it:

Murmur:

• want every person who can send emails to the list to be published to have to send them to a "secure" email (i.e. group+hash@host). To do this, modify add_member function to generate the hash at the same time for each MemberGroup entry, and change the mail received in smtp_handler for murmur so that it first checks if "to" address is group+hash and if that hash matches any of the hashes in MemberGroup entries that are allowed to send to this list, if it doesn't then reject it
• hashes are stored with membergroup object ^^ what about if we want to let people who are not members of the group email the group? add them to the whitelist (see below)? or should we store all hashes as whitelist objects and make a whitelist entry every time a new member is added automatically?

Squadbox:

• we have 2 workflows - 1. people email user@squadbox custom email which is then approved and forwarded to real email, 2. people email real email, gmail filter forwards that to squadbox, once verified it is returned to them
• for 1: people email user+hash@squadbox where hash is unique to each whitelisted person sender. if hash doesn't match the hash stored for the whitelisted send-from entry, email is rejected/held for moderation, if it does it is automatically forwarded
• for 2, more complicated: people email personaluseremail+hash@gmail.com, then the gmail filter forwards it to squadbox if that email isn't in the forward filter (We add the hash to the forward filter during the gmail contacts import step - hash is actually generated at this point)
• so for squadbox hash is generated in update_whitelist_blacklist function and saved with whiteorblacklist model

[karger]

so the "right" way to do this is for people to sign their email e.g. with pgp and for murmur to check the signatures. the problem is that most people don't know how to sign their email. But for those who do, it's a more correct and convenient solution than the hashes. Is there a way to support this as well?

Note a risk of this hashing approach: if someone else is CC'ed in the "To:" of the email, then they get access to the secret and can impersonate the sender. this does suggest its important for each sender to have a different hash, so that only they have to change their address book if they mess up.

for senders who leave off the hash, we can send an email back to the sender asking them to reply or click a link to confirm that they sent the mail---this provides proof they are not spoofing. although, if we allow a confirmation by reply, we have to put a secret into the reply, e.g. in the subject line, since otherwise a spoofing sender would know what the confirmation message would look like and could send it without ever having received it!

On 2/9/2017 10:00 PM, Oliver Dunkley wrote:

@amyxzhang https://github.com/amyxzhang @kmahar https://github.com/kmahar

Here's how I'm thinking of going about doing the email sender verification using hashes in the address. Let me know if you think it's an appropriate way to go about it:

Murmur:

• want every person who can send emails to the list to be published to have to send them to a "secure" email (i.e. group+hash@host). To do this, modify add_member function to generate the hash at the same time for each MemberGroup entry, and change the mail received in smtp_handler for murmur so that it first checks if "to" address is group+hash and if that hash matches any of the hashes in MemberGroup entries that are allowed to send to this list, if it doesn't then reject it
• hashes are stored with membergroup object ^^ what about if we want to let people who are not members of the group email the group? add them to the whitelist (see below)? or should we store all hashes as whitelist objects and make a whitelist entry every time a new member is added automatically?

Squadbox:

• we have 2 workflows - 1. people email user@squadbox custom email which is then approved and forwarded to real email, 2. people email real email, gmail filter forwards that to squadbox, once verified it is returned to them
• for 1: people email user+hash@squadbox where hash is unique to each whitelisted person sender. if hash doesn't match the hash stored for the whitelisted send-from entry, email is rejected/held for moderation, if it does it is automatically forwarded
• for 2, more complicated: people email personaluseremail+hash@gmail.com mailto:personaluseremail+hash@gmail.com, then the gmail filter forwards it to squadbox if that email isn't in the forward filter (We add the hash to the forward filter during the gmail contacts import step - hash is actually generated at this point)
• so for squadbox hash is generated in update_whitelist_blacklist function and saved with whiteorblacklist model

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/haystack/murmur/issues/135#issuecomment-278845077, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFpXs-nDVgteZ-UAfrJ5iuylO1NqQnZks5ra9LggaJpZM4Lsy26.

[oliverjd]

@karger Good point for sending back a confirmation email allowing verification if people forget/don't have the hash but have an account on the website. I will look into verifying PGP signed messages as well as I suspect there will be a package that can implement that fairly easily.

[kmahar]

All sounds good @oliverjd. You could also add a hash field for ForwardingList, for the case where a list forwards to a Murmur group. Then that mailing list would put email+x@murmur as a member.

As for having people who are not in a Murmur group post to it, we have not allowed this so far outside of people who post to a mailing list that forwards to a Murmur group. I'm not sure if we should use whitelist for that case; I see that table as being more for tracking whose posts don't need to be moderated, as opposed to whose posts are allowed to be made at all.