Easy protocol for email authentication

Question

I'm cooking up a very simple system to send commands to a remote server via email. Everytime an email is sent to [email protected], the server runs a python script that does something different based on the recipient do_something, and uses the email content and metadata as parameters for whatever task it will perform. This will be used to provide services through email for a specific set of users that don't have direct Internet connection must of the time. Users don't write emails themselves, but use a small application that generates all necessary metadata.

It is of course very important to authenticate users reliably. I could implement some public key cryptography protocol, but a friend suggested me the following idea, which is very easy to implement, and seems reliable enough for me:

I generate a password for each user (identified by his email address), say a random string of size 2K. The server knows the password for each user, and each user knows his password. The user application generates an email for the corresponding task with all necesary data. After it has finished, it concatenates some of the email metadata (say sender and timestamp to avoid collisions for the same user) with the user password and computes a secure hash (I'm currently using SHA-512). It then attaches this hash to the generated email. The server gets the email and calculates the same hash (remember it knows the supposed sender password). If it matches with the hash attached in the email, it is considered authenticated.

Now suppose that I can reliable make each user get his password (not by electronic means). Is this mechanism secure? I know I'm probably reinventing a lot (rather old) of wheels here, so please forgive my ignorance on the subject. I do know that SHA hashes are virtually irreversible, and that is the main reason why I think this strategy might work.

Thanks in advance.

Answer 1

You are trying to use a MAC. Applying a hash function on the concatenation of the password and some other data is a custom MAC, and not a very good one with usual hash functions like SHA-512 because of the length extension attack. That's why HMAC was invented.

Using HMAC with a shared secret is a good authentication method. However, due to the inherent insecurity of emails, you would probably want some encryption, too, and for that you should just use OpenPGP (with its OpenSource implementation). Using a software system which already exist is both safer and easier than reimplementing your own system.

Regardless of the authentication method you use, you should add an anti-replay attack: an attacker could send a valid email (which he observed in transit) a second time, thus triggering the email effect again. Replay attacks laugh at MAC and encryption. To defeat them, the server must "remember" past emails and discard exact duplicates.

Answer 2

Tom's got a great perspective on how to bring the general idea of the system you suggest up to snuff and it's biggest risk - replay attack.

A few other thoughts that might give you something to ponder:

What does this protect?

With the scheme you have, there's not only replay attack but the rick of user password getting stolen or lost. Some of the fixes to replay attacks (like putting in a timestamp, and only letting the timestamp be used once) - may work for some cases, but not others (cases where a legitimate user will send several messages in a single time window.

How important is consistent availability and what is the risk if the authentication creates a false positive or a false negative?

How is this deployed?

It's a big difference whether it's operating inside the protections of a network, or something coming from the public. Also, protection of the user passwords on both the user's client machine and on the server is a big deal and needs to be protected in a way that is commensurate with the risks of the system.

How are users rekeyed?

This can be a problem for both assymmetric keys and user passwords - often the reset/rekey process is the biggest risk, as the user is now without the proof of authentication. Reset of passwords adds the risk that the password must be stored both places. If users have to work (and reset passwords) remotely - this can be a big problem.

Rekey of assymetric keys has some of the same problems - knowing the user is the user is a problem if the user has lost his credentials, but the private key in an assymetric pair is not required to be transmitted as long as the public key can be verified.

What are your ease of use requirements?

Most users, if properly provisioned, can sign emails with the click of a button in most major mail clients (Outlook and Notes for sure). It'll take an extension to the email client to do something custom built. If you have a few, very knowledgeable, users, this may be no big deal. But if this has to go do non-technical business people, this will be a real UI challenge, the size of which may dwarf any benefits.