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?
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.
2