Secure Login, Secure Login

Hello, hello.
- Plunge into the world of security.

It's no secret that the Internet is full of Trojans, viruses, etc., each has its own purpose, each makes its own actions. Some steal your accounts from the social. networks, the second collect ICQ accounts, the third just wait for commands from the server, the fourth collect bank data, the fifth do something else ... The list can be continued for a very long time.

I want to draw the attention of site creators to the security of transferring a password from a client to a server.
')
Until now, the network can come across sites that pass the password using the GET method.
But this is still half the trouble, the most interesting thing is when there is a public access counter on such sites ...

Do you understand what the joke is?
You can go to the counter statistics page and see the requests to the site ...

And if it is transmitted by GET - you can clearly see everything.
Such a bug suffers so far not one city chat and some guest ...
But this is their problem.

Let's say the developers made every effort to intercept data to 3m people.
Use POST, SSL but there is again a weak spot.

I knowingly at the beginning wrote about viruses.

The fact is that existing Trojans can intercept the sent forms and save them to themselves in a file ...

Then read the contents of the forms - a couple of trivia, they usually look like this:
[IP]
[DATE]
[URL]
username = root
password = ri2i098vnd
- Even SSL does not help ... everything is intercepted on the client side without any problems.
You can put a sniffer and see how things really are :-)

There is one solution that will significantly spoil the mood of the attacker, but the solution itself is quite simple - to hash the password on the client side . And after that, only transfer to the server.

That is, the algorithm works as follows:
0. When a user visits the site, the site gives him a COOKIE long, say, 50 characters.
1. The user enters a password (it is best through the virtual keyboard so that keystrokes are not lit)
2. The characters entered are hashed using cookies.
3. This is all transmitted to the server.

In this case, the client leaves the username and hash!
- You say that the attacker can also convey this ... Undoubtedly, there is one BUT! When a request leaves the user, the assigned COOKIES also leave. And COOKI Trojans do not intercept!
That is, the same password will eventually have different HESHI, and knowing the received HASH, the attacker is not authorized because the COOKI Trojan does not intercept, and therefore cannot enter. On the server side, COOKIES and HESHs are read and a decision is made on the basis of these data.

Do you understand what is the matter?
Now the attacker gets a bunch of hemorrhoids in addition.
He hoped to see the passwords "as is" and then the hashes, and even different ... and understand these are different passwords or one ...

The attacker will have to invent new ways to get the password, but inexperienced hackers will scare away, that is, degenerate schoolchildren and so on will be filtered out ...

THIS IS NOT PANACEA , but rather an effective way to hide the password from the Trojans and their owners, albeit for a while. Therefore, dear developers, if you write a service where money will flow, data, some important information - the extra method of protection will not hurt, and besides, it is quite simple to implement, but for clients with JS && Cookie disabled quite a bit ...

Thanks to all

UPD: For those who believe that the topic of delirium and SSL saves the world - here is the data from the local sniffer - watch
Hence the conclusion: SSL is good because the password is not intercepted between the client and the server, but on the client it can be removed easily and no matter where it goes to http or https

UPD2 : Guys, this is NOT a panic. No need to bale, spitting. IT WORKS On other sites and works successfully. The same OSMP.ru SO WORKED before moving to the certificate.

Do not write what it is.
There is a desire - there are opportunities
There is no desire - there are a lot of reasons.