如何使用HTTP基本身份驗證解決密碼哈希複雜性？

密碼哈希以512位16384輪的形式存儲爲PBKDF2。這需要我的小型服務器上的時間。用戶通過SSL/TLS進行HTTP基本認證。通過這個設置，每個請求都需要計算出在服務器上加載負載的哈希。如何使用HTTP基本身份驗證解決密碼哈希複雜性？

當前解決方案：第一次成功登錄後，我在客戶端存儲會話cookie。

臨：減少時間哈希計算最小的複雜性，仍然可以工作，不存儲cookie

缺點客戶：不接受cookie仍然創造負載的客戶。

其他方式來緩解： - 削弱密碼哈希（並不感到右） - 實現自己的/其他認證，而不是基本身份驗證（哪一個呢？增加了複雜性）

重點：安全第一，訪問管理/監督是安全的。然後服務器加載。

如何減輕密碼散列負載？如何不犧牲安全性？沒有安全通道（共享密鑰）的情況下是否有認證的替代方案？

來源

2013-10-18 aggsol

可能重複：[HTTP基本爲API - 如何「減少」憑據加密？]（http://stackoverflow.com/questions/19367490/http-basic-for-api-how-to-reduce-credential -encryption/19368660＃19368660） –

當前解決方案：第一次成功登錄後，我在客戶端存儲會話cookie。

這是典型的解決方案 - 使用實際存儲的會話或簽名的用戶時間戳記標記（HMAC比bcrypt更快地進行驗證）。

它還解決了HTTP Auth僅針對與請求auth的第一個頁面相同的目錄路徑發送的頁面的問題，以及瘋狂的瀏覽器不重新發送auth頭部直到每隔401單一請求。

缺點：不接受cookie的客戶端仍會產生負載。

根本不接受cookie的客戶端相對較少，幾乎所有其他需要登錄的站點都會中斷，因此對於常見情況，您通常應該可以。

實現自己/其他認證，而不是基本身份驗證（哪一個？增加了複雜性）

如果你堅決不依賴於餅乾，唯一的機制我可以與原生瀏覽器支持想到的是Digest Auth（並不真正解決問題，因爲它仍然是基於密碼的）和HTTPS客戶端證書（根據您的用戶羣是誰可能是一個可接受/方便的選項）。

來源

2013-10-18 09:22:02 bobince

如何使用HTTP基本身份驗證解決密碼哈希複雜性？

回答

相關問題