通過使用哈希和鹽的SSL驗證

Question

我已經詳盡地研究了這個主題，並且被卡住了 - 希望能從有幫助的人那裏得到一些解釋。

背景：我的藍牙發送應答器連接到在我的應用程序中通過付款打開的鎖。用戶支付固定費用，鎖打開，他們抓住他們的物品，並關上門鎖。我試圖防止非付費用戶能夠打開這些鎖的欺騙攻擊。

我現在的解決方案理論上如下：每個轉發器都有一個隨機的32位鹽。一旦應用程序連接，認證請求被髮送到轉發器，該轉發器創建隨機挑戰字符串+其獨特的鹽。應答器然後使用SHA256迭代字符串10,000（以防止蠻力）時間。同時，最初的挑戰字符串+鹽被傳輸到應用程序，然後通過SSL將其發送到安全服務器，共享祕密散列密鑰和應答器鹽位於該服務器中。該字符串使用Sha256迭代10,000次，發送迴應用程序，然後返回應答器，該應答器根據其計算出的散列驗證服務器散列。如果相等，則鎖打開。

我的問題是：這是安全的嗎？我可以忽略一些明顯的安全缺陷，無論是暴力還是其他？我完全錯了嗎？任何幫助或建議將不勝感激

Answer 1

一個潛在的一點要考慮：

如果你將鹽和挑戰字符串到應用程序，然後到服務器，所有的信息，你需要生成正確的答案是可用的。唯一的祕密是你的哈希算法，但現在是堆棧溢出。

爲了讓生活變得更加困難，人們試圖破壞你的系統，你不需要在通信中發送鹽。相反，當您向系統添加新的發送應答器時，可以將發送應答器ID及其唯一的鹽添加到服務器可以訪問的數據庫中。不要發送鹽，而是發送隨機挑戰和轉發器ID。服務器然後使用應答器ID查找鹽。

這種方式鹽永遠不會被傳輸，並保持祕密（只要你的服務器沒有受到威脅）。

這有它自己的問題。鹽可以從發射機應答器反向設計，您用來生成散列的算法也可以。但它確實使事情變得更加困難，特別是如果您混淆並保護髮射機應答器上的鹽分。

爲了完整起見，值得一提的是，您希望確保您在所有組件之間發送的流量都是加密的。在服務器和客戶端應用程序之間，這意味着使用TLS。我對藍牙知之甚少，所以我不知道加密通信的標準方法是什麼。爲了進一步確保客戶端和服務器之間通過TLS進行通信，您可能需要實現一種形式爲pinning。