Form submission security in HTTP header

Question

After some tests on the site of Yahoo and Facebook I realized that after filling in my username and password and clicking on Login, with the developer tools opened in the option Network (Chrome or Firefox), I realized that if I stop sending the data over the page, the method POST already appears before the refresh page.

In other words, before the data is sent to the page the developer tools already manage to intercept the POST and its header.

Inside the header I found the item FORMDATA, which contained my password, exactly as I typed it, as below.

So I ask: is this normal? Even if the Yahoo site is secure, like SSL and everything? Is there any way to encrypt this data before sending?

I imagine that if a computer is infected with some malware or some hidden script is running in the browser, these may intercept the POST at some point and get the user password very easily.

Answer 1

Yes, this is normal - data security in WEB forms, as a rule is provided exactly by SSL, present in the HTTPS connection - and in fact, if the page is using HTTP and not HTTPS, all data transits in open - why HTTPS is so important, and has become the standard way of viewing any large site.

In particular, in WEB development, you can easily notice that for both the javascript of the page, and for the code that receives and treats the data of any form, the data of the password field are in plain text, treated in the same way as any text field.

It is possible to use an extra layer of encryption, using javascript, so that the data is encoded even before it is sent - but this is not a widespread practice because it has few gains on the HTTPS itself - and is very difficult to do well to the point of, in fact, improve safety (and not only have an illusory sense of security).

In particular, if the source browser is compromised by a malware that allows you to intercept Post data prior to the encoding used in the HTTPS connection, the same malware could also intercept the data before coding in some javascript (and also the javascript code used for the extra encryption and the keys you are using): ie the case of a well targeted attack, the vulnerability would still be there.

A technique like this, which tried to encrypt by obscurity combined with other techniques, inserting fake keyboard events in the typing of the password, separating the characters of the password in separate data packets, and using another layer of encryption, however, could rather avoid or slow down generic or automatic attacks (but as described above, even with all this care, you would be vulnerable to a refined attack whose target was specifically your application/site). However, I in particular consider that the feeling of being safe when you’re not is worse than knowing that you’re vulnerable.

Answer 2

Reading the excellent response from @jsbueno and also remembering a similar question about password encryption in Javascript’s @mgibsonbr, thought of a hypothetical solution with the use of a token.

As many are aware, using an additional secret mechanism, in addition to the password, greatly increases security.

Examples of token are those devices like pen drive which provide a sequential number based on the current date and time to be validated by the server. There are also solutions with mobile or SMS apps. Another mechanism is the "security card", as it is called by some financial institutions.

With this technique, the attacker would have to figure out not only his password, but the secret number of his token.

And an additional layer of security would consist of encrypting the user’s password based on the code provided by token, so that none of the information goes in plain text. Thus, even if the attacker could intercept the request and see the data, he would depend on a brute force attack to discover the key used (code of the token) and the content (the password).

The weakness of this is that, at least during the validity of the current session, the attacker could still intercept encrypted value and simulate the request to authenticate. But at least he wouldn’t have free access.

Answer 3

Actually, the site is https. What happens is that the browser developer tool shows the form data before it encrypts and sends it to your network card. If you install the wireshark and capture the data coming in and out of your network card you will notice that it is all encrypted. I did a test and follow print below:

ip 31.13.73.36 is from the facebook SSL server and 192.168.0.14 is mine.

Answer 4

We had a class on Information Security with these answers.

I would like to contribute an experience: the fact that we traffic data via http makes any system fragile. Some time ago I had a problem like this in a system that I upgraded where the Information Security staff did not approve this system on account of authentication failures: it was possible to identify the password through sniffers. The solution was to apply a password encryption algorithm before transacting the page, as the company would not provide me with the means to apply SSL. Security area validated new method of entry after encryption application.

I hope I contributed.

Answer 5

And normal to appear, but I suggest that everyone encrypts the passwords before submitting it through the form as this can prevent one of its users: may be stolen, lose important data like a photo or a work of years, have confidential data open, or worse. What I mean is that quite a site that does not use the famous HTTPS Digital Certificate to effect the sending of data. And it turns out that most of the population uses the same password for Old Orkut, Facebook, twitter, email, and Ales access password to the Bank’s website or simply from somewhere I gave to leave money with Pagseguro, Digital Payment, Free Market transferring everything to an account or making purchases to any address. Can erase important data for user, nowadays in mobile days with Apple’s Windows Phone and Android, Apple and Windows Phone default by own site and possible lock the device and delete all data including that photo you like and for some reason do not have a backup or a job that is in the memory of the mobile phone for you to pass in college or simply a project for years without sleep. Why is it unsafe to send without encrypting first? Websites that do not contain the Digital Certificate have no security in transferring information over the network and may be intercepted by third parties. And for those who use it costs nothing an additional security just simply add a small javascript code and you’re done.