2008-10-20 38 views
5

我正在將身份驗證構建到客戶端服務器應用程序中,並且我收到的一些反饋意見是我應該將哈希計算留給服務器(最初實現的目的是讓客戶端接收哈希,從哈希計算哈希客戶輸入的密碼,並比較它們)。這似乎是有道理的,但我留下了一個問題 - 我如何認證離線的用戶?脫機用戶認證的最佳模式是什麼?

例如,如果我部署到沒有互聯網訪問的移動設備,處理身份驗證的最安全方式是什麼?

我看到它的方式,我將不得不要麼允許客戶端接收的哈希+任何鹽信息,OR 使用單獨的PIN /密碼,並允許客戶端接收的哈希+鹽爲密碼。如果移動設備被破壞,那麼整個系統(例如,所有的網絡認證件)的安全性保持不變 -

,因爲它似乎限制了攻擊向量我贊成後者。

我最好的選擇和考慮是什麼?

+0

您是在談論永久離線訪問,還是重新驗證已經在線的人,現在他們已經不在? – Whisk 2008-10-20 21:52:55

+0

最終目標是讓客戶端稍後連接到服務器並同步其數據/更新。 – pc1oad1etter 2008-10-20 23:38:52

+0

對不起,我感到困惑。我並不是指所有用戶共享的「主」密碼,我的意思是一個保護用戶的移動數據庫和用戶的服務認證憑證的密碼。這有效地驗證用戶離線和在線。 – erickson 2008-10-28 15:54:35

回答

1

如果您更加詳細地解釋你的應用程序,我可能會發現,我關閉基地在這裏,但現在我會讓你的使用情況和威脅模型的一些假設。

我的理解是,您有一些敏感信息需要在具有間歇性連接的移動設備和某些遠程服務之間進行同步。該服務只能由經過身份驗證的用戶訪問,並且用戶必須向移動設備進行身份驗證才能訪問其信息副本,即使該信息處於脫機狀態。

如果您想要強大的安全性,請使用基於密碼的加密方式對移動設備的副本進行加密。

您可以使用相同的密碼來驗證服務,但一般來說,我會避免重複使用相同的密鑰用於不同的目的。更好的方法是爲移動設備提供主加密密碼,該密碼加密移動數據庫以及用於向同步服務驗證用戶的「密碼」。請注意,服務認證密碼實際上可以是用於SSL客戶端認證認證的私鑰,也可以是基於字符的密碼。

您必須評估只有一個密碼的風險,但在很多情況下,我認爲這爲用戶提供了便利,再加上一個強大的主密碼提供的安全性,易記的密碼是一個很好的平衡。

注意,這種方法將允許用戶,其服務的訪問已被撤銷,繼續訪問他們的本地副本,但沒有任何新的更新。您可以包含一些移動軟件強制執行的時間限制的概念,但是一個有決心的攻擊者可以繞過這個限制。

如果您只是需要玩具安全,您在移動設備上存儲正確散列的建議已足夠,並且散列真實密碼或備用散列確實無關緊要,因爲如果使用正確的散列,它應該花費數十億年時間才能找到能夠讓他們訪問遠程服務的密碼衝突。

但是,假設攻擊者可以看到密碼的哈希,什麼從在同步數據看太阻止他們?他們爲什麼需要恢復密碼?加密移動數據庫可以防止這種情況發生。

1

我想這可能取決於您的問題域,但對於安全的應用程序,由於缺乏信任,授權不能由客戶端完成。在簡單的例子中,你說明了散列計算和比較在客戶端完成的地方,爲了獲得訪問權限,所有需要做的事情是掛鉤一個調試器,逐步完成代碼並找到比較完成的位置,並將值返回之前的堆棧(例如)。恭喜,你已被黑客入侵。

我想知道更多關於您的特定應用程序在「脫機」模式下啓用的操作的信息,以及在設備重新連接之前您的計劃將用於協調,然後再查看啓用部分功能脫機。

+0

因此,您確認客戶端無法完全安全 - 我可以採取哪些措施來降低風險?您最近的評論可能會考慮到這一點 - 考慮在同步數據之前要做什麼或檢查什麼。 – pc1oad1etter 2008-10-21 00:17:43

0

我在幾分鐘前發佈了一個類似的問題,經過一番思考後,我可能會找到一個可接受的方法,使用公鑰/私鑰。下面是我列出我的應用程序的步驟:

  1. 當用戶下線後,他可以選擇使用密碼安全地訪問應用程序在離線時(帶有可選的加密,以防止盜竊)。

  2. 一旦上線,客戶端會發送一個id爲當前用戶(它可以像一個哈希表或者一些有關唯一標識用戶)。

  3. 服務器發送用該用戶的公鑰加密的授權令牌。

  4. 客戶端發回用他的私鑰解密的令牌。

  5. 最後,服務器發送會話令牌繼續進一步通信(最後這一步可能是不必要的,也許可以使用已經建立的身份驗證令牌?)。

我在加密或安全方面的專家,但它似乎對我這種做法是非常安全的,因爲我能想到的唯一辦法侵入服務器將是攻擊者有用戶的私鑰以及其密碼短語。

在敏感數據的情況下,可以像我之前提到的那樣通過加密來保護,或者通過密碼來驗證用戶身份,或者通過加密數據本身來防止設備丟失, 。

相關問題