前幾天跟朋友一起討論關(guān)于傳輸過程加密的問題,http本身的設(shè)計就是無狀態(tài)?，F(xiàn)在很多的網(wǎng)站都在傳輸過程中都沒有進(jìn)行加密，只是進(jìn)行了加密，而這樣的話，別人通過嗅探的話，還是可以嗅探到你的明文密碼。
比如：你的一臺機(jī)器ip是. 23.22.2.3另一臺機(jī)器是23.22.2.4，在同一個下23.22.2.3的這是一個網(wǎng)站的，而我就可以用23.22.2.4這個服務(wù)器來嗅彈，23.22.2.3 80端口的信息 登錄的用戶名，等等這些信息。并且嗅探到的還是明文，先前我測試了dz dz也在傳輸過程中沒有加密，他不過就是數(shù)據(jù)庫加密比較另類一點，難解密!也就是用md5+salt來加密的。
也許有人會說，為何不用https加密呢？
1、https的是收費的。
2、https也可以突破嗅探 至于怎么樣突破 這里的就不在多說。
3、用https之后網(wǎng)頁會很卡，現(xiàn)在我們討論的并不是數(shù)據(jù)庫加密，而是傳輸過程的加密， 先前我自己想到的方法是 在客戶端js加密 而想到這個辦法后 有出現(xiàn)了種種的問題 問題如下： js的方法別人在網(wǎng)上已經(jīng)說過。
1.js加密的問題是，不論單向雙向，加密方式?jīng)]辦法隱藏，會被人家看到。
2.例如我密碼是 123abc,輸入表單后發(fā)送，js給加密成了 亂碼。 發(fā)給服務(wù)端再加密下和數(shù)據(jù)庫比對。問題來了，如果者截獲到j(luò)s加密后的亂碼，他可以禁用js，然后直接把亂碼輸入表單后發(fā)送，效果和直接得到用戶密碼發(fā)生一. js加密這里的作用除了不知道密碼是啥外，其他都沒用，亂碼也可以登錄。
js的加密的直接pass掉。這里根本行不通!
跟朋友又討論下 想到了其他的辦法 捆綁驗證碼 從而進(jìn)行加密。
流程：用戶->js提交服務(wù)器md5(md5(pass)+驗證碼)->服務(wù)器查詢出pass然后md5(pass+驗證碼)『數(shù)據(jù)庫里pass=md5(pass)』->刪除驗證碼的session
這個方法筆者也測試了，確實可行!發(fā)出捆綁驗證碼的，從而進(jìn)行傳輸加密的代碼，打包下載。