背景

大大小小的系統其實都離不開登錄這個小小的功能，前段時間老黃在審查公司部分系統代碼時，發現不少系統的登錄還是很粗暴的，粗暴到讓人不敢說話的那種。

說到登錄，結合標題，其實大部分人應該都猜到那個粗暴到讓人不敢說話的是什么問題了~~~

密碼明文傳輸，確實是很簡單粗暴的一種做法，但是帶來的風險也是可想而知的。

后面老黃就抽時間去看了一下我們比較熟悉的大網站是不是也會有這種情況。

明文傳輸的案例

#1 下面是一個財富網站的登錄接口，可以看到他們的也是挺隨意的，密碼也是明文傳輸的。

#2 下面是一個旅游相關網站的登錄接口，同樣也是明文傳輸密碼的，一不小心，還用13800138000成功登錄上了他家系統，嚇得老黃瑟瑟發抖~~

其實這樣的案例是數不勝數的，知道個大概就好了~~

上面兩個就是實打實的反面教材，再來看看幾個好一點的案例，有個鮮明的對比。

非明文傳輸的案例

#1 唯品會的登錄接口

可以看到vip還是稍微嚴謹一點的，至少讓別人猜不出來這個密碼的原文是什么。

偷偷看一下js代碼，可以發現是MD5了一下。

#2 拉勾網的登錄接口

看上去傳輸的內容也是MD5過后的內容。

去看一下js代碼，可以發現，拉勾傳輸的密碼還略微復雜了一點，不是單純的MD5，是兩層MD5和加鹽的結果。

上面兩種是比較常見的做法了。下面再來看一個稍微不一樣的。

#3 知乎的登錄接口

可以看出，他們比較狠，參數是什么都不給我們看了，一點人性光輝都沒，傳輸的內容都是完整的密文。具體是什么加密方式，這里就沒有繼續去看了，不外乎對稱和非對稱加密兩種比較常見。

歸納梳理

從上面3個密文傳輸的案例就可以大致知道，密碼傳輸，我們的可選方案是什么。

hash

加鹽 hash

加密

90%的系統，用前面2種就可以擋住不少壞人了，畢竟想撞庫，也是要花不少時間的。

其中對于使用hash的方案，除了用MD5以外，還可以考慮用SHA1或SHA256等。

如果真的要用加密的方案，可以用RSA+AES的組合方案。

在傳輸層做了不可逆的參數傳遞，那么后臺接口要怎么處理呢？

后臺接口，在登錄的時候，主要是進行驗證，驗證的話，就取決于創建用戶時，寫入數據庫的密碼，是對這個傳輸的密碼做了什么操作。

所以在驗證的時候，照葫蘆畫瓢即可。

最后老黃采取的方案是雙重MD5+加鹽。

總結

以上是生活随笔為你收集整理的谈谈登录密码传输这件小事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。