1

Our application currently generates "invitation" emails containing an encrypted personId in the query string of an https link. When the recipient clicks the link, the application validates the personId, returns the home page, and sets a never-expires cookie that will identify and authenticate the user for all future visits.

Can we make this process more secure without sacrificing the ease of use? We think the weak point is the use of the query string. The secure token, because its passed in the query string, will be stored in the browser history, server logs, and possibly firewall logs if they do man-in-the-middle https inspection. We could put the same details in a form with hidden inputs, but I read that forms in emails cause the panic reaction in email clients.

The resources being secured aren't super precious. Are there obvious improvements that I've overlooked?

Improve this question

1 Answer 1

Reset to default
7

emails containing an encrypted personId in the query string of an https link

Firstly, encryption isn't really what you want in this scenario - you really want entropy. Your login token should be entirely independent of your personId, instead it should be a random string generated using a cryptographically secure method.

Of course you will need to store the random token in your database, and you may choose to hash+salt that value, but the value emailed to them should not be the hashed value.

Can we make this process more secure without sacrificing the ease of use? We think the weak point is the use of the query string.

I don't think the issue is so much that your token is in the query string, but rather that your tokens aren't single use.

Single use tokens would resolve browser history and server logs because once it's been accessed the links in the logs/history wouldn't work any more.

With regard to:

if they do man-in-the-middle https inspection

If they have installed a malicious CA on the machine then they can inspect any of the traffic, so regardless of where you put the value (in the Request URL header or in the request body) they could access it.

Overall I'd consider this to be a pretty low threat, it's not easy to install a malicious CA and if someone malicious has managed to do so then you probably can't trust anything whatsoever on that machine.

You could of course also make them manually type the code rather than using a link - which would mitigate some of these threats. At the least you might be able to have some separate and easier to type code (eg. a 4 digit value) and an appropriate failed attempt lockout in addition to the link containing the main token.

Improve this answer
2
  • These are all good remarks. Concerning the "malicious" CA, its not so difficult. It's even a product sold by fortinet, microsoft and others, and installed as a matter of course, on our corporate network for example.
    – bbsimonbb
    Commented May 12, 2015 at 7:44
  • @user1585345 Sure it's not difficult to MITM an SSL connection, but to do that the attacker would almost certainly need root access and if the attacker has that then there's almost nothing you can do to secure your communication. In the case of a corporate network, if the administrators had root access and were hostile to you then they could thwart just about any security measure you could put in place because they essentially own and control the machine.
    – thexacre
    Commented May 12, 2015 at 11:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.