https URL with token parameter : how secure is it?

Question

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?

Selry

securityweek.com/hackers-can-intercept-https-urls-proxy-attacks – Prokopyevsk

Answer 1

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.

Raines

I hadn't thought about the HTTP-referer problem, but the url link would redirect to the result page, it wouldn't be a proper page (no google analytics or other third party script). – Selry

Don't most browsers remove the referrer when going from HTTPS to HTTP? – Macdonald

This is similar to user activation(or password reset) link right? How then should that case be handled? Lot of websites send reset urls to email, POST is not an option since it should be clickable. Thank you. – Nonesuch

so what is the solution? – Realist

what if the token in the url is not the same as the token used for api requests and it only lasts one hour, what would the harm be then? – Disservice

@Disservice If that token is exposed the attacker will have one hour to use it to impersonate your user. Whats the harm all depends on your application. Sending it via email in my opinion is fine so long as the token has a short timeframe and is a one time use – Raines

Answer 2

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.

Ultramicrometer

If there are no cookies on the new computer, how does the the server know who they are? Giving the user a token when they have no idea who there and what results belong to them doesn't make sense. Am I missing something? – Possum

and I imagine that if the user clears their cookies, their website data will be inaccessible or deleted. – Toreutic

Answer 3

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.

Appenzell

The SSL connection is secured before the URL is transmitted. – Felton

Answer 4

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

Propagate

Exact but many many sites don't bother about that and send login/passwords by mail. But it's not a reason to imitate them... – Selry

I agree no reason to imitate them, but they usually tell you to change the password after you login the first time. – Propagate

Answer 5

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.

Horwath

You're right : the URL would remain in the browser history for instance – Selry

Answer 6

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.

Valerievalerio

How exactly is a salted SHA1 hash decrypted in any sense of the word? – Appenzell

"You are aware that if any hacker get access to your database a lot of personnal information can be freely given ?" Yes, but isn't it a problem for all websites ?? – Selry

@Selry yep but if you gain access to paypal's db you won't find clearly saved credit card informations everything is encrypted. @Appenzell : theregister.co.uk/2005/02/17/sha1_hashing_broken – Valerievalerio

Answer 7

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.

Professionalism

You're right about the risk of brute force attacks. I don't see how we could prevent bots from this type of attack. Ban "insisting" IPs wouldn't be a sufficient protection. Would you have ideas on the subject? – Selry

Actually, with the kind of key space we're talking about, putting a if(this_ip_number_has_requested_an_invalid_token_today()) sleep(5); in your load_simulation script would be perfectly sufficient protection. (Rate limiting is one of those features of good authentication mechanisms.) – Professionalism

Thanks for your answer. But I thought that a same bot could easily take different IPs which made IP rate limit not sufficient. Am I wrong? – Selry

All that gets them is one undelayed attempt per IP. IP address space is not so easily available that that's helpful. – Professionalism

Answer 8

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 ;)

Magee

Answer 9

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.

Eternity

SSN? Are you serious? Anyway, I suggest you do the math on how many 40 character random strings there are. It's more than just "highly unlikely" – Appenzell

You're right, we should probably add another parameter in the url, like the email (even if a..z + A..Z + 0..9 = 62 characters, and 62^40 is a quite big number). – Selry

Guys, 62^40 is considerably more than the number of atoms in the universe. It is literally unguessable. – Appenzell

I appreciate 62^40 is huge; there is still a chance however tiny, someone could brute force the URL until they hit upon someones personal details. Rather than send it in the e-mail, ask them a simple question e.g. DOB, then even if someone guesses the string they would have to guess the DOB too. – Eternity

I'm sorry, but your math just doesn't add up. 62^40 is 496212362459367066914366580195701544604991251555593230875525121862270976 possibilities. Adding a check for DOB adds perhaps 30,000 to that. You're nuts if you think that makes a difference in any meaningful way. – Appenzell

I'm surprised how many people can't grasp the scale of these numbers. If you were guessing a MILLION tokens a second, it's far more likely that the sun would burn out before you get a hit – Appenzell

You don't have to go through every single possibility to get a hit what happens if someones URL just happens to be in the first million posibilities? – Eternity

Richard, it sounds like you're pointing out what is usually called the Birthday Paradox... it's not just the number of possible combinations that matters, but how many of them are used. Well, in this case, you need to use about 2^119 of the 62^40 combinations before the chance becomes significant. – Kassie

@RichardSlater, so what you are saying is a birthday would be harder to guess or bruteforce than 62^40 characters. – Dermatoid