How secure is sending sensitive data over https?

问题:

Is SSL secure enough for using sensitive data (like password) in query string? Is there any extra options to implement?

回答1:

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.

回答2:

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.

回答3:

Sensitive data in the query string is a bad idea, casual passers by can see the query string and there'd be a temptation to bookmark which is really not secure.

SSL is pretty secure, if you do internet banking and you trust it then SSL will be good enough for you too.

回答4:

agree with the SSL is secure *ish and the querystring issue

remember that there are limitations on SSL -

ensure that the cert is root certified.

some windows 2000 machines need to have an sp applied for the 128 bit ssl to work, if its not there then it goes to 40bit or doenst load (if i remember right)

Some software firewalls like ISA - where you publish the secure site and cert inside it - act like a man in the middle.

Secure to ISA then Secure to LAN. but the big facter here is the "then" as ISA will Log then logging is an issue as the password on the query string and post can be seen - which means anyone (admin) can see...

So look for secure hashing algorithims in your language to simply hash the password.

回答5:

There is no "secure enough", security is not a static thing with a bool property that is either false or true.

SSL is good, but it depends on how secure is the private key on the server side, how much bits the key has, the algorithm used, how trustworthy the used certificates are, etc ....

But if you use SSL at least all your data transmitted is encrypted (except the target IP because it is used to route your package).

Another point you should consider is - if you enter your password query string by hand in your browser it might end up in your local browser cache (in an completely unencrypted local file). So better use POST and not GET transfer mechanics.

If you are really interested in security i recommend more research about that topic, because most often not the algorithm is the weakest point in security.

回答6:

Yes it is secure enough. While I agree its not usually a good idea anyways to have stuff such as that in a query string, its ok if its not a query string that will show in the address bar. If it shows in the address bar you for obvious reasons lose a level of security (people walking by, etc)

回答7:

ssl inspector can open ssl traffics http://www.ssl-inspector.com/files/file/SSL%20Inspector%20Appliance%20Product%20Brief%20(2-11).pdf

回答8:

you should never send anything critically sensitive using query strings!

回答9:

Shouldn't one send hashed passwords ? - nevermind if I'm wrong.

SSL is pretty much the most security you can get.

回答10:

Self-signed certificates are SSL certificates that are created and signed by yourself. This means that you do not require a third party certificate authority (CA) to sign your certificate, but it means that browsers will, by default, throw a warning about it, since a self-signed certificate cannot reliably (your browser has a list of trusted CAs) verify that the signer of the certificate is exactly what the certificate says.

Consider the situation where you create a SSL certificate "on behalf of" a certain Redmond-based software company. Now, if your HTTP server presents that certificate, which you have self-signed, to a client, the user agent will warn that this certificate may not actually be whose it says it is. A certificate authority will verify - by paperwork, the real, actual dead-tree kind - the identity of the party requesting signing, hence it's trustable.

Hope this helps.