背景
- 對于一個系統來說，顯然把用戶的密碼明文存盤是大忌，那么必然要加鹽加密存盤，
- 在登錄注冊程序中，密碼顯然不能明文傳輸，那么必然會用https來做登錄注冊介面，
- 但是 https 并不是絕對安全的，經常用抓包工具除錯軟體的就會明白，雖然條件苛刻，但是也能實作中間人攻擊，那么為了安全，應該在瀏覽器或者客戶端把密碼先做加密處理（MD5），即使被中間人攻擊了，也不會泄露密碼，Link
- 那么問題來了，對于后端開發人員來說，客戶端是不能被信任的，如果采用MD5或其他摘要演算法，后端是無法對密碼強度進行檢驗的，如何解決這個問題？
實驗環節
為了解決這個問題，我首先對幾個知名網站的注冊進行抓包，看看他們是怎么處理這個問題的 (截圖丟失這里暫時只放結論)
- 阿里云賬戶： https + 明文密碼
- 微軟賬戶： https + 明文密碼
- 百度個人中心： https + 某種未知加密
- 微信公眾平臺: https + MD5
- 谷歌賬戶：https + 明文密碼
分析思考
- 上述5個網站中百度的最有意思，從密文上沒看出來是何種加密方法，密文長度和密碼長度趨勢相反，引起了我的好奇，于是提取js觀察，原來用了RSA演算法，這種非對稱加密傳輸密碼，確實能保證密碼被可靠的傳輸到后端，這個程序和https傳輸對稱加密密碼程序是一樣的，除非這個黑客黑到極致，不僅成功做了中間人攻擊，還順手把百度的那個js給改成了他自己的一套，用戶注冊的密碼被中間人解密后再用真正的百度的那個js加密請求給百度后端（
從這個角度考慮，只要中間人存在，就不存在絕對的安全，就算用了Hash加密密碼，中間人捕獲到你的md5密文，來偽造請求登錄，登陸成功過后還不是可以為所欲為，如果杠精說阿里、微軟谷歌的都不安全，微信公眾平臺和百度才叫真正的安全，那么大可懟回去，這只不過是五十步笑百步，在中間人面前，皆是螻蟻）， - https 的可靠性還是被認可的，畢竟對https進行中間人攻擊，條件是很苛刻的，如果是瀏覽器，會給你提示證書錯誤，阻止你的訪問，如下圖，如果是自己開發的客戶端，ssl證書的認證程序也是可控的，
- 回到題目，如果使用https + 密碼明文進行注冊，服務端自然可以檢驗密碼強度，除了擔心安全，沒什么好糾結的，
- 如果使用https + md5進行注冊，服務端無法檢驗密碼強度，那么能自己繞過前端驗證的，必然都是搞技術的開發者或者黑客（正經人誰 TM 使 Postman 注冊），黑客注冊一個脆弱的賬戶自己用的話，其意義跟注冊一個密碼強度高的賬戶沒區別，系統安全的要求都是防止惡意用戶越權訪問，如果黑客注冊一堆脆弱的賬戶給別人用，其依然沒意義，既然是黑客注冊的，密碼簡單和復雜沒區別，因為黑客完全掌握，因此也沒什么好糾結的，
- 如果使用RSA非對稱加密進行注冊，服務端可以解密得到密碼明文，從而檢驗密碼強度，密碼沒有在https加密下明文傳輸（這話說著別扭），心理好受，又擔心非對稱加密代價比較大，其實注冊不是一個高并發的場景，在網關層面做好防護，防止流量攻擊即可，因此也沒什么好糾結的，
總結起來，為了屁事少，前端做個密碼強度校驗，然后https請求到服務端，服務端對密碼加鹽增加密碼長度，以sha或者md5的形式存盤到資料庫即可，如果你作為不受信任的服務提供商，為了充分保護用戶隱私(避嫌)，大可在https請求之前，做個MD5哈希，服務端不接觸用戶用戶的明文密碼，就不會有因為日志等因素泄露用戶隱私的風險！
其實我有考慮能否使用同態加密，但是沒研究過其可行性，只是設想客戶端傳輸了服務端不可解的密文，服務端又能判斷密碼強度，然后服務端存盤這個不可解的密文，這樣就能做到md5形式的避嫌，又能做到不傳輸明文，還可以在服務端校驗密碼強度，全部痛點都解決了（除了開發者肝疼）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/258363.html
標籤：其他
上一篇：預防session劫持
下一篇：Vue框架——指令