Hacker News Reader

Comment by tmcneal | Hacker News Reader

If you're using SSL then form data in a POST request will be encrypted. HTTP headers are always encrypted using SSL. What wasn't clear to me from the documentation is whether the 'username' and 'password' are form data, or are actually custom HTTP headers. The latter choice would certainly be a facepalm.

View on HN

> The latter choice would certainly be a facepalm.

Why?

>If you're using SSL then form data in a POST request will be encrypted

So will everything else, including the URI being requested, and thus the query string in it. Which is why it makes no difference using GET or POST.

But you can be 99.994% sure they're writing your plan text user name and password into their logs if you're using get, and if somebody breaks in and gets them, then they have your password, even if those passwords are properly hashed in the user database.

No, I wouldn't be 99.994% sure of that at all. In fact, I would assume that if they are suggesting that people use GET, that they are in fact not logging the query params, as any security audit would catch that.

And again, if they are compromised, then they are compromised. It doesn't matter if they have logging disabled, someone who would have access to the logs also has access to either the httpd account or the root account. Either way, they can already read your plaintext usernames and passwords directly when they are being submitted. Of course, they don't need your username and password anyways, as they already have full access to the system.

Picking a comment at random to thank you for at least trying to explain to people why their assumption of what's being logged relates in no way to security.

At least one person appreciates someone taking the time to correct this rather serious misunderstanding.

So will everything else, including the URI being requested

I disagree from the data I'm seeing in the access logs from my SSL-hosted site running nginx. In the logs I can see lines such as:

GET /path/script?variable=blahblah&another_variable=123

EDIT since I appear to have lost the ability to reply to comments: I disagree with SomeOtherGuy2 that The fact that it may get logged is a red-herring.

Ignoring how secure a server with a rogue user accessing it is, it's possible that there will be more than one server involved in this scenario, and central logging servers are common. Will the traffic sent to the logging server be encrypted? And what if the logging server is compromised? You're essentially storing passwords in plain text.

It's all encrypted over the network. Obviously, your servers have to be able decrypt URL strings (and everything else), or they wouldn't be able to respond correctly. I think the assumption is just that servers may by default log decrypted URLs for GET requests, but not POST requests. But, as people have noted, that's not exactly reassuring, since you have no idea how their logging is set up.

You are very confused. SSL is used to encrypt transmission between the browser and web server. Of course the web server decrypts the data it receives, otherwise it wouldn't be able to use it. I am saying you can not sniff someone's HTTPS traffic and see the urls they are requesting, so sensitive information being in the url is not a problem. The fact that it may get logged is a red-herring, as if someone has compromised the server to gain access to the logs, they can access whatever they want, your username and password included.

Reply on news.ycombinator.com