寧靜的WCF服務認證

Question

我有一個應用程序，它公開通過Jquery POST和其他應用程序（iPad，Android等）由Web應用程序使用的服務。 我必須創建一個高度安全但仍然足夠快的身份驗證系統。

我想制作一個令牌，該令牌將在登錄時傳遞給應用程序，並將在特定時間段（例如30分鍾）內使用，該令牌應刷新自身且不會使會話過期。 因此，我想到了將令牌發送到服務並生成令牌的想法。 它將接受

1. 用戶身份

2. 密碼（均用公鑰加密）

3. 的AppId

服務器將通過私鑰解密該請求，並生成一個在特定時間內有效的令牌。 現在，由於這將高度依賴於私鑰（該私鑰將是相同的，因此系統內的某人可能泄漏它並濫用它），所以我希望在特定時間（例如2小時）后刷新私鑰。

題 -

1. 如何刷新私鑰並確保當前發出的令牌不會被拒絕。

2. 有更好的方法嗎

Answer 1

有更好的方法嗎？

是的，它叫做SSL / HTTPS。 如果您已經在使用HTTPS，則無需使用任何這種加密魔術。 如果您不使用HTTPS，則從設計上就已經不安全了，您想出的任何辦法都無法解決重新發明SSL的問題。

那么，如果傳輸是安全的（HTTPS），您應該怎么辦？

1. 客戶端發出身份驗證請求，以純文本形式發送用戶名和密碼。
2. 服務器根據與該帳戶一起存儲的（希望）哈希密碼驗證用戶名+密碼對。
3. 服務器使用靜態AES密鑰響應令牌（加密的帳戶ID，到期等）。
4. 客戶端將令牌用於所有經過身份驗證的請求。

簡單。

你可以做的一件事...

為了防止丟失用於非安全設備的憑據，您應該訪問Google和其他網站的頁面。 與其讓用戶輸入網站密碼，不如讓用戶訪問並登錄到您的Web服務器。 他們從那里單擊“為設備生成訪問令牌”。 生成唯一的數據字符串（20個或更多字符），並用其帳戶記錄。 然后，用戶可以從您的網站撤消此“備用密碼”。

如何使它更安全？

您確實無法做得更好，這就是原因...

假設攻擊者可以訪問您的私鑰。 然后，攻擊者可以在竊取用戶名和密碼的同時更換您的服務器或扮演中間人。

為了防止這種情況，您需要進行一些PKI交換，以發送由服務器提供給您的公用密鑰加密的密碼。 作為中間人，我可以簡單地給您我自己的公鑰並訪問用戶名和密碼，然后（如果我選擇）將其轉發到真實的服務器。

- 要么 -

為了防止這種情況，您可以使用一些salt +密碼哈希將代替明文密碼發送到服務器。 作為中間人，我可以簡單地為您提供一個固定的鹽值，然后為該鹽值預先計算一個完整的Rainbow表。 現在，我再次以明文形式輸入了每個人的密碼（最多）。

- 要么 -

為了防止這種情況，您可以使用PKI建立一些秘密會話密鑰，然后對每個通信進行簽名和加密。 好吧，gee ...聽起來很熟悉...請參閱Wikipedia上的SSL 。 意識到使SSL安全的唯一事情就是對其私鑰的保護。 一旦私鑰丟失，所有的安全性和信任都將丟失。

最后說明：

如果無法保護某些加密密鑰，則無法建立安全的通信。

您還應該意識到，在SSL的軟件實現（如OpenSSL）上已經花費了數千個工時，並且他們在其實現中不斷發現漏洞。 您自己實現並實現與IIS或OpenSSL一樣安全的希望幾乎是NIL。 那不是對您的Digg，這只是現實，我做不到，或者我只知道什至不嘗試。

最后，我的最終建議是關於您的聲明：“系統內部的某人可能泄漏它並濫用它”。 這是你真正的問題。 修復此問題，其他所有操作將變得更加容易。 保護服務器環境應該是您的首要任務。 您的第二要務是，如果您沒有做到第一，則應將對客戶的影響降至最低。

一些有用的鏈接：

• 如何使用一組特定的字符生成密碼。
• 另一個如何存儲加鹽密碼哈希的示例。