Warning to the paranoid and secretive

[Jeremy Howard]

Well, to 99.99% of you this will be of no interest, but for the 0.01% of you are paranoid or have reason to be particularly secretive, I want to be completely upfront about a change I've just made.

When you send a message now through the web interface or the FastMail.FM SMTP server, a header is added to your message like this:

X-Sasl: RWzarwyQLaL9fxp5KdWX1Q

This is a header that contains an encrypted version of your username. This will be used by us if someone complains of mail abuse or spam from FastMail.FM, so that we can track down who is responsible (since they may well forge their email address).

What this means is that someone can work out who you are if you firstly send them a message from your account with your true From address, and then send again with some other address, since the X-Sasl header will be the same in each case.

Other than this case, I don't think that your username can be reverse engineered from the encrypted id--we use a one way hash function so that your username remains private if you want it to be. Crypto gurus--we're using Perl's Digest::MD5 for the hashing; please let us know if you are aware of any weakness with this approach.

For the 99.99% of you who found this message completely irrelevent, here's a funny (off-topic) story to entertain you... Yesterday I was sitting next to my girlfriend, Evelyn, when she asked me about how she could get her own web site. I told her she should search Google for a web host, and suggested that it should support ASP and Webdav since she could then use Dreamweaver Ultradev, a program that she recently purchased.

...A few minutes later I hear her muttering "huh? this site's got nothing to do with web hosting..." and then "hang on... Hey Jeremy--you wrote this page!!!" It was the strangest thing---out of the 2 billion pages in Google's cache Evelyn happened to click on one which I wrote! She searched for webdav asp host and on the first page of results found this... Funny coincidence...

[pobelly]

i'm fairly ignorant about this sort of thing, but wouldn't it be possible (and maybe better) to use an encrypted verision of something other than the username, but still meaningful to you, like a user id number or whatnot? then, even if the encryption somehow failed, the information exposed wouldn't mean much to anyone but you.

[Jeremy Howard]

That's pretty much a non-issue. Because we use a one-way function there's no way to get the username back from the hashed version. So it really has the same effect as hashing the userid.

[pobelly]

oh, well... in that case, ummm... i like your google story.

[psalzer]

I think it's a good thing. The ability to send from different addresses easily is a very, very valuable thing to me. I'm not trying to appear to be a different person, though and my real name appears on all of them. It's great to have one account which can encompass a whole bunch of domains, though, and I would hate for that not to be possible due to abuse somewhere down the line. The idea of someone being able to easily forge an e-mail is not a comfortable thought either. I know you say that anyone can do it anyway, but that's not really so. Anyone who knows how, maybe, but that's not everyone, at least as far as making it seem like it's coming from a different address is concerned. I'm happy to see as many protections as possible so that this feature remains safe for legitimate use.

[zimerman]

Hello.

Being paranoid and secretive myself (and proud of it), I have a few comments to make on X-Sasl-enc:

1. False sense of security. Forging a message appearing to come from a Fastmail user, via Fastmail infrastructure, and with a valid X-Sasl-enc header line - is very easy. Unless you have supporting evidence (such as audit logs), you wouldn't be able to prove a specific user has sent a specific problematic message. And if you have an audit log, why bother with X-Sasl-enc?

2. Dictionary attack. I don't know how exactly you use MD5 to hash the username (and don't currently have the time to check), but if you merely feed it to the hash function without keying it with a secret, a potential attacker can dictionary attack X-Sasl-enc, and discover the username who sent it. This is of greater concern if the attacker has reason to believe one of few sent a message - feeding those few usernames to the hash is simple and effective.

3. Praise. I do wish to praise you for making the inclusion of X-Sasl-enc public knowledge. I feel this is exactly the right way to get security done right in the software world, and specifically in Internet software.

So, this was the praise and criticism. Now comes the practical talk:

1. If you aren't keying the MD5 hash, doing it would enhance security without harming performing. It would make what is known as "known-plaintext-attacks" harder to perform, and the dictionary attack would become virtually impossible to perform.

2. Adding something unique and random, yet known, to the hash would solve the problem of being able to track a specific sender over several e-mails. An example of such a unique feature is the Message-Id of the e-mail.
As each message would carry a unique, yet completely trackable, X-Sasl-enc header line - nobody would be able to links two messages together. And even if he has a dozen different messages he knows are from the same source, figuring out the username would require a dictionary attack (and if you keyed the hash with a secret - well, even that would be fairly darn hard).
The drawback - it would be harder for you to discover who the sender is, as you would need to dictionary attack the hash yourself. As you have the dictionary at hand (the list of all usernames), it is still pretty easy.
You would need to conduct an experiment to discover whether this is feasable, but I suspect it is, and in my opinion, quite worth the trouble.

3. Taking both of these approaches together (keying with a secret and with the Message-Id), and adding also the time-stamp of the message, you make it far harder to forge a message appearing to come from Fastmail, as the attacker would have to use the same Message-Id and time-stamp over and over, which is certainly less attractive.

To summarize:

1. Keying with a secret.
2. Keying with the Message-Id.
3. Keying with the time-stamp.

The drawback is outlined above.

There may well be flaws in what I just described. It seems solid enough to me, but public review never hurts.

Additionally, there are other ways to achieve this goal, that might be better. One that pops to mind is to symmetrically encrypt the username along with the time-stamp and some random bits with a secret key, placing the result in X-Sasl-enc.
It appears to have all the advantages outlined above, without the disadvantage to you of having to work hard to discover the sender. It would probably be a bit heavier on the hardware, though.

If I scared anybody with this post, I apologize. But there is a toll to being paranoid and secretive...
And now, I shall happily move on to doing some other paranoid and/or secretive stuff. Can't tell you what, or I'll have to kill you. Sorry.

-- Nimrod

[Jeremy Howard]

Originally posted by zimerman
Being paranoid and secretive myself (and proud of it), I have a few comments to make on X-Sasl-enc:

Thank you. Being somewhat paranoid and secretive myself from time to time, I can empathise and this is why I made this public.

1. False sense of security.

It's not going to be used as proof. It just helps us know where to start looking (the logs get pretty big...)

2. Dictionary attack.

Already doing this. A 32 byte salt is added before doing the digest. The salt is a random string (it's whatever happened to be in /dev/urandom when I wrote the code).

2. Adding something unique and random, yet known, to the hash would solve the problem of being able to track a specific sender over several e-mails. An example of such a unique feature is the Message-Id of the e-mail.

Now that's a good idea. I'll do that.

[syn]

i agree with nimrod.

md5 is vulnerable to a dictionary attack, and in this case, if the attacker already has subset of usernames to try, the hash is fairly easy to brute force.

i think keying with a secret is essential, if only to eliminate the possibility of the dictionary attack. it also has the side benefit of making it impossible to forge a fastmail message from outside the fastmail infrastructure (e.g. by just hashing an arbitrary username and manually tacking on an X-Sasl header).

keying with a message-id or timestamp would be useful, in addition to keying with the secret, for increased protection for user anonymity from message to message while reserving the ability to track. that is, hashes for each message would then be unique, but each message would still be traceable.

i don't think i've covered anything new that nimrod didn't already talk about, except to add my endorsement of the idea.

-originalsyn

[Jeremy Howard]

Originally posted by syn
md5 is vulnerable to a dictionary attack, and in this case, if the attacker already has subset of usernames to try, the hash is fairly easy to brute force.

As I said, we're already keying with a secret, so it's not vunerable. Perhaps you started composing your last message before I posted mine...

i think keying with a secret is essential, if only to eliminate the possibility of the dictionary attack. it also has the side benefit of making it impossible to forge a fastmail message from outside the fastmail infrastructure.

Not really. If you've already sent a message with that username, someone else can just copy the sasl header.

keying with a message-id or timestamp would be useful, in addition to keying with the secret, for increased protection for user anonymity from message to message while reserving the ability to track.

Actually, with this addition it also makes it (kinda) impossible to forge a message. I say 'kinda' because you could always include the same message-id and timestamp in your headers. But that looks pretty dodgy because your message is being sent at a different time to what's in your headers.

Anyway, this is not designed to be 'proof', it's just a bit of help for us to track down the right bit of our audit logs if we have to.

BTW, we don't actually provide this information to 3rd parties unless legally required. We do use it for our own mail abuse handling internally however. For instance, we've had someone ask for assistance with a breaking-and-entering investigation where a PC on the premises had been used to access FastMail.FM. Our answer was that we'd only provide the username that had accessed us from that IP if the request came through the proper channels. Interestingly, we never heard back from them...

[pobelly]

Our answer was that we'd only provide the username that had accessed us from that IP if the request came through the proper channels.

well, geez... i would HOPE so...

does that include people who are really good at posing as Proper Channels?

[Jeremy Howard]

Yes, under some definition of 'really good'. They would have to be good enough to fool our local police department in Australia to get them to get the information from us. We wouldn't provide the information directly to anyone other than the local authorities.

[Jeremy Howard]

I've now implemented the discussed enhancement to the X-Saslenc header. It is now encyrypted with the added salt of the current epoch (# seconds since Jan 1 1970) such that two messages from the same person will have different X-Saslenc headers.

Also, there's some headers added to inbound messages: X-Attached, which lists any attachments; and X-Mail-from, which is the envelope FROM address. You can use these in any Rules if you need them.

[jason849]

Hi,

The x-sasl header is not encrypted - just look at your full header.
Please fix this problem.

[lux]

It isn't??

It is for me. It shows: X-sasl-enc

[jason849]

Sorry, I'm a moron. I'm looking my my sent-mail, which has the X-sasl header. When I get the e-mail, the header is X-sasl-enc, and it is encrypted. I assumed that the sent-mail would have the same X-headers as the e-mail. My apologies.