題:
在我的哈希值前面加上所使用的算法是否是錯誤的做法？
Mathias Lykkegaard Lorenzen
2018-11-08 19:25:07 UTC
view on stackexchange narkive permalink

假設我有一個包含大量用戶的數據庫。該用戶數據庫通常每個用戶都有一個哈希密碼。 b>

例如，代替散列 aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d ，我會存儲 sha1_aaf4c61ddcc5e8a2dabededeff3b482cd9a，

我注意到Argon2做到了這一點，實際上，我認為這很方便，因為隨著時間的推移，它可以更容易地部分遷移到較新的哈希算法以供新用戶使用。 / p>

我在生產代碼中未使用SHA1作為密碼。 SHA1是隨機選擇的。這個問題與散列方法的使用無關。

評論不作進一步討論；此對話已[移至聊天]（https://chat.stackexchange.com/rooms/85699/discussion-on-question-by-mathias-lykkegaard-lorenzen-is-it-bad-practice-pref）。
五 答案:
schroeder
2018-11-08 19:28:19 UTC
view on stackexchange narkive permalink

許多不同的密碼哈希系統都可以這樣做。所使用的哈希機制的類型不應（也不必是）秘密。 Kerckhoffs的原理說：

即使系統中除密鑰之外的所有內容都是公共知識，密碼系統也應該是安全的。

因此，如果您的系統具有適當的安全性，則哈希機制是否公開也沒關係。

為什麼“不應該”？Kerckhoffs的原則不應該要求保密，但是只要它不會導致您破壞密鑰安全性，那麼即使哈希算法也是保密的，也肯定不會造成損害。
關於Kerckhoffs的@leftaroundabout。在操作上和策略上，將哈希算法分類為秘密是一個問題。它試圖通過模糊來提供安全性，並且引入的控製成本超過了收益。更不用說Toby Speight提供的實際用例了。這不是關於添加alo類型，而是關於算法類型數據的分類。
_分類為秘密不是必需的，因為它是秘密的。出於性能原因，這可能是秘密的。
將其設為秘密與不公開之間的區別。在這種情況下，問題是關於數據的分類，而不是不公開（儘管上下文是公開）。
我的印像是，添加“默默無聞的安全性”仍然是一件好事。即使您知道系統的所有詳細信息，系統也應該是安全的，但是增加模糊性可以提高安全性（減慢攻擊者的速度，發現0天錯誤時隱藏系統等）。這樣公平嗎？
@NathanMerrill我想說的是，應視具體情況而定。在這種情況下，我認為將算法與散列存儲在一起的好處大大超過了通過掩蓋它而獲得的很小的安全性好處。
我必須同意@leftaroundabout。在我看來，對Kerckhoff的這種解釋與對Occam的Razor的常見解釋（即“最簡單的解決方案總是正確的”）存在類似的缺陷。只要不將實現細節作為安全措施，就可以將實現細節秘密化（或至少有些晦澀）。但是，這會使經驗不足的攻擊者的生活更加艱難。許多公司都通過法律手段保護了他們的“秘密調味料”商業秘密（即使知道了秘密也可以使用），但是他們仍然保留秘密。
@Damon很好，我的意思是，僅以“遵守Kerckhoffs原則”將實現細節與純文本捆綁在一起是不好的。除非它具有獨立的優勢（例如，促進向另一個哈希的遷移，否則不會給您帶來任何好處），為此，唯一的選擇是將哈希的名稱以ASCII開頭不是唯一的選擇，而且可以說是一個很棘手的選擇。故意發布實施細節僅是_advantage_，前提是這樣做可以給您同行評審（開源庫等）。如果都不適用，請保持簡單並省略算法名稱。
@NathanMerrill Kerkhoff原理用於允許硬化系統。如果鑰匙以外的所有東西都是打開的，則可以對其進行全面檢查。如果系統的某些部分未打開，則任何試圖驗證其安全性的人都必須對這些部分進行反向工程，然後才能對其進行正確評估。
-1
@Deduplicator的確是這樣：您希望它對於攻擊者來說是晦澀難懂的，但對於評估人員而言卻不是晦澀難懂的。在某些情況下，這絕對不可能。
Anders
2018-11-08 19:41:49 UTC
view on stackexchange narkive permalink

我同意 schroeder的說法是可以的。即使沒有前綴，攻擊者也可能會弄清您使用的算法。無論如何，保護密碼的是哈希算法的優勢，而不是算法的保密性。

請注意，許多哈希算法和庫已經為您做到了這一點。他們將所有相關信息（算法，成本因素，鹽，實際哈希值）嵌入到一個序列化字符串中。例如，參見模塊化加密格式或PHP password_hash函數。因此，不要自行製定方案。如果您使用的是下降的哈希庫，那麼您已經有了一個。

不要使用SHA1來哈希密碼。 那不行。

是的，我使用SHA1是因為對於SHA512中的示例，“ hello”的哈希值太長了。
@MathiasLykkegaardLorenzen也不要使用SHA512，除非它只是更大方案中具有更多迭代的組件。但是當然，舉個例子，任何事情都會發生！:-)
@MathiasLykkegaardLorenzen也不要僅使用多次迭代！使用經過驗證的PBKDF2之類的構造，該構造使用HMAC（而不僅僅是原始哈希迭代）。
SHA512是否被視為不安全？目前我還不知道。您能否引用說明原因的文章？
它的設計目的（即散列數據）並不是不安全的，但它的設計目的是“快速”。您希望您的密碼哈希函數能夠緩慢地阻止暴力嘗試。
但是，即使速度很快，是否仍然需要很高的嘗試次數（加上鹽和胡椒粉）仍然高得不重要嗎？
是的，這仍然很重要。散列函數因其速度而不能用於存儲密碼。借助Amazon上的一個p3.16xlarge實例，您可以在SHA512上每秒進行172.8億次猜測。這意味著您僅需151.17秒即可破解字母和數字的任何8個字符的密碼。密鑰派生功能可用於存儲速度較慢的密碼。在工作因子12上使用bcrypt時，您每秒只能進行424200次猜測。每個密碼將花費34.8天。另外，bcrypt和argon2內置了鹽，因此您不必擔心對密碼加鹽。
Toby Speight
2018-11-08 21:59:44 UTC
view on stackexchange narkive permalink

不，這不是一個壞習慣，可以說，您應該 保留此信息。

如您所見，這允許您隨時更改新密碼的算法，而不會使所有用戶的現有密碼失效（由於某種原因，這樣做會使您不受歡迎）。

有一個論點是，這使攻擊者可以搜索較舊，較弱的密碼來首先進行攻擊，但是完全沒有降低它們的安全性（假設Kerckhoff原理，該算法本身不必一定是秘密）。

如果可以存儲算法和鹽的組合，那麼一旦有更強大的算法可用，就無需保留較弱的密碼。如果當前條目說將密碼通過salt1的weakAlgorithm產生X，只需通過將X通過salt2的StrongAlgorithm進行X計算Y，然後將條目更改為說將密碼通過salt1穿過weakAlgorithm，然後將*的結果通過使用salt2的更強算法實現的*，將產生Y。無需等待用戶登錄。
leo v
2018-11-09 01:27:51 UTC
view on stackexchange narkive permalink

存儲哈希算法是一個好習慣，但是適當的密碼哈希函數（例如Argon2和PBKDF2）已經解決了這一問題。但是，單獨使用SHA1或SHA256進行密碼散列是一種不好的做法，因為使用字典攻擊和蠻力破解它們是一項固定（且相對較小）的工作。這些密碼應通過在下次登錄時重新哈希密碼而遷移到安全哈希算法。有關詳細信息，請參見 https://crypto.stackexchange.com/a/45405。

Nicolas Marshall
2018-11-10 00:11:22 UTC
view on stackexchange narkive permalink

這不是一個壞習慣，實際上是很常見的事情。實際上，如果您在Linux機器上打開 / etc / shadow 文件，則會看到帶有$ x $ salt $前綴的哈希密碼，其中x是一個數字，指示使用了哪種哈希算法。

現在需要考慮一些事情：

  • 不要將SHA1直接用作哈希算法。請改用bcrypt，scrypt或argon2（您確實提到過，但是不能重複太多）。它們確實使用簡單的哈希算法（例如SHA1）作為基礎，但是它們以特殊的方式運行以使其能夠抵抗攻擊。
  • 出於實際原因，由於您使用的是數據庫而不是文件，您可能希望將哈希方法和鹽存儲在單獨的行中。但是，您也可以選擇將以$ x $ salt $開頭的字符串存儲在數據庫中，並在檢查密碼時從該字符串中解析出salt和hash方法。它可能足夠快以至於沒有太大差異。在這兩種情況下，系統的安全性都是相同的。
OP在評論中說SHA-1僅用作示例，在生產中未使用
一個人需要使用“多次運行”而不是更多的東西，它需要CPU利用率或〜100ms和隨機鹽。
@schroeder我不太清楚閱讀問題。
@zaph絕對同意，但我不想具體說明。編輯我的答案，以減少歧義


ⓘ
該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到，我們感謝它分發的cc by-sa 4.0許可。
Loading...