依靠散列進行文件識別有多安全？

Question

我正在設計一個LAMP堆棧頂部的存儲雲軟件。

文件可能具有內部ID，但將它們存儲在服務器文件系統中的文件名不是以遞增的id存儲，而是使用散列作爲文件名。

如果當前集中的數據庫應該分片或分散或者應該建立某種主 - 主高可用性環境，那麼在數據庫中作爲標識符的哈希也會具有很多優點。但我還不確定。

客戶端可以在任何字符串下存儲文件（通常是某種路徑和文件名）。

此字符串保證是唯一的，因爲第一級就像用戶在Amazon S3和Google存儲中註冊的「桶」。

我的計劃是將文件存儲爲客戶端定義路徑的散列。

這樣，存儲服務器可以直接爲文件提供服務，而無需數據庫詢問它是哪個ID，因爲它可以計算散列，從而可以即時計算文件名。

但是我怕碰撞。我目前正在考慮使用SHA1哈希。

我聽說GIT也使用哈希也修訂標識符。

我知道碰撞的可能性真的很低，但是可能的。

我只是不能判斷這一點。你會或不會依賴hash來達到這個目的？

我還可以對路徑編碼進行一些規範化處理。也許base64作爲文件名，但我真的不希望這樣，因爲它可能會變得混亂，路徑可能會變得太長，可能還有其他複雜性。

Answer 1

假設您有一個具有「完美」屬性的散列函數，並且假定加密散列函數的方法適用的理論與適用於birthday attacks的理論相同。這就是說，給定最大數量的文件，通過使用更大的散列摘要大小，可以使碰撞概率儘可能小。 SHA有160位，所以對於任何實際數量的文件來說，碰撞概率幾乎爲零。如果您查看鏈接中的表格，您會看到具有10^10個文件的128位散列的碰撞概率爲10^-18。

只要概率足夠低，我認爲解決方案是好的。與行星被小行星擊中的概率，磁盤驅動器中無法檢測到的錯誤，在你的記憶中翻轉的位等 - 只要這些概率足夠低，我們就不擔心它們，因爲它們將「永遠不會」發生。只需足夠的保證金，並確保這不是最薄弱的環節。

有一點需要關注的是哈希函數的選擇，它可能存在漏洞。是否有其他身份驗證或用戶是否僅提供路徑並檢索文件？

如果您想要攻擊者試圖暴力破解上述場景，他們需要先獲取2^18個文件，然後才能獲得系統中存儲的其他隨機文件（再假設128位散列和10^10文件，您將擁有更少的文件和更長的散列）。2^18是一個相當大的數字，你可以蠻力的速度受到網絡和服務器的限制。在x嘗試策略之後簡單地鎖定用戶可以完全關閉這個漏洞（這就是許多系統實現這種策略的原因）。建立一個安全的系統非常複雜，需要考慮許多要點，但這種方案可以非常安全。

希望這是很有用的...

編輯：另一種方式來思考這是幾乎每一個加密或認證系統依賴於具有其安全性非常低概率的某些事件。例如我可以很幸運，猜測512位RSA密鑰的主要因素，但這是不太可能的，因爲系統被認爲是非常安全的。

Answer 2

雖然碰撞的可能性可能非常小，但想象一下，因爲碰巧存在散列衝突，所以將一個高度機密的文件從一個客戶提供給他們的競爭對手。

=業務

我寧願使用散列的事情是如果你有一個數據庫時的碰撞的確發生;-)

不太重要的文件存儲下的GUID的結束 - 所以不是遞增索引，但具有適當的全局唯一標識符。當涉及到分佈式碎片/高可用性等時，它們可以很好地工作。

想象一下最糟糕的情況，並假設它會在有線雜誌中作爲一個令人驚歎的啓動推出後一週發生......這是一個很好的壓力測試該算法。