前幾天跟朋友一起討論關(guān)于傳輸過程加密的問題,http本身的設(shè)計(jì)就是無狀態(tài)。現(xiàn)在很多的網(wǎng)站都在傳輸過程中都沒有進(jìn)行加密，只是數(shù)據(jù)庫(kù)進(jìn)行了加密，而這樣的話，別人通過嗅探的話，還是可以嗅探到你的明文密碼。

比如：你的一臺(tái)機(jī)器ip是. 23.22.2.3另一臺(tái)機(jī)器是23.22.2.4，在同一個(gè)網(wǎng)關(guān)下23.22.2.3的這是一個(gè)網(wǎng)站的服務(wù)器，而我就可以用23.22.2.4這個(gè)服務(wù)器來嗅彈，23.22.2.3 80端口的信息 登錄的用戶名，等等這些信息。并且嗅探到的還是明文，先前我測(cè)試了dz dz也在傳輸過程中沒有加密，他不過就是數(shù)據(jù)庫(kù)加密比較另類一點(diǎn)，難解密！也就是用md5+salt來加密的。

也許有人會(huì)說，為何不用https加密呢？

1、https的是收費(fèi)的。

2、https也可以突破嗅探 至于怎么樣突破 這里的就不在多說。

3、用https之后網(wǎng)頁(yè)會(huì)很卡，現(xiàn)在我們討論的并不是數(shù)據(jù)庫(kù)加密，而是傳輸過程的加密， 先前我自己想到的方法是 在客戶端js加密 而想到這個(gè)辦法后 有出現(xiàn)了種種的問題 問題如下： js的方法別人在網(wǎng)上已經(jīng)說過。

1.js加密的問題是，不論單向雙向，加密方式?jīng)]辦法隱藏，會(huì)被人家看到。

2.例如我密碼是 123abc,輸入表單后發(fā)送，js給加密成了 亂碼。 發(fā)給服務(wù)端再加密下和數(shù)據(jù)庫(kù)比對(duì)。問題來了，如果入侵者截獲到j(luò)s加密后的亂碼，他可以禁用js，然后直接把亂碼輸入表單后發(fā)送，效果和直接得到用戶密碼發(fā)生一. js加密這里的作用除了黑客不知道密碼是啥外，其他都沒用，亂碼也可以登錄。

js的加密的直接pass掉。這里根本行不通！

跟朋友又討論下 想到了其他的辦法 捆綁驗(yàn)證碼 從而進(jìn)行加密。

流程：用戶輸入密碼->js提交服務(wù)器md5(md5(pass)+驗(yàn)證碼)->服務(wù)器查詢出pass然后md5(pass+驗(yàn)證碼)『數(shù)據(jù)庫(kù)里pass=md5(pass)』->刪除驗(yàn)證碼的session

這個(gè)方法筆者也測(cè)試了，確實(shí)可行！發(fā)出捆綁驗(yàn)證碼的，從而進(jìn)行傳輸加密的代碼，打包下載。

http://dl.dbank.com/c0a94csv5e代碼朋友寫的，我只是跟他討論了入侵者用到的手法而已。提供給了思路。