How secure is a HTTP POST?

Question

Is a POST secure enough to send login credentials over?

Or is an SSL connection a must?

Answer 1

SSL is a must. POST is not more secure than GET as it’s also send unencrypted. SSL will cover the whole HTTP communication and encrypt the HTTP data send between the client and server.

Answer 2

SSL is a must :)

HTTP Post is transmitted in plain text. For an example, download and use Fiddler to watch HTTP traffic. You can easily see the entire post in there (or via a network traffic monitor like WireShark)

Answer 3

No...POST is not secure enough at all. SSL is a MUST.

POST only effectively hides the parameters in the query string. Those parameters can still be picked up by anybody looking at the traffic in between the browser and the end point.

Answer 4

It is not secure. A POST can be sniffed just as easily as a GET.

Answer 5

That depends on your circumstances, how much would the interception of the credentials cost somebody?

If it's just a login to a software Q+A site then SSL might not be necessary, if it's an online banking site or you store credit card data then it is.
This is a business not a techncial decision.

Answer 6

POST is plaintext.

A secure connection is a must.

That's why it's called a secure connection.

Answer 7

A POST request alone is not secure because all the data is "traveling" in plain text.

You need SSL, to make it secure.

Answer 8

About as secure as snail-mailing someone's credentials on on a postcard.

Answer 9

No, use SSL.

With POST the values are still submitted as plain text unless SSL is used.

Answer 10

POST data is sent in plain text if you are using an unencrypted HTTP connection. IF this is secure enough depends on your usage (hint: it's not).

If both the server, the client machine and ALL MACHINES BETWEEN THEM are part of a controlled, fully trusted network, this may be ok.

Outside of these very limited circumstances (and sometimes even within them) plain text authentication is asking for trouble.

Answer 11

The only difference between HTTP GET and HTTP POST is the manner in which the data is encoded. In both cases it is sent as plain-text.

In order to provide any sort of security for login credentials, HTTPS is a must.

You do not need an expensive certificate to provide HTTPS either. There are many providers that will issue very basic certificates for about $20USD. The more expensive ones include identity verification which is more of a concern for e-commerce sites.

Answer 12

Depends on where you are using it and how secure you really need.

There is no way for someone to get the POST data you send from your home unless you are using a proxy (TOR) or someone is tapping your wires.

However, if you are concerned that someone will login using a wireless unsecured network, than ssl is important.

If you are a bank, you can't even take that risk. If you are a techer with logins to see assignments, then you should be fine

Answer 13

HTTP POST is not encrypted, it can be intercepted by a network sniffer, by a proxy or leaked in the logs of the server with a customised logging level. Yes, POST is better than GET because POST data is not usualy logged by a proxy or server, but it is not secure. To secure a password or other confidential data you must use SSL or encrypt the data before you POST. Another option would be to use Digest Authentication with the browser (see RFC 2617). Remember that (home grown) encryption is not enough to prevent replay attacks, you must concatenate a nonce and other data (eg. realm) before encrypting (see RFC 2617 for how it is done in Digest Auth).

Answer 14

The most secure way is to not send credentials at all.

If you use Digest Authentication, then SSL is NOT a must.

(NB: I am not implying that Digest Authentication over HTTP is always more secure than using POST over HTTPS).

Answer 15

<shameless plug>I have a blog post that details what an HTTP request looks like and how a GET request compares to a POST request. For brevity's sake, GET:

GET /?page=123 HTTP/1.1 CRLF
Host: jasonmbaker.wordpress.com CRLF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 CRLF
Connection: close CRLF

and POST:

POST / HTTP/1.1 CRLF
Host: jasonmbaker.wordpress.com CRLF
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 CRLF
Connection: close CRLF
CRLF
page=123

(The CRLF is just a newline)

As you can see, the only differences from the standpoint of how a request is formed* is that a POST request uses the word POST and the form data is sent in the body of the request vs the URI. Thus, using HTTP POST is security by obscurity. If you want to protect data, you should use SSL.

* Note that there are other differences.

Answer 16

I agree with mgb, I really don't know why so many people are screaming about how SSL is a must - it's absolutely important under certain circumstances, but is by no means a must. Even stack overflow doesn't use SSL - they use OpenID, but some of the websites (I just checked, and LiveJournal does not use SSL to log in) are just plain POST requests.

If you are protecting important information, you would be very irresponsible to not use SSL, but for the average use case it's just extra hassle that you don't need.

Answer 17

Login credentials to who? How sensitive is it? (SSL is much better... Do you need it? Do you need more?)

Answer 18

Very interesting

Answer 19

I am wondering if there is a difference between POST and GET over SSL when sending sensitive info such as UID/PW. This will be encrypted in the body when sent using a POST, but I don't believe this part of the URI will be encrypted and will be sent as plain text.

i.e., Won't something like "https://myserver.mydomain.com/login?uid=me&pw=supersecretpw" be exposed in plain text on the wire, although the rest of the message will be SSL encrypted if sent as a GET?