Menu
Is SSL secure enough for using sensitive data (like password) in query string? Is there any extra options to implement?
293
HTTPS ensures that all communications between the user's web browser and a website are completely encrypted. Even if cybercriminals intercept the traffic, what they receive looks like garbled data. This data can be converted to a readable form only with the corresponding decryption tool -- that is, the private key.
Hypertext transfer protocol secure (HTTPS) is the secure version of HTTP, which is the primary protocol used to send data between a web browser and a website. HTTPS is encrypted in order to increase security of data transfer.
HTTPS is HTTP with encryption and verification. The only difference between the two protocols is that HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses, and to digitally sign those requests and responses. As a result, HTTPS is far more secure than HTTP.
Don't give private information to anyone you don't know or who doesn't have a legitimate need for it. Don't provide personal, sensitive, or confidential information online unless you are using a trusted, secure web page. At a minimum, look for “https” in the URL to indicate that there is a secure connection.
SSL provides secure, transport-level security. Nobody between client and server should be able to read the information.
But you should change your mind about writing sensitive data in the querystring. It will show up in the browser's history and is visible in the address bar of the browser and in logs on the server. See this article: How Secure Are Query Strings Over HTTPS?
If using query strings is your only option (I doubt it), here is an interesting article about securing query strings.
175
SSL is secure, but remember that any encryption can be broken if given enough time and resources. Given that you don't know which packets contain a password and which don't, you'd have to decrypt all encrypted traffic to find the right one. This is intractable in the general case.
However, a login form will need a input[type=text] to enter it. It would take work to "unpack" this and turn the request in to a HTTP GET request using query strings rather than a POST with the data in form parameters. I can't imagine why anyone would do this. Once the password has been supplied by the user (and the user authenticated), use the fact of authentication rather than keeping the password around. If you need to keep the password, for impersonation, say, keep it server side and preferably in a secure string. If you are trying do do single-sign on (enter my id/password once for many sites), then use some sort of central authentication service (CAS) - OpenID, WindowsLive - or implement your own.
The fewer times a password crosses the wire, the better.
And, there is always the browser location bar to consider which would argue that you need to encrypt and encode any sensitive data you put in query strings as mentioned previously.
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
