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?

Improve this question
7
  • 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, 2015 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, 2015 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, 2015 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, 2015 at 13:14
  • 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, 2015 at 13:57

6 Answers 6

Reset to default
51

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

Improve this answer
15
  • 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.
    – user42178
    Feb 24, 2015 at 14:38
  • 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.
    – user42178
    Feb 24, 2015 at 15:01
  • 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.
    – user42178
    Feb 24, 2015 at 15:14
  • 16
    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, 2015 at 16:17
  • 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, 2015 at 0:17
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!

Improve this answer
9
  • 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, 2015 at 1: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, 2015 at 1: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, 2015 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, 2015 at 16:28
  • 1
    Server does not necessarily store clear text password. It could store the hash of (username:realm:password) as stated in this wiki
    – user2829759
    Jun 19, 2016 at 8: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.

Improve this answer
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.

Improve this answer
-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?

Improve this answer
1
  • 1
    If Fiddler can see it, and the SSL proxy isn't enabled, there's zero encryption period.
    – Iszi
    Feb 24, 2015 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.

Improve this answer
8
  • 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, 2015 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, 2015 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, 2015 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, 2015 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, 2015 at 10:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .