3

I started working on a service that sends out mails with a link to a registration form. (e.g. a registration for a movie premier)

The link would look like this https://movie-premier.com/rsvp/USERCODE

The problem is that for some users part of the form is prefilled with their name and address etc.

So basically we send them a "password" in plain text to access personal data.
I doubt this is ok under GDPR so I'm trying to think of a better solution.

The thing is: usually users that did register will get a confirmation mail with all that data in it anyway. So I wonder if I could do the same in the invitation. Just send them a very long link with all the data in it.

But then is this really worth doing it? Shure now there is no link on the internet to access that personal data. But the thread I had before was someone stealing that link from the mail…

Is there any other downside to having that link online?

confused
  • 33
  • 2
  • 2
    Why would you have the data in the URL? Just generate a random string and tie them together with a database entry, then you won't need to worry about having potentially sensitive information in a URL. – user Dec 09 '19 at 19:21
  • @user sounds like you should make that an answer... – Conor Mancone Dec 09 '19 at 19:57
  • @ConorMancone I can do it Wednesday. If someone wants to write something up before then I'd be happy to upvote it. – user Dec 09 '19 at 20:21
  • USERCODE is a random string tied to a databse entry. I just see it as a password. That would mean it should be hashed and not sent in plaintext by mail… But yeah maybe sending the data is worse not better… – confused Dec 09 '19 at 21:46
  • Don't put any information in a URL that you wouldn't want public. It leaks through the referrer header, it persists in browser history and cache, browser addons can leak or log URLs, anti-malware and privacy software can do the same, the URL can be leaked through misconfigured servers, or can be leaked through the clipboard if the user copies the URL. URLs can also be followed by email server anti-spam systems, anti-malware systems, censorship software, or search engine crawlers. Secret data should be POST data. – Future Security Dec 10 '19 at 01:53
  • @confused The primary reason for hashing passwords is because people often re-use them, so a leaked password threatens not just the user on your service but also any other services where the user used that password. An Access token (which is what you are describing) doesn't carry that same risk, so hashing is not necessary, and is actually counter productive – Conor Mancone Dec 11 '19 at 00:20

1 Answers1

1

Typically what websites will do is generate a random URL (https://movie-premier.com/rsvp/yNXszjZUpYJvYFqCJ57tuLgSQvcGXWN1 for example), and tie that random code to a user ID with a database entry. When the user loads that page, you can autofill the data with the corresponding user's information. URLs tend to get saved by web clients and logs, so having a random placeholder should also reduce the risk of that information leaking that way.

Another benefit of this is that you can also tie in an expiration to it and prevent users from pulling up sensitive information afterwards, or remove that database entry when they finish registering. If you tried to add in all that information in the URL you'd be left with no way to go back and remove it from the email server/client.

Just make sure it's a random URL and not the hash of the user's password or something silly, or an attacker may be able to figure out what the original value was. Also it should go without saying that it should be at least cryptographically random data so that an attacker can't guess what the URLs are, or they may be able to harvest up user data by guessing the registration codes.

user
  • 606
  • 7
  • 11
  • I'd also suggest having it be a one-time-use token in the URL, as well, so that the data isn't available afterwards. – Ghedipunk Dec 11 '19 at 22:03
  • @Ghedipunk Yeah you'd want to delete the database entry to prevent it from being used after the registration is complete. I don't think you'd want to disable it right after it's opened the first time though, since if the user refreshes the page and sees 404 right after they're going to be pissed. – user Dec 12 '19 at 13:21