Security in submitting information via form in the HTTP header

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 open - so HTTPS is so important, and has become the standard form of visualization of any great website.

In particular, in WEB development, you can easily realize that for both the page javascript and the code that receives and handles the data of any form, the password field data is pure text, treated in the same way than any text field.

You can instead use an extra layer of encryption, using javascript, so that the data is encrypted even before it is sent - but this is not a widespread practice because it has few gains over HTTPS itself - and is very difficult to be well done to the point of actually improving safety (and not just having an illusory sense of security).

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

Such a technique, which attempted to encrypt by obscurity combined with other techniques, inserting fake keyboard events into the password entry, separating the password characters into distinct data packets, and using another encryption layer, however. (but as described above, even with all these cautions, you would be vulnerable to a refined attack targeted specifically at your application / site). However, I personally feel that the feeling of being safe when you are not is worse than knowing that you are vulnerable.

Reading the excellent response from @jsbueno and also remembering a similar question about @mgibsonbr Javascript password encryption, I thought of a hypothetical solution using a token .

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

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

With this technique, the attacker would have to discover 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 the token , so that none of the information goes in plain text. Thus, even if the attacker could intercept the request and view the data, it would depend on a brute-force attack to find the key used (token code) and 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 would not have free access.

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

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

We had an Information Security class 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 improved where Information Security personnel 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, since the company would not provide me with the means to apply SSL. The Security area validated the new input method after applying encryption.

I hope I have contributed.

And normal to appear, I suggest that everyone encrypt the passwords before submitting the form since this can prevent one of your users from being stolen, lose important data such as a photo or a year's work, have confidential data open, or worse. What I mean is that quite a site that does not use the famous HTTPS Digital Certificate to send data. And it happens that most of the population uses the same password for Old Orkut, Facebook, twitter, email, and such until password access to the Bank's website or simply from somewhere I gave to leave money with Pagseguro, Pagamento Digital , Free Market transferring everything to an account or making purchases to any address. They can delete important data for users, nowadays on cellular days with Apple's Windows Phone and Android, Apple and Windows Phone by default by the website itself and it is possible to lock the device and delete all data including that photo you like and by some reason does not have a backup or a job that is in the memory of the cell phone for you to spend in college or simply a project of years without sleep. Why and unsure to send unencrypted before? The sites that do not contain the Digital Certificate have no security in the transfer of the information through the network and can be intercepted by third parties. And for those who use it does not cost anything an additional security simply simply add a small javascript code and that's it.