I wanted to use MD5 hash for password transmission, but now the dictionary is full and has been cracked by a collision. Later, I plan to use sha1, but on the md5.js page, I suggest sha256 or stronger. Okay, use sha256.
Server
Java's messagedigest class can be directly used for Sha hashing, but after the hash is complete, it is byte [] type data, so we have to deal with it again, using the Apache commons-codec library, you cannot write it yourself.
Commons-codec Library:
Http://commons.apache.org/proper/commons-codec/download_codec.cgi
CodeYes: (key statements are highlighted in red)
Import Java. Io. unsupportedencodingexception; Import Java. Security. messagedigest; Import Java. Security. nosuchalgorithmexception; Import Org. Apache. commons. codec. Binary. HEX; Public Class Testsha { Public Static Void Main (string ARGs []) {string text =" 123456123456 " ; Messagedigest digest; Try {Digest = Messagedigest. getinstance ("SHA-256"); byte [] hash = digest. Digest (text. getbytes ("UTF-8"); string output = Hex. encodehexstring (hash );System. Out. println (output );} Catch (Nosuchalgorithmexception e ){ // Todo auto-generated Catch Block E. printstacktrace ();} Catch (Unsupportedencodingexception e ){ // Todo auto-generated Catch Block E. printstacktrace ();}}}
I tried several strings:
123456123456
SHA-256:Bytes
Hello World
SHA-256:Bytes
Client
The client uses the ready-made sha256.js.
: Http://www.bichlmeier.info/sha256.html
HTML code on the test page:
<HTML> Document. Write (Sha256_digest ("Hello World"));</SCRIPT> </body>
Page output:
Bytes
We can see that it matches with the above.
Summary
HashAlgorithmIt can only prevent the intercepted information from being pushed back to the plaintext of the password, but it cannot guarantee the security of the password during transmission. Therefore, it is best to add a random number sent from the server as the verification code by adding salt in use to prevent hackers from using the intercepted user ID + password for verification. After a Random verification code is added, the generated strings are converted into one-time password verification. For example:
Sha256 (sha256 (userid + password) + verification code)
The verification code is transmitted through the session to avoid the risk of session hijacking. Therefore, to ensure full transmission security, we also need to prevent session hijacking, such as binding cookieid to a MAC address.
However, none of the above practices can avoid the theft of the keyboard recorder. Therefore, it is not suitable for dealing with money. It can only prevent the exposure of customers' passwords on common websites.