我正在創建一個Web服務以允許應用程序開發人員（A.K.A.我的朋友）查詢我的數據庫。事情是，作爲一個安全約束，我希望能夠跟蹤每個用戶。我正在創建FaceBook或Google地圖等獨特應用程序ID。獨特的應用程序密鑰
開發人員必須提交用戶名和電子郵件地址，當他們點擊生成一個唯一的密鑰將被生成。問題是，如果用戶/電子郵件已存在，則必須先檢查數據庫，並檢查密鑰是否已生成（僞隨機生成保護）。
要使用Web服務的用戶必須輸入類似：
webservice.Authenticate（「在這裏應用的關鍵」）;
進行驗證。提前致謝。
據我所知Guid.NewGuid()應該足夠了。
是的，我只是做了一些更多的閱讀，發現這種方法很有用。做了一段時間的循環，併產生了大約20磨，仍然沒有得到衝突 – ferronrsmith
@ferronrsmith：你可能需要讓這個循環運行幾百年，然後才能達到衝突的統計可能性。 – LukeH
大聲笑圖那麼多。謝謝你笑的人:) – ferronrsmith
典型的身份驗證包括身份（名稱）和密碼（密碼）。您正在設計一個僅包含祕密的認證方案，即。密碼（以guid的形式）。這種方法的問題（即不能將身份與密碼分離）是因爲密碼是他們的身份，所以用戶不能更改密碼。
什麼Maps API密鑰和類似的密鑰是別的：它們是由服務提供商簽署的聲明。例如您的應用調用Maps API的註冊域。 Generate鍵接受您提交的域名，將使用服務的私鑰簽署該域名，並向您顯示publis簽名。訪問API時，您必須出示已簽署並同意服務條款的簽名（API密鑰）。驗證的另一部分（您的應用運行的域，換言之，'聲明'）會被JavaScript自動檢測到。
我絕不是地圖API的專家，我可能已經得到了一些部分，但這通常是如何實現的。我建議不要使用guid作爲模糊的應用程序ID，因爲它沒有提供太多價值：任何人都可以使用泄露的guid，並且您無法使用guid驗證任何聲明。想想你想要保護什麼，或者只是使用像OpenId這樣的已建立的方案。
@Remus Rusanu生成的GUID密鑰將與人的姓名，電子郵件（如果我們希望的話，域名一起）放入數據庫中。當用戶試圖檢索信息時，數據庫中的數據即GUID將被驗證。我打算寫一個存儲過程進行進一步的加密（沒有太多極端）。存儲在數據庫中的值將與域一起檢查，如果這些值不匹配，則返回空值。簡單。它沒有任何進展，只是在我周圍有些鬼混，有些朋友在學校開始回來。反正謝謝 – ferronrsmith
從鹽，用戶名和電子郵件地址中創建一個字符串。然後從該字符串中創建一個散列（MD5或SHA1）。鹽可以簡單地用作用途，或者可以是其他用途，只要用戶不知道。
GUID很好，但在這種情況下它可能是矯枉過正的。你會有數十億用戶嗎？你可能會得到1到1000000之間的隨機數。然後確保在x次嘗試失敗後禁用登錄，其中x在3和6之間。
億的用戶，LOL。最多它將是約20萬 – ferronrsmith
根據您的應用程序的大小和用戶數量，Guid可能不是最好的選擇，除非您知道如何處理它們。大多數情況下，我已經將這些用作字符串，這隻會增加您的存儲需求並減慢您的比較例程。匹配的guid的字符串比較必須掃描全部36個字符。對於剛剛以十六進制格式存儲的數據而言，這種方法過於誇張。最好將GUID保存爲一個整數數組...您在減少搜索的同時減少了存儲需求。
如果您只有幾千條記錄，那麼guid作爲字符串可能不會有太大影響。但是，如果你的編程規模很大，而且規模很大，那麼現在進行適當的調整將會爲你節省以後做的痛苦。
如果您正在進行表連接，請使用整數標識進行連接，而不是guid（出於前面提及的相同原因）。
最多我會有大約20萬。當時我正在考慮將它們保存爲一個整數數組，但是究竟是什麼。這不是那麼多記錄，如果需要，我可以隨時改變例程 – ferronrsmith
我在看GUID的一代。它真的是獨一無二的嗎？還是它是一個隨機數？ – ferronrsmith
你到底需要什麼幫助？這聽起來像你有一個很好的計劃... –
GUID幾乎是真正獨特的。好的，所以你可能會碰到一個衝突，但是這個機會很小，它真的不值得考慮，如果你擔心衝突，嘗試再創建一個Guid，然後再試一次（如果你有兩次衝突連續，用您的日誌數據寫入Microsoft）。我們從一臺服務器上獲得了數百萬個Guids，並且從未發生衝突。 –