我需要創建一個令牌以顯示在查詢字符串中，該查詢字符串可以傳遞到網頁並進行解碼以便在數據庫視圖中查找記錄。sql服務器中的查詢字符串加密
令牌不應該容易受到暴力增值類型攻擊的影響。
在數據庫中查看記錄被唯一定義爲兩個鍵的組合。
該令牌的生成需要在數據庫和按需發生。數據庫由另一個系統直接訪問，該系統利用視圖中的數據生成電子郵件。
我試圖產生基於兩個密鑰的SHA1哈希值，然後URL編碼的結果安全base64，但由於它是一個單向操作在web端的查找是慢得不可接受。
我覺得作爲發生在數據庫的加密，並且發生在網站解密，查找之前的對稱密鑰加密將是合適的，因爲長。
在這個階段我傾向於建立一個CLR函數來填充視圖生成列。
我已經結束了編寫使用三重DES加密包含我所需要的密鑰的鹹魚連接字符串一個CLR函數。該功能用於視圖上的計算列。
我用這個頁面作爲三重DES代碼的基礎： http://www.dotnetspark.com/kb/1279-triple-des-encryption-and-decryption-using.aspx
它的高性能和安全的，但更多的工作比我想是在大多數情況下必要的。
所以，你希望數據庫生成「令牌」，將該值傳遞出來的應用程序（網絡/互聯網），以後用戶將返回令牌和數據庫將主要使用它作爲查找/主鍵值？而且您希望生成的值能夠讓黑客（我們的朋友Mallory）無法（a）猜測特定帳戶的令牌和/或（b）爲某個帳戶猜測任何有效令牌？
爲什麼不把它作爲一個隨機數？一個4字節的值爲您提供了40億個值，8個字節爲您提供了4 PB的值（2^64），並且它不斷上升。不可否認的是，你有一個古老的問題產生一個真正的隨機數（Maybe try these guys?），你需要測量可能的標記與有效標記的比率與蠻力攻擊需要猜測它們需要多長時間，但是你會得到具有任何安全性。
我的問題是，爲什麼用哈希和加密打擾，如果你傳遞出的數據僅僅是一個查找鍵？
隨機數是一個好主意，只要它足夠大以避免衝突，但由於數據在視圖中而不是表中，因此它實際上並不存在。爲了使用一個隨機數，我需要有一個基於視圖數據的真實表。由於視圖包含交叉連接，因此會導致數據爆炸。 – aboy021 2010-01-13 21:18:58
你的問題是什麼？ – 2010-01-13 02:33:28
當跨視圖中的兩列存在定義數據時，如何在sql server中創建持久的，防入侵的，安全的url標記？ – aboy021 2010-01-13 21:22:19