0

I have 1 legacy site and the other new. The new site will be embedded into legacy site as an iframe. In the new site I know the list of users registered in legacy site. I want to know which user is opening my page, registered and logged in the legacy site. What is the best way to pass username to new site from old site in HTTP URL with knowing that it is safe?

I was thinking about passing as GET parameter encrypted data, which will be decrypted in new site. This data would contain username and timestamp and salt. In new site I will check if username is in my list of registered users, and I will grant acces for a particular time. Is that a secure way?

There is only HTTP without SSL.

Dariusz Mydlarz
  • 2,940
  • 6
  • 31
  • 59

3 Answers3

1

You should use POST whenever you transmit secure data over HTTP , not because it provides any additional security over GET , but will avoid logging the sensitive info in Browser history and server logs.

Also instead of sending the encrypted credentials over HTTP you could generate some kind of Token out of it and pass it across which can be verified at the receiver end.

Roshith
  • 2,116
  • 13
  • 21
  • I want to send username, timestamp and salt; Without password; Do U think I still need special token for that? – Dariusz Mydlarz Dec 12 '14 at 10:47
  • Not necessarily as you are encrypting it. Security tokens standard way for inter app/site authentication, or simply SSO. So suggested it. – Roshith Dec 12 '14 at 10:52
  • Correct, in this context POST is more secure than GET for the reasons you describe. [It is also advisable to do this for AJAX requests](http://stackoverflow.com/a/21499008/413180) to prevent ` – SilverlightFox Dec 13 '14 at 11:26
  • Thanks for all you advices, especially @SilverlightFox. I cant use Kerberos either, I have to rethink that all. Because I am not able to switch to HTTPS also. So there always will be a backdoor to get into the system... – Dariusz Mydlarz Dec 13 '14 at 13:00
0

It looks pretty safe to me. You are delegating authentication to your new site and just signaling the old one. That should be safe provided your encryption method is.

Using salt and timestamp will take care of replay attacks, so I don't see any vulnerabilities in the method you propose, if you choose a safe encryption method, that is.

eirasf
  • 79
  • 10
  • Unless there is a token that is invalidated after first use, a replay attack is still viable (an attacker can capture the initial request and simply repeat it). However, as there is no HTTPS this is a moot point as once a session is established the token can be captured. – SilverlightFox Dec 13 '14 at 11:28
  • I assume that's the purpose of the timestamp. – eirasf Dec 13 '14 at 12:36
  • An attacker would just grab the encrypted query string parameter and replay it immediately - the time stamp will still be valid. – SilverlightFox Dec 13 '14 at 12:55
  • Yes, to prevent that a token would be much safer than relying on the precision of the timestamp. – eirasf Dec 13 '14 at 14:00
0

Sticking user info in the URL of a GET request may be safe if encrypted, it will ruin your caching as now the same page has a different URL for different users.

The thing that doesn't sound safe to me is that if both sites are served over HTTP, then the user could not have logged in safely to the old site. All traffic is in the clear and susceptible to eavesdropping.

I would recommend moving your site to HTTPS for both sites. If the sites are hosted on the same domain, you can set a cookie identifying the user that will work for both sites.

Even better would be to move to some social authentication provider like Facebook or Microsoft Live Id and avoid storing user passwords all together.

MvdD
  • 22,082
  • 8
  • 65
  • 93
  • Unfortunately I am not able to move both sites to HTTPS. There is also no chances to use social authentication either – Dariusz Mydlarz Dec 12 '14 at 20:33
  • In that case you need to make your users aware of the security implications of logging on to your site. – MvdD Dec 12 '14 at 21:00
  • It will be entirely internal system, but I want it to be the most secure it can. I am not able to change old site to move to HTTPS – Dariusz Mydlarz Dec 12 '14 at 21:08
  • If it's an internal system, you should look into using Kerberos for authentication. That will also remove the need to store usernames and passwords. – MvdD Dec 12 '14 at 22:11
  • A POST request will not be cached for different users either as the request payload will be different so caching is not possible this way. To enable caching to work, you would need to redirect after the initial request is accepted (with either GET or POST). However, as different users may have different content, it is advisable to disable caching anyway for dynamic content from a security perspective. Your other points are valid. – SilverlightFox Dec 13 '14 at 11:31