http下是否有加密登陸密碼的必要
起因:是乙個90後團隊搞的乙個流氓公司,做 mac 下的盜版應用商場,被罵了一通,同時調侃 http 協議明文傳輸使用者名稱密碼,太低階。後來有個人站出來,提出「前端對資料進行加密沒有意義」這個觀點。後來就是的罵戰了。。。
無意義說:密碼在前端加密完全沒有意義,對密碼系統的安全性不會有任何提高,反而會引發不必要的麻煩。
(1)加密了也無法解決重放的問題,你發給伺服器端的雖然是加密後的資料,但是黑客攔截之後,把加密之後的資料重發一遍,依然是驗證通過的。直接監聽到你所謂的密文,然後用指令碼發起乙個http請求就可以登入上去了。
http在網路上是明文傳輸的,**和閘道器都能夠看到所有的資料,在同一區域網內也可以被嗅探到,你可以開個wireshark抓下區域網的包試試看。加密也沒有提高什麼攻擊難度,因為攻擊者就沒必要去解密原始密碼,能登入上去就表示目標已經實現了,所以,難度沒有提高。
(2)既然是加密,那麼加密用的金鑰和演算法肯定是儲存在前端的,攻擊者通過檢視原始碼就能得到演算法和金鑰。除非你是通過做瀏覽器外掛程式,將演算法和金鑰封裝在外掛程式中,然後加密的時候明文混淆上時間戳,這樣即使黑客攔截到了請求資料,進行重放過程時,也會很快失效。
有必要說:
(2)加密更安全,不是為了完全阻擋攻擊,而是為了提高攻擊的成本,降低被攻下的概率。
qq 網頁上的登陸模組(全程http/get請求):
function getencryption(password, uin, vcode, ismd5)
password:密碼
uin:使用者名稱
vcode:驗證碼
白話就是: md5(md5(md5(密碼) + 使用者的qq號) + 驗證碼)
驗證碼是一次性的, 所以,在你在網路層拿到本次的請求之後,無法做 重放攻擊, 因為驗證碼是不正確的.加入驗證碼的作用:防止軟體惡意註冊,防止暴力破解密碼,防止網路爬蟲,google利用驗證碼,讓使用者幫他實現的識別。
而當你獲取新的驗證碼, 但你並不知道 組合之前的內容[md5(md5(密碼) + 使用者的qq號)] 是什麼 , 所以你無法重新傳送本次請求實現登陸的目的.
至於 服務端的校驗, 只要將記錄下來的md5值(而不是記錄的明文), 進行同樣的運算, 得到的結果與提交上來的一樣, 即密碼正確.
安全點的方法:通過https協議提交登入資料,這樣黑客抓包時得到的資料是加密的,而且無法反解。
關於Web前端密碼加密是否有意義的總結!
起因 是乙個90後團隊搞的乙個流氓公司,做 mac 下的盜版應用商場,被罵了一通,同時調侃 http 協議明文傳輸使用者名稱密碼,太低階。後來有個人站出來,提出 前端對資料進行加密沒有意義 這個觀點。後來就是的罵戰了。無意義說 密碼在前端加密完全沒有意義,對密碼系統的安全性不會有任何提高,反而會引發...
基於RSA的WEB前端密碼加密方案
受制於web頁面原始碼的暴露,因此傳統的對稱加密方案以及加密金鑰都將暴露在js檔案中,同樣可以被解密。目前比較好的解決方案是web頁面全程或使用者登入等關鍵環節使用https進行傳輸。另外一種解決方案就是通過rsa進行加密。也就是說公鑰並不能進行解密,因此進行明文傳輸也是安全的。1 加密流程 服務端...
關於前端雜湊加密密碼的思考
在前端雜湊密碼是否是個不錯的方案?為了防止使用者或者管理員的密碼洩漏或者資料庫資訊洩漏出去,web應用普遍採用了在後端將密碼雜湊以後儲存在資料庫中,前端提供密碼,由後端進行雜湊後與資料庫進行對比,既然最終需要對比的是雜湊過得密碼,那麼為什麼不直接在前端將密碼雜湊直接交給後端儲存在資料庫呢?答案其實很...