Grezzo
2012-12-13 17:48:03 UTC
每個人都知道，如果他們有一個需要密碼才能登錄的系統，他們應該存儲所需密碼的散列&鹽醃副本，而不是純文本密碼。
今天想知道為什麼他們不也將用戶ID也存儲在類似的哈希&鹽醃密碼中？攻擊者必須先“破解”密碼和用戶名哈希，然後才能破壞該帳戶。這也意味著，如果對用戶名進行哈希處理並添加鹽分的電子郵件地址，則可以更好地保護用戶名，避免將其出售給SPAMmers。
因為您可能需要儲存鹽？當您忘記用戶名和/或密碼時，會發生可怕的後果，該怎麼辦。有一個原因沒有完成。
用戶名不用於身份驗證，僅用於標識。考慮到任何一種安全協議對待它們都會帶來麻煩-識別*不需要*保密的內容和識別*不需要*一樣重要。明確區分很重要。
“每個人都知道，如果他們的系統需要輸入密碼，他們應該存儲所需密碼的散列和加鹽副本，而不是純文本密碼。” *不*，***他們不***。對於安全新手來說，這些都不是顯而易見的。甚至加密和散列之間的區別也超出了某些人無法理解的範圍。
@zzzzBov好，也許我的意思是“每個了解安全性的人”
@lynks，但是如果數據庫被盜用時，他們沒有獲得用戶的所有電子郵件地址，那不是很好。他們不僅可以將這些地址作為垃圾郵件，還可以針對特定站點的網絡釣魚攻擊將它們作為目標。
-1
一秒鐘我以為這是個好主意，但是哪個公司不需要向用戶發送電子郵件？
通常，在將數據存儲到數據庫時，不會對數據進行哈希處理和添加鹽分。僅在需要時（例如保護密碼）才進行哈希處理。哈希用戶名的需求是什麼？換句話說，您的問題的前提是錯誤的……您假設應該有一個不對用戶名進行哈希處理的原因，而默認情況下，不對數據進行哈希處理。
原因可能是進一步阻止定時攻擊嗎？由於用戶名通常是通過字符串比較完成的，因此從理論上講，人們也可以阻止人們猜測（以微秒為單位）用戶名（通常是電子郵件地址）嗎？例如，如果某人想破解每個10,000,000個密碼的電子郵件地址用戶名，那麼在PHP中使用類似password_verfify（）的名稱作為用戶名可能會使失敗的返回時間更加不穩定，從而更難分析？人們仍然想通過電子郵件發送其社區信息，但這並不意味著電子郵件地址必須在...
...用於登錄的表。
但是，每個用戶名應有一個唯一的鹽...
基本上，我看到大多數人對此想法持懷疑態度的原因是“因為這不是過去的方式。此外，這是建立在過去基礎上的原因和假設。”登錄需要付出一定的代價，而無論您的觀點如何，該技術平均在計算上都更加昂貴。
衝突是可能的，但就何時存儲散列的用戶名而言，不可能提供良好的編程邏輯。
許多站點（例如stackexchange）都以評論和帖子之類的方式向公眾顯示用戶名。那麼散列用戶名有什麼意義呢？