How secure is sending sensitive data over https?

Question

I would like to ask you about your opinion guys. Is SSL secure enough for using sensitive data (like password) in query string? Is there any extra options to implement?

thanks for any word.X.

Answer 1

you should never send anything critically sensitive using query strings!

Answer 2

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)

Answer 3

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

SSL is pretty much the most security you can get.

Answer 4

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.

Answer 5

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.

If using query strings is your only option (I doubt it), here is an interesting article about securing query strings.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

thanks guys, very comprehensive answers...it clarifies to me that SSL is enough itself.

Just for clarification...
- I suppose using http in code by HttpWebRequest...Response, so no issue with browser - I suppose consuming 3th part services

I am just curious about tricks and traps that can happen in some stage, e.g. the information can be dig from somewhere, like server cache, history log....

2 Checker ... can you please describe that self-signed certificates theory. What is it about?

Answer 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.

Answer 11

Gurus,

Kindly help me here. I am a newbie. I have created a Self signed certificate. My browser throws the error as above. Though this is not the problem, i was trying to sniff into packets in my network and i have realized that credentials are being displayed in clear text format for anyone logging on the secure server from the client.

Kindly help me out. What should i do... i thought the idea of having https is to ensure that packets are encrypted during transfer between server and client.

Kindly help me out. any one with a suggestion i would appreciate a lot. Thanks