微軟和谷歌這樣級別公司又是如何防範拖庫的？

01-13

有感於最近網易郵箱被「拖庫」的嚴重安全事故，鑒於網易在網上風評一向還可以，對國內的公司有點失望。
想知道微軟、谷歌這個級別的公司是如何防範此類問題的。一般聽說過用戶密碼泄露，但是是個別用戶，沒有批量泄露的。
另外，微軟前段時間把用戶過長的密碼揭短到 20 位，難道他是明文存的密碼？不是大忌諱嗎？

本人現在用 Outlook，有點好奇。

M$消費級服務不知道，企業級是Active Directory改，但都是獨立的驗證伺服器。AD這東西都存ESENT，啊就一個ISAM，高級查詢都得自己搞，拖個庫都困難。然後驗證的Portal呢就一AD FS改，輸入對了簽發一個token丟給產品服務，產品就知道是這個用戶了。這個就是SSO，Google也用的是類似的方案，但是肯定不是AD，但無論如何產品是不會是處理密碼的。有個行業標準SAML就是干類似的事情的，你可以參考一下。

撞庫是可以有一定概率搞出密碼的，這個其他答主講的很明確了。

在這裡說一下蘋果。iCloud搞了那麼多年連個SSO都沒有，這無疑就是加大暴露面。

樓上有小夥伴說加鹽的問題，然後經過了一些討論，覺得可以說說密鑰保護裡面加鹽的通用做法

首先，你要明白的是：加鹽不是為了密碼不被破解，而是為了密碼不被批量破解！

——————為毛直接Hash不安全——————

直接Hash出密碼的公式是這樣的：

password_hash = hash(password)

這種方式極其容易被破解，一個彩虹表就能把整個庫的Hash跑出來，8位密碼可以直接查表，O(1)複雜度，所有密碼破解只要O(n)

——————神馬是鹽————————

鹽就是在進行計算hash密碼的時候增加的一個隨機字元串

公式就像這樣：

password_hash = hash(password + salt)

鹽是明文保存的一串隨機字元串，是隨機字元串，隨機演算法可以無所謂。

——————怎麼保證不被批量破解嘞————

根據加鹽hash計算公式，每個hash密碼的計算都是密鑰+salt再進行hash，而salt本身是隨機串，所以理論上破解一個用戶密鑰的複雜度就是O(n)，而破解整張表的複雜度是O(n**2)，如果hash字串長度適中，比如sha-256，計算量還是比較大的。一般黑產不會搞成本這麼大的事情。（不過最近聽說有雲計算暴力破解的辦法，sigh）

——————關於鹽——————

1、鹽必須是隨機串

有的公司為了方便，把時間、用戶名、ip地址什麼的作鹽，其實比較作死。因為不隨機的字串具有規律性，有人嘗試過直接構造非隨機鹽的彩虹表，好像效果也不錯。

2、鹽不能太短

和密鑰不能太短是一個道理，假設是8位鹽，也就256種可能。為每個鹽造個彩虹表也OK，反正現在存儲不值錢。

3、鹽不能復用

每個用戶都需要一個隨機鹽，理由很簡單，如果是統一鹽，那和直接hash其實是一樣的

4、鹽存在用戶表裡面

基本鹽都和用戶表一起存，因為本身就是明文保存的，所以對鹽也不需要有安全保存的考慮，方便業務實現就行。

不僅要防黑客，更要防碼農。對敏感數據分級管理。普通資料庫賬號能看到用戶表，用戶名.訪問密碼，信用卡號欄位要授權。不然查詢出來都是加密的。要從技術上強制保證，不能靠初級碼農去解決安全問題。可以使用商業資料庫加密功能，強制加密欄位，或者自己封裝driver

首先在爆破這件事上不管你加了多少層密鑰密碼複雜度多高，依舊是能夠破解，當然這是在不計算時間成本以及資源成本的前提下

所以最好的辦法就是永遠不讓你獲取到數據，就像 lovny說的那樣，存放數據的伺服器單獨放，只開放驗證介面不開放數據查詢介面，你只能知道1或者0 不能知道是啥

我猜：

第一、要有外部環境的約束：立法並且有效執法或者有重視商譽的市場環境並且用戶有自我保護意識，有低成本的維權方式。使得企業要想發展，就要重視社會責任、重視信息安全和用戶隱私。

第二、企業內部切實把信息安全放在重要位置，要有投入。

第三、要有懂得安全、敬業並且做事嚴謹的工匠（工程師），並且能得到重視。

有了第一條，去哪兒的到店無房、收錢不出票就沒有生存空間，也更不會逼得攜程被迫同流合污；支付寶在店大欺客時就會有所顧忌；360也不敢用那麼多的流氓手段。

有了第一條，就會慢慢有第二條，敬業的安全工程師才有好的工作機會。才會有更多的人能滿足第三條。

現在你看知乎的回答，就知道第三條大概是不滿足的。

微軟截短用戶密碼嗎？請問是什麼時候的事情？有官方證實嗎？

國內的法律對加密是怎麼規定的？有官方的說法必須保存明文嗎？

虹膜掃描加密數據單獨存放數據的伺服器單獨驗證密碼的伺服器密碼機制由管理層保管KEY 一個加密的函數由一個人寫一部分代碼他的上司在寫一部分代碼他的上上司再寫一部分代碼，最後只有最高級的管理層知道整個加密函數的代碼，那個上司必須是屬於IT部門的高管必須精通IT也是IT方面的天才，而且擁有公司的部分股份，以防止用戶數據被泄露。

我只想說，國內有些IT網站，用明碼保存密碼，非一般的噁心。

所以不是別人多強，而我們多弱。

應用層不能直接訪問資料庫，只能採用內的API進行，並且API只有單個驗證用戶名和密碼是否正確的功能或者獲取單個用戶信息的功能，禁止進行批量查詢。

另外從加密方法來說，不僅僅可以加salt，也可以使用非對稱加密方法對密碼加密。

密碼難道不是類似 MD5(明文密碼）算出來的？

非安全出生，以下評論僅供參考

有知友提到了簡單密碼的問題。如果資料庫存儲的是明文密碼的MD5、SHA1，那麼一旦資料庫泄漏了，簡單密碼被破解是無法避免的。攻擊者可以事先計算簡單密碼（如123456）的MD5、SHA1，如果在資料庫中有匹配，密碼就泄漏了。應該說這不是MD5的鍋，用戶和公司各背50%的鍋吧。

一個簡單的解決方案是公司為MD5加鹽。比如維護一個內部secret，對MD5再做一遍運算。這就要保證secret不被泄漏。另一個問題是如何更新secret？如果一直不更新，泄漏只是時間問題；然後，如果更新，怎麼更新？把所有密碼重新計算一遍？

有知友糾結「內部secret」和隨機鹽的問題，這只是具體實現罷了，也可以將隨機鹽整體看作」內部secret」。無論如何，你得維護它。如果你將隨機鹽放在密碼一起，那麼一旦被拖庫，這個秘密也就不存在了。

再解釋下簡單密碼

在CSDN泄漏明文密碼的事件中，2.17%的用戶用了123456，0.65%用了123456789，0.59%用了111111，等等[1]。如果網易也存在大量簡單密碼，那麼我挨個檢查簡單密碼，就可以破解大量用戶的賬戶。

把鹽放在同一個資料庫中，這次就會被一起拖走，顯然無法解決簡單密碼的問題。簡單的辦法是放在兩個地方，攻擊者必須拖走兩個資料庫才行，減少了被攻擊的概率（這辦法很難嗎？為啥一定要把鹽放一個資料庫？）。

如果你會定期更新鹽，那麼攻擊者就必須在你更新鹽的周期內，完成拖走兩個資料庫的操作，就更難了。

是我沒說明白？我只是想去增加攻擊者的代價，絕對安全是不可能的。

［1］Z. Li et al. A Large-Scale Empirical Analysis of Chinese Web Passwords. USENIX Security"14.