黑客攻防日记---刘欣
我最近發現了一個網站，是個博客平臺，很火，大家都到那里去寫注冊賬號，寫日志。
我也好奇地去看了看，不過，我主要是想看看有什么漏洞沒有，哈哈。
我發現他這個網站只用了HTTP協議，沒用HTTPS，換句話說，所有的數據都是明文傳輸的，包括用戶名和密碼， 我覺得機會來了。
我尊敬的大哥給了我幾臺服務器的信息，他說通過這幾臺服務器能夠偷窺，不，是監視發往博客平臺服務器的HTTP數據，還能通過這幾臺服務器當個中間人，攔截修改請求和響應， 這讓我喜出望外。
既然數據都是明文的，我就輕松地拿到了很多人的用戶名和密碼。更有意思的是，這些人的用戶名和密碼在很多平臺都是一樣的，這下次發財了！
我把用戶名和密碼都獻給了大哥。
最近收到了不少投訴，都是說密碼泄露的問題，我覺得不可能啊，因為我根本就沒有明文存儲密碼！
有些人還不相信，我百口難辨。
在服務器的數據庫里，我存的都是hash過的密碼，為了防止黑客破解， 每個密碼還都加了鹽(salt)以后才做的存儲。 密碼怎么可能泄露？
想來想去，我覺得還是從瀏覽器到服務器這一段出了問題，肯定是有人在偷窺， 老子一定要加密！
我想用RSA這種非對稱的加密方式（碼農翻身注： RSA的詳細解釋戳這里）：
服務器生成public key 和 private key ， 瀏覽器用JavaScript使用public key 對密碼加密， 然后服務器端用private key 進行解密。 這樣，密碼在傳輸過程中就不會被竊取了。
小黑的日記? 2010-6-24 多云
我突然發現，好多密碼都被加密了！
我讓大哥看了看，大哥說沒有私鑰，我是無法解密的， 不過他建議我當個中間人，也生成一對兒public key 和private key ， 對博客網站冒充是瀏覽器， 對瀏覽器冒充是博客網站。
我把我的public key 發給瀏覽器，瀏覽器把加密后的數據發給我，我用我的private key 解密， 就拿到了明文密碼。
然后我還得用博客網站的public key 把密碼加密，發給博客網站，讓它渾然不知。
這件事難度不小，真是讓人興奮。
MD, 密碼還是泄露，氣死老子了。
幸虧Bill提示我說可能有中間人，?我怎么忘了我和Bill 建立HTTPS的時候已經考慮到中間人這種情況了？
（碼農翻身注： 《一個故事講完HTTPS》）
中間人難于防范，還得搞數字證書證明身份，如果我把這一套都搞好，豈不是又實現了一遍HTTPS？ 重復發明輪子！
要不我也上HTTPS ，一勞永逸地解決問題？ 但是我這是個小網站，搞個正規的、瀏覽器不會提示安全風險的證書也不便宜吧？
真是煩人！
當中間人真是爽！
老子決定不再折騰HTTPS了！
Bill建議我可以對瀏覽器發過來的密碼加密， 其實也不是加密，而是做個Hash， Hash過的數據是不可逆的，不能恢復原始的明文密碼。
瀏覽器端：
hash(password,salt) -> hash_password
然后瀏覽器把（username, hash_password） 發給服務器端。
服務器端：
從數據庫獲得之前保存的hash_password
和瀏覽器傳遞過來的hash_password比較，看看是否相等。
從此以后，網絡上傳輸的都是所謂hash_password，再也看不到明文密碼了， 讓那幫偷窺的孫子們哭去吧！
ps : 在瀏覽器中進行hash的時候，有一個salt參數， 這個salt從哪里來？ 肯定是從服務器端獲取的啊。
大哥猜對了，那家伙果然對密碼做了hash，然后再發到服務器端，現在我難于獲取明文密碼了。
不過，那家伙還是留了一個大漏洞，既然我還能監聽到 user_name, hash_password， 我就重新發送一下到服務器端，還是成功登陸這個博客系統了！ 哈哈！
焦頭爛額！
這個瀏覽器端的hash操作沒能發揮作用。今天研究了半天，才發現那些黑客可以重放攻擊。
Bill說主要的原因還是salt固定導致的， 我決定再增加一點難度，增加一點動態的東西：驗證碼（captcha）！
用戶登錄的時候，發個驗證碼(captcha)到瀏覽器，這個驗證碼每次都不一樣。
瀏覽器端：
第一次Hash:
hash(password,salt) -> hash_password1
第二次Hash:
hash(hash_password1,captcha) ?->?hash_password2
然后瀏覽器把（username,?hash_password2，captcha） 發給服務器端。
注意：hash_password1并不會發送給服務器， 黑客們窺探不到。
服務器端：
驗證captcha 是否正確
使用username從數據庫獲得hash_password
hash(hashed_password,captcha) ?-->?hash_password3
比較hash_password2和hash_password3，看看是否相等。
如果相等，登錄成功，否則，登錄失敗。
hash_password2是使用一次性的驗證碼生成的， 即使被那幫孫子截獲，他也沒法展開重放攻擊，因為驗證碼已經失效了。
那家伙越來越聰明了嘛，增加了驗證碼，老子的重放攻擊也不管用了。
不過大哥真是威武，他告訴我要另辟蹊徑，想辦法攻擊博客系統的數據庫，只要把數據庫拿到了，用暴力的方法破解它！
今晚就開始行動！
Bill今天來了，他告訴我一件重要事情，不管你前端怎么加密，后端的安全措施一點都不能少！
我決定，把用戶在瀏覽器中輸入的密碼做兩次hash, 一次在瀏覽器端做，另外一次在服務器端做，把最終的結果作為密碼存到數據庫中。
瀏覽器端：
front_hash(password,salt) ->front_hash_password
發送(username,front_hash_password)到服務器端
服務器端：
back_hash(front_hash_password,salt) -> backend_hash_password
和數據庫保存的hash_password做比較， 看看是否相等。
這么做的結果就是， 如果那幫孫子真的把我的數據庫給偷走了，他們也很難通過撞庫的方式破解其中的密碼。
因為他們通常會把常用密碼建立一個字典，然后通過hash算法生成hash值，如果這個hash值和待破解數據庫的值相等，不就知道明文是什么了嗎？
但是我的數據庫中的密碼是通過front_hash_password 作為明文密碼，再次hash計算出來的。而那個front_hash_password本身就是個散列值，毫無規則可言。假如它是個32位的16進制字符串， 那將會有16^32 中組合，這是個天文數字，?這樣字典也就難以建立了。
如果黑客把密碼也按照我的方式，把常用的密碼做兩次hash呢？
這也不怕，Bill說可以把瀏覽器端的hash算法設置得復雜一點，增加破解的難度。 當然復雜的算法比較耗時， 但是Bill說了： 瀏覽器是分布的，完全可以充分利用他們的計算能力嘛！
Bill真是個聰明的家伙。
為了最終的安全，我想我還是上HTTPS吧！
終于把博客系統的數據庫給拖下來了，可是怎么都破解不了。
大哥研究了一下說，這個網站可能用了復雜的Hash算法, 破解起來太耗時間了，放棄吧。
更加悲催的是，我發現這個網站開始使用HTTPS了，真的難以下手了。
我還是去看世界杯去吧。
總結
以上是生活随笔為你收集整理的黑客攻防日记---刘欣的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： vue3+ts 实现防抖功能
- 下一篇： ERP项目组员工年度工作总结2010(刘