18

I have to log in on an HTTP website.

There is a login form which contains inputs for username and password and as hidden inputs the sessionId. I am creating an application in which I have to access resources which just can be accessed if you are logged in on this website, so I provide a username and password input in my application to log in.

I watched the HTTP requests now, and the HTTP POST request in which the login data is sent has the parameters password and username, so I could see my username and password in Fiddler non-encrypted, but I don't want to send my data unprotected.

If the parameters of an HTTP POST request can be seen by tools like Fiddler in the clear, does this mean that my data is sent without any encryption to the server? Or is there any kind of encryption that is done which just isn't visible to me?

Jens Erat
  • 23,446
  • 12
  • 72
  • 96
Richard_Papen
  • 183
  • 1
  • 1
  • 5
  • Sometimes doing an incorrect login will cause a redirect to a secure login page, which is what the site should have redirected to in the first place. Just type a fake user name and password in most cases to test this, but be leery about using the same password from other accounts. These sites tend to also send a plain-text password by email during a password reset. Check if there is an `https` version of the login page, and have your app use that. – ps2goat Feb 24 '15 at 17:33
  • 1
    Even HTTPS isn't all that secure. How can you expect any sort of security from HTTP, when prodigious folks are able to break even HTTPS encryption? – Chris Pratt Feb 24 '15 at 20:46
  • 1
    @ChrisPratt: What do you meant by HTTPS isn't secure? HTTPS is only insecure if you misconfigure either the server or the client, or if you tell the browser to trust entities that shouldn't have been trusted. – Lie Ryan Feb 25 '15 at 11:11
  • Forget about HTTPS for now, your first problem is that you are sending your password unencrypted by itself. – Ceiling Gecko Feb 25 '15 at 13:14
  • @LieRyan: I simply meant there's been a number of high profile HTTPS exploits of late. Though, most of that had been due to a relative small group of people working on it, mostly in their free-time. Now, companies like Google and Microsoft are getting involved in earnest, so the situation should improve in that regard. Still, it's only ever as secure as the network itself is. I can go to Starbucks, set up my own Wifi, and probably catch a few clueless users' passwords easy enough. – Chris Pratt Feb 25 '15 at 13:55
  • 1
    @CeilingGecko: Not sure what that's supposed to mean. There's no way to encrypt the password in transit without SSL. If you're talking about encrypting it client-side before submitting the form, that really does nothing as it's all to easy to see what you're doing and reverse it. At most you just add an extra step to the process, which isn't going to deter a hacker. – Chris Pratt Feb 25 '15 at 13:57
  • @ChrisPratt: most of the recent exploits are due to using older protocols, which really should've been turned off long ago, it's just noone has been bothered enough to do it. The compression size issues aren't specific to HTTPS and the basic idea wasn't even new, and in practice it requires very specific conditions to exploit. The OpenSSL bug is an implementation issue, not an issue with the protocol itself. These are configuration and implementation issues, not so much protocol issues. – Lie Ryan Feb 25 '15 at 17:02

6 Answers6

50

Ordinary HTTP of all sorts is unencrypted. If you want to protect your data, it has to be sent over HTTPS.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • So this means, if I use ordinary HTTP and the data would be encrypted by the client then I just see the encrypted data in the HTTP request? – Richard_Papen Feb 24 '15 at 11:24
  • 12
    @Richard_Papen you can't do reliable encryption using HTTP, as any code you would use to do that will be served by the server over the unencrypted connection, easy for an attacker to compromise. –  Feb 24 '15 at 14:38
  • @AndréDaniel: not exactly true, you can still use custom encryption even if you're using HTTP. – Mints97 Feb 24 '15 at 14:58
  • 5
    @Mints97 but any code you'd use for custom encryption would be transmitted over that same HTTP connection, trivial for an attacker to compromise and thus disable your encryption. –  Feb 24 '15 at 15:01
  • @AndréDaniel: OP says he's developing an app, which means it isn't a browser-using scenario, and the possibility of client-side encryption code being tampered with can be more or less neglectable. – Mints97 Feb 24 '15 at 15:12
  • 3
    Assuming it's indeed an app (and not a webapp like I think it is) it *may* be secure assuming you do your custom over-HTTP crypto correctly. –  Feb 24 '15 at 15:14
  • This is the correct answer. But sadly, it doesn't have enough content to be an answer. But there isn't much more to say about it. Anyway, I aprove this and upvote it. – Ismael Miguel Feb 24 '15 at 15:22
  • 15
    It's no use arguing over not using TLS. Any custom crypto scheme can only lead to two things: a) a massive fail b) a (partial) reimplementation of TLS. TLS is ubiquitous and, if it's an app, you don't even need to have a certificate signed by a CA, just hard-code your public key in the application. – Stefano Sanfilippo Feb 24 '15 at 16:17
  • @AndréDaniel the 2 words custom and crypto should never be used in the same sentence unless a) you don't care about security at all or b) you are an extremely experienced crypto analyst – Damian Nikodem Feb 24 '15 at 17:43
  • By "custom" I meant using the OpenSSL libraries to actually do the crypto, the custom part would only be the code that handles the HTTP layer and passes the data to OpenSSL for actual crypto stuff. –  Feb 24 '15 at 17:50
  • @AndréDaniel Ultimately any encryption scheme needs to be implemented on both sides of the conversation. Here, the question is about writing a third-party application that needs to impersonate the user to another service. With that service being beyond the developer's control, and obviously performing authentication in the clear, any form of encryption is not an option. – Iszi Feb 24 '15 at 23:54
  • 3
    Well, @AndréDaniel, you fall under case b), that's a partial reimplementation of TLS. Just use it, it will save you a lot of headaches. – Stefano Sanfilippo Feb 25 '15 at 00:17
  • So what if the server passed a public key over HTTP to the client then the client used the public key to encrypt the credentials before sending it back? [Completely Hypothetical. Please refrain from flame war.] – DotNetRussell Feb 25 '15 at 14:23
  • 1
    @AnthonyRussell: Such an approach would provide present and forward secrecy, but would be susceptible to a man-in-the-middle attack. An adversary could intercept the server's public key, pass its own public key to the user, intercept the user's response, decrypt the data with the interceptor's private key, and re-encrypt with the legitimate server's public key. – supercat Feb 25 '15 at 19:28
  • Of course it is possible, it's not just that easy, but using digital signatures (like ed25519) can be used to verify the javascript code that actually encrypts the data being sent. It's just that the user must have received the public key using a safe transmission channel first. – Hannes Karppila Jul 30 '16 at 12:13
22

There is a mechanism to allow secure authentication over HTTP without SSL or TLS, but it's rarely ever used, and it's still not as good as HTTPS. Basically, it's a half-assed security measure of historical interest that never caught on, and you really ought to just use HTTPS anyway. But since you asked……

The HTTP protocol supports two authentication mechanisms: Basic and Digest Access Authentication, both described in RFC 2617. These are mechanisms that cause your browser itself to show an authentication dialog box, not embedded in the contents of the page. Basic authentication, which is sometimes used, is not much better than cleartext transmission.

The Digest mechanism, though, is a challenge-response protocol. The server issues a challenge containing a nonce (some random string). The client must reissue the request with a response that is a hash function of the nonce and the password (but not the password itself).

There are some significant caveats:

  • The server usually stores the plaintext password (or a plaintext-equivalent version of it) in order to be able to verify the challenge. This is undesirable, since best practices dictate that only salted password hashes should be stored. (@user2829759 points out that the server could also store the MD5 hash of (username:realm:password).
  • The Digest mechanism uses MD5, which is considered to be an insecure hash algorithm these days. Unlike SSL/TLS, there is no algorithm negotiation between the client and server.
  • There is no verification of the server's identity. Spoofing is possible, as are man-in-the-middle attacks. The only thing that Digest Authentication is good at protecting is the password itself — which is not as useful as one might think.

In Apache, Digest Authentication support is provided by mod_auth_digest.

One lesson that can be drawn from this piece of trivia is that a JavaScript-based encryption hack is likely to suffer from the same weaknesses. If you need security, just use HTTPS!

Community
  • 1
200_success
  • 2,144
  • 2
  • 15
  • 20
  • Would it be possible to have a secure (https://) web server someplace host a Javascript app that could then implement a secure protocol, if the embedded system included a header to authorize cross-site data fetching? – supercat Feb 25 '15 at 01:23
  • @supercat As I stated in my answer, anything short of reinventing all of HTTPS would be pointless. You could, at best, protect the password, but you still wouldn't be _secure_. – 200_success Feb 25 '15 at 01:30
  • If one has a trustworthy outside https:// server which, after a person supplies login credentials, will transfer a Javascript program which contains AES keys embedded in an Internet appliance, and if those with credentials are presumed authorized to do anything and everything they like with the appliance, how would an interloper without such credentials do anything with the appliance or snoop upon the actions which were being performed upon it, if all such actions were encrypted using AES (which--unlike SSL--can be implemented in a system with 2K or less of RAM). – supercat Feb 25 '15 at 16:22
  • To put it another way, suppose an appliance required someone to type all their intended actions into a handheld encryption device and then type the contents of that device's display into their browser. Such a system would be a real pain to use, but would be secure since no unencrypted data would ever cross the internet. Is there any reason an *SSL-served* Javascript applet could not play the role of the handheld device? – supercat Feb 25 '15 at 16:28
  • @supercat I suppose that could work. – 200_success Feb 25 '15 at 16:29
  • I remember authentication dialog boxes. I agree they never became too popular but they weren't that uncommon in the early 2000s. – Celeritas Feb 26 '15 at 09:47
  • Why is "protecting the password itself [...] not as useful as one might think"? Fetching a password (and username) enables the attacker to use this combination at other places. Yes, you shouldn't use passwords at multiple places. Yes, your users *will* use the password at multiple places. With Auth Digest the actual password used by the user is not stored or sent so an attack "only" ever compromises this exact server/account. Of course, using https if available is better. – JonnyJD Feb 26 '15 at 12:20
  • Using HTTP Digest Auth is better than "rolling your own" (if that involves saving clear text passwords, still see that in wild Oo) and better than Basic Auth if the connection is not HTTPS (which you don't always have control over). – JonnyJD Feb 26 '15 at 12:27
  • 1
    Server does not necessarily store clear text password. It could store the hash of (username:realm:password) as stated in [this wiki](https://www.wikiwand.com/en/Digest_access_authentication#/HTTP_digest_authentication_considerations) – user2829759 Jun 19 '16 at 08:12
3

To answer the question you posed: Yes, credentials are most likely being sent in the clear.

The only time Fiddler would be able to see the cleartext for the credentials, while the credentials are being sent encrypted, is if you've enabled the SSL proxy in Fiddler and configured the client devices to either trust the Fiddler Root CA or ignore the certificate errors. You'd probably know if you've done this.

For the record: Trusting the Fiddler Root CA should only be done for testing purposes, and writing an application that ignores certificate errors is in itself a security vulnerability.

Since you are writing an app that will authenticate to a third-party service, a service which presumably you have no control over, there's effectively nothing you can do to enhance the security of this login process.

Iszi
  • 26,997
  • 18
  • 98
  • 163
2

It would be possible for your application to authenticate securely over HTTP if the website (and your application) implemented the SRP protocol (Secure Remote Password).

Note that it would only be secure for applications implementing the SRP protocol, not for users accessing the website with a browser, because if the JavaScript code required to make SRP work is sent over HTTP, it can be tampered with.

Now, since it's very unlikely that the website you're working with implements the SRP protocol (because if they cared about security, they would at least use HTTPS), you can't do anything on your end to secure the login process.

Also, it would be easier to just switch to HTTPS than to implement the SRP protocol.

Sébastien
  • 313
  • 2
  • 10
-2

Mmm the problem is in the title of the question "HTTP - safe login"

"HTTP" and "safe login" are mutually exclusive.

...unless you add an "S" to the former :-)

It is likely the site has no encryption or weak encryption, so you should be very careful about calling the site from your web app if you want to keep your passwords safe!

Have you tried looking for an encrypted version of the same website?

Kai
  • 1
  • 1
  • 1
    If Fiddler can see it, and the SSL proxy isn't enabled, there's zero encryption period. – Iszi Feb 24 '15 at 18:29
-2

There is a jQuery extension called jCryption

http://www.jcryption.org/

you can encrypt username/passwords with your ssl public key and decrypt it on the server with a private key., so you will be using HTTP but the login etc would be secured if they are encrypted on the client computer using your public key.

Aurangzeb
  • 119
  • 3
    This appears to have the same problem as with sending a hash. Someone intercepting the stream can simply use the encrypted text to log in. – schroeder Feb 24 '15 at 21:37
  • in that case, the programmer is to be blamed not the algorithm. for example, if someone is sending abcde/password in encrypted form, then yes it is quite easy but suppose someone I send username/password/time in encrypted form or something else, how can the interceptor use it when the time doesn't match? there are ways... and thank you for voting down! – Aurangzeb Feb 24 '15 at 21:51
  • after all the precautions taken, the only attack possible is man-in-the-middle attack (that's where the CA comes in), and for that kind of attack the man must be in the middle., but anyway, doing it on http is like re-inventing the wheel... it's possible, but not recommended – Aurangzeb Feb 24 '15 at 22:21
  • First, I did not vote you down. Second, neither you nor the jcryption site mention using a nonce (time, in your example). – schroeder Feb 24 '15 at 23:35
  • What would stop a man-in-the-middle attack that serves the client a bogus version of jCryption that sends off the password to a 3rd party? – tangrs Feb 25 '15 at 10:50
  • @tangrs you need to trust someone, even a bogus chrome or firefox or IE can send passwords to a 3rd party! there's no stopping that! the only safe way then is don't use a computer! – Aurangzeb Feb 25 '15 at 16:12
  • @Aurangzeb Yes, but that someone shouldn't be everyone between you and the server. If we could trust them, we wouldn't need SSL/TLS now would we? The attack I'm talking about is the one the Tunisian government used to compromise Facebook logins by injecting Javascript into the insecure login page that sends off login details to a 3rd party before it was posted to a secure login page. – tangrs Feb 25 '15 at 23:56
  • You seem to be underestimating how easy it is to intercept HTTP traffic. What if the user is on a public wifi network? This solution isn't even close to SSL for security. – Aaronaught Feb 26 '15 at 05:31