App一般都需要用戶的登錄操作。登錄惠啄，就需要用到用戶名和密碼慎恒。為了安全起見，暴露明文密碼的次數(shù)越少越好撵渡。這里有兩個問題：1融柬，怎么能最大程度避免泄露用戶的密碼呢？2趋距，在登錄后粒氧，app后端又怎么去驗證和維持用戶的登錄狀態(tài)呢？本文先講述第一個問題--如何最大程度避免用戶密碼泄露节腐。第二個問題放在下篇外盯。
密碼存儲
- 用戶密碼必須不能明文存儲摘盆。如果數(shù)據(jù)庫泄露，那么所有用戶的密碼就會被泄露饱苟，存在非常高的安全風(fēng)險孩擂。
- 用戶密碼不能直接hash存儲。hash破解現(xiàn)在已經(jīng)不是一件難事箱熬，方法有查表法类垦、反向查表法、彩虹表等城须。
- 在存儲用戶密碼的時候蚤认，一定要考慮的是加鹽hash。所謂 鹽(salt) 實際是一個隨機字符串酿傍，在用戶密碼的前面后者后面加一個隨機字符串烙懦，然后再hash，即使hash被破解赤炒，也能保證用戶密碼不丟失氯析。加鹽hash需要一些基本原則：
- 鹽值永遠(yuǎn)不要重復(fù)使用；
- 每個用戶的每一個密碼都要使用獨一無二的鹽值莺褒；
- 用戶每次創(chuàng)建帳號或更改密碼時掩缓，密碼應(yīng)采用一個新的隨機鹽值；
- 鹽值需要單獨存儲遵岩，或者固定鹽值長度你辣，然后固定放在 hash結(jié)果 的某個位置
- 鹽值不要太短，建議32位以上
- MD5 尘执、SHA1舍哄、SHA256、SHA512誊锭、RipeMD表悬、WHIRLPOOL、SHA3等hash算法丧靡，都屬于快速加密hash函數(shù)蟆沫，他們的弱點在于，加密快温治，破解也快饭庞。建議使用 慢哈希函數(shù) 進行hash處理，如 PBKDF2 或 bcrypt的安全版本熬荆。 慢哈希函數(shù) 在hash的計算過程中舟山，也會變慢，但是這個速度是可以根據(jù)參數(shù)調(diào)整的，建議慢hash時間調(diào)整到200ms-500ms捏顺，如果速度過慢六孵，容易讓系統(tǒng)遭受ddos攻擊。
- 到這一步幅骄，系統(tǒng)還不是完全的安全。如果我們采用加密算法本今，比如 AES對稱加密拆座，對hash結(jié)果進行加密，那么只有知道秘鑰的人才能解密出hash結(jié)果冠息，然后才有機會對hash破解挪凑。但是，又引出了一個新問題：如何保證秘鑰的安全性逛艰？這個密鑰必須在任何情況下躏碳，即使系統(tǒng)因為漏洞被攻陷，也不能被攻擊者獲取散怖。如果攻擊者完全進入系統(tǒng)菇绵，密鑰不管存儲在何處，總能被找到镇眷。因此咬最，密鑰必須密鑰必須被存儲在外部系統(tǒng)，例如專用于密碼驗證一個物理上隔離的服務(wù)端欠动，或者連接到服務(wù)端永乌，例如一個特殊的硬件設(shè)備。
- 如果被拖庫具伍，數(shù)據(jù)發(fā)生丟失翅雏，我們要做的第一件事應(yīng)該是：確定系統(tǒng)被暴露到什么程度，然后修復(fù)攻擊者利用的的漏洞人芽；在還沒有完全發(fā)生什么事情時望几，需要盡快通知用戶修改密碼，甚至強制用戶修改密碼啼肩；如果數(shù)據(jù)庫包括信用卡等信息橄妆，應(yīng)該通知用戶仔細(xì)檢查近期賬單甚至銷掉這張信用卡。
密碼傳輸
- 上面說的問題只是密碼存儲問題祈坠，實際上還要一個更嚴(yán)重的問題需要考慮害碾，既密碼的傳輸問題窘哈。用戶在注冊或者登陸時叹誉，需要將密碼傳遞到服務(wù)端锤躁。但是要嚴(yán)禁明文傳輸密碼璧亚。
- 建議的一種方案是痹屹，非對稱加密算法對密碼進行加密傳輸：
- 用戶在傳輸密碼之前，先像服務(wù)器請求一個公鑰士聪；
- 然后傳輸?shù)拿艽a是 使用 公鑰加密的 密碼某饰，而這個加密之后的密碼，只有用自己的私鑰才能解開剃袍；
- 服務(wù)端使用私鑰解開密碼黄刚，然后加密存儲。
- 這里面又涉及到兩個問題：1是私鑰的安全性存儲民效；2公鑰私鑰對 是否需要對每一次登錄或注冊都重新生成一對憔维？ 從安全性來講，后者顯然會更好畏邢，而且公鑰业扒、私鑰有過期時間。
- 具體的實現(xiàn)過程舒萎，這里不講程储。
基本原則
- 永遠(yuǎn)不要告訴用戶輸錯的究竟是用戶名還是密碼。
- 通用的提示：“無效的用戶名或密碼”臂寝。
好久沒寫文章了章鲤。希望以后能多學(xué)習(xí)一些東西，多寫一些交煞。
