https URL with token parameter : how secure is it?

On our site, we provide to users a simulation based on their private information (given through a form). We would like to allow them to get back on their simulation results later, but without forcing them to create a login/password account.

We have thought of sending them an email with a link, from which they could get back their results. But, naturally, we have to secure this URL, because private data is at stake.

So we're intending to pass a token (like a 40 characters combination of letters and digit, or a MD5 Hash) in the URL and to use SSL.

Finally, they would receive an email like that:

> Hi,
> Get back your results on > https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

What do you think about it? Is it secure enough? What would you advise me for the token generation? What about passing URL parameters in a https request?

SSL will protect the query parameters in transit; however, email itself is not secure, and the email could bounce along any number of servers before getting to its destination.

Also depending on your web server the full URL might get logged in its log files. Depending on how sensitive the data is you might not want your IT people having access to all the tokens.

Additionally the URL with the query string would be saved in your user's history, allowing other users of the same machine to access the URL.

Finally and what makes this very insecure is, the URL is sent in the Referer header of all requests for any resource, even third party resources. So if you're using Google Analytics for example, you will send Google the URL token in and all to them.

In my opinion this is a bad idea.

I'd use a cookie for that. The workflow should be like this:

1. User comes to your site for the first time.
2. Site sets a cookie
3. User enters data. Data is stored in the DB using some key that is stored in the cookie.
4. When user leaves, you send them an email with a https: link
5. When user comes back, site discovers the cookie and can present the user with the old data.

Now, the user wants to use a different browser on a different machine. In this case, offer a "transfer" button. When the user clicks on this button, she will get a "token". She can use this token on another computer to reset the cookie. This way, the user decide how secure she wants to transfer the token.

SSL secures the contents of the data in transit, but I'm not sure about the URL.

Regardless, one way to mitigate an attacker reusing that URL token is to make sure each token can only be used once. You could even set a cookie so that the legitimate user can continue to use the link, but after the first access it will only work for someone with the cookie.

If the user's email is compromised and an attacker gets the link first, well, you're hosed. But the user also has bigger problems.

E-mail is inherently insecure. If anyone can click on that link and get to the data, you're not really protecting it.

Well the token is secure when being passed through SSL. The problem you are going to have is that it is avilable to people (those who it is not intended for) by being able to view the URL.

If it's private information like SSN I don't think I would send a URL through email. I would rather have them create a username and password for the site. It's too easy to compromise an email with that kind of information at stake for you and for them. If someone's account is comprimised it will come into quesion whose fault it really is. The more secure the better you are from a strictly CYA standpoint.

You are aware that if any hacker get access to your database a lot of personnal information can be freely given ?

After that I would say that this is not bad as idea. I would not use MD5 or SHA1 as they are not very secure for hashing. They can be "decrypted" (I know it's not encryption) quite easily.

Otherwise I would maybe use a second information that would not be sent by email kind of a password. The reason is quite simple, if someone get access to the user's email (quite easy with hotmail if you don't kill your session) he will have access to any informations the user have sent.

Note that the HTTPS will secure and crypt data sent from your site to the end user. Nothing else, take it as a secure tunel. Nothing more nothign less.

I really wouldn't that consider that secure enough for a situation where there are serious privacy issues. The fact that you're sending the URL in a (presumably cleartext) email is by far the weakest link. After that is the risk of brute force attacks on the tokens, which (lacking the structure of a real authentication mechanism) are likely to be more vulnerable than a well-constructed username and password setup.

There are no issues at all with the parameters in a https request, incidentally.

As it is, it would be a bad idea. You will scarify security with easy usage. As said before SSL will only protect the transfer of information between the server and client browser and will only prevent the middle man attack. Emails are very risky and insecure.

The best would be a User name and password authentication to access the information.

I like the cookie idea more or less. You should encrypt the cookie information as well. You should also generate the token with salt and key phrase plus the $_SERVER['HTTP_USER_AGENT'] to limit the probability of an attack. Store as much nonsensitive information about the client in the cookie for verification usage.

The key phrase could be stored in the cookie for easy usage but keep in mind that also cookie can be stolen =(.

Better let the client type the key phrase that he provided, which is also stored in the database along with his data.

Or, the key can be used in case the person uses a different machine which differs in the $_SERVER['HTTP_USER_AGENT'] parameters or simply misses the cookie. So the cookie can be transfered or set.

Also make sure that sensitive data is encrypted in the database. You never know ;)

From what I understand of your idea, in theory someone could type in a random 40 character string or MD5 hash and get someone elses details. Whilst this may be highly unlikely it only needs to happen once.

A better soloution might be to send the user a token then ask them to enter some of the details, such as their name, post code, ssn or a combination of these.