Https URL with token: how safe is it?

Question

On our website, we provide users with a simulation based on their personal information (provided through the form). We would like to allow them to return to the simulation results later, but without forcing them to create an account for login / password.

We thought about sending them an email with a link from which they could return their results. But, of course, we must provide this URL, because personal data is at stake.

So, we intend to transfer a token (for example, a combination of letters and numbers of 40 characters or an MD5 hash file) in the URL and use SSL.

Finally, they would receive such an email:

Hello,
Return the results https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

What do you think about it? Is it safe enough? What would you advise me for creating a marker? How about passing URL parameters in an https request?

Answer 1

SSL will protect request parameters in transit; however, the email address itself is not secure, and the email can bounce on any number of servers before reaching its destination.

In addition, depending on your web server, the full URL may be logged in log files. Depending on how sensitive the data is, you may not want your IT staff to have access to all tokens.

In addition, the URL with the query string will be stored in the user's history, which will allow other users of the same computer to access the URL.

Finally, and making this very insecure, the URL is sent in the Referer header of all requests for any resource, even third-party resources. Therefore, if you use Google Analytics, for example, you send Google a token of URLs for them.

In my opinion, this is a bad idea.

Answer 2

I would use a cookie for this. The workflow should look like this:

• The user comes to your site for the first time.
• The site sets a cookie
• The user enters data. Data is stored in the database using some key, which is stored in a cookie.
• When the user leaves, you send them an email with https: link
• When the user returns, the site detects a cookie and can present old data to the user.

Now the user wants to use another browser on another machine. In this case, suggest the "transfer" button. When the user clicks on this button, it will receive a “token”. She can use this token on another computer to reset the cookie. Thus, the user decides how securely she wants to transfer the token.

Answer 3

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

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

If the user's email address is hacked and the attacker receives the link first, well, you get to. But the user also has big problems.

Answer 4

Email is inherently insecure. If someone can click on this link and go to the data, you are not really protecting it.

Answer 5

Well, the token is protected when transmitted over SSL. The problem that you will encounter is that it is accessible to people (those for whom it is not intended), being able to view the URL.

If this is private information such as SSN, I don’t think I will send the URL by email. I would prefer that they create a username and password for the site. It is too easy to compromise e-mail with such information that you have set for yourself and for them. If an account is included, it will go into the question of whose fault it really is. The safer, the better you are on the strictly CYA side.

Answer 6

I really don't think it's safe enough for a situation where there are serious privacy issues. The fact that you are sending the URL in a (presumably plain text) email is the weakest link. After this, there is a risk of brute force attacks on tokens, which (without having a real authentication mechanism structure) are more likely to be more vulnerable than a well-constructed username and password setting.

There is no problem with the parameters in the https request, by the way.

Answer 7

Anyway, that would be a bad idea. You scan security easily. As mentioned earlier, SSL will protect the transfer of information between the server and the client’s browser and prevent the attack of the average person. Letters are very risky and unsafe.

It would be best to use a username and password to access information.

I like the idea of ​​cookie more or less. You must also encrypt cookie information. You should also generate a token with a salt and key phrase plus $ _SERVER ['HTTP_USER_AGENT'] to limit the likelihood of an attack. Store as much customer information as possible in a cookie to verify usage.

The passphrase can be stored in a cookie for ease of use, but keep in mind that a cookie can be stolen = (.

It is better to 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 if the person is using another machine that differs in the parameters of $ _SERVER ['HTTP_USER_AGENT'] or simply skips the cookie. In this way, a cookie can be transmitted or set.

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

Answer 8

You know that if any hacker gets access to your database, you can freely provide a lot of personal information?

After that, I would say that it is not bad as an idea. I would not use MD5 or SHA1 as they are not very safe for hashing. They can be “decrypted” (I know that this is not encryption) quite easily.

Otherwise, I might have used second information that would not have been emailed as a password. The reason is quite simple: if someone gets access to the user's email (quite simply with hotmail, if you don't kill your session), he will have access to any information that the user sent.

Please note that HTTPS will protect and encrypt data sent from your site to the end user. Nothing else is perceived as safe. Nothing more.

Answer 9

From what I understand about your idea, theoretically someone can enter an arbitrary string of 40 characters or an MD5 hash and get information about some details. Although this may be unlikely, it should only happen once.

A better solution might be to send a token to the user and then ask them to enter some details, such as their name, zip code, ssn, or a combination of both.