2012-07-28 44 views
0

我需要一種方法來以防止抓取/抓取項目的方式將我的物品ID傳輸到瀏覽器。使用祕密和共享的鹽加密整數

我的想法是使用祕密和共享salt加密整數ID。這允許大量永久但不可預知的URL用於同一個唯一項目。假設我需要傳送的記錄1和2的結果,而不是發送的ID中明確:

string RESULT_SET_SALT = "randomValue1"; 
foreach(ResultItem item in results) { 
    item.id = encrypt(SECRET, RESULT_SET_SALT, id); 
} 

實際發送內容:

{ 
    1: "Item One", 
    2: "Item Two" 
} 

我先在web服務器加密的ID到客戶端是鹽和加密值:

{ 
    RESULT_SET_SALT: "randomValue1", 
    387439: "Item One", 
    79: "Item Two" 
} 

當客戶端選擇一個項目,以查看細節,AJAX請求包括鹽和加密值。

$.get("/ItemDetails/387439?RESULT_SET_SALT=randomValue1"); 

在服務器上,ID使用SECRET和SALT解密請求中包含的客戶端。

int actualRequestedId = decrypt(387439, "randomValue1", SECRET); // result is 1 

這是信息:Simple integer encryption 這:Way to encrypt a single int

有關使用鹽也不文章會談。也許,如果我將祕密分成兩部分並傳輸一半,沒有人會努力破解它,但我知道算法的濫用類型往往會破壞它,我寧願正確地做到這一點。

有什麼建議嗎?沒有必要將ID保持爲int,但是我將傳輸大量的ID,並且需要將它們保持爲小。由於會有大量的ID並且加密過程會阻止結果UI,因此它不應該太昂貴。這將是很好,如果這槓桿開箱即用的.NET(C#)加密

編輯:它發生在我身上,另一個(更高的帶寬)方法是爲每個ID添加一個隨機的高32位並用祕密進行加密,而不是使用鹽。如果這是另一種算法濫用,用戶使用相同ID生成多次迭代的能力可能會危及祕密(或者不那麼重要的是個人ID),那麼這將會很好。

+0

您應該檢查[格式保留加密](http://en.wikipedia.org/wiki/Format-preserving_encryption)。你找不到任何有關鹽的原因是加密不使用鹽。它可以使用IV或NONCE,但鹽通常用於密鑰派生函數。 – 2012-07-28 11:54:26

+0

感謝您對鹽的澄清。 – shannon 2012-07-29 03:34:50

+0

我不知道它是否會達到相同的結果,簡單地在ID上執行一些非祕密操作,基於與每個響應相關的祕密(加密和與響應一起發送以及相關的詳細請求,或存儲在服務器會話狀態)。我並不需要加密數字。所以只需添加或XOR他們的ID。 – shannon 2012-07-29 03:42:55

回答

1

保留加密格式可能是您正在尋找的東西,但實現起來並不容易。您可以使用鏈接到服務器會話的隨機密鑰。攻擊者可以簡單地請求所有值,但不能猜出它們。

CTR密碼可以加密任何值並返回相同的大小(以位爲單位)。它們具有更好的可用性(在API中),但是對於使用相同密鑰的每次加密,它們都需要NONCE。

或者,您可以簡單地在服務器上保留一張桌子,並記住隨機ID到項目ID。這樣攻擊者根本無法檢索除了通過服務器提交給他的任何東西。這可能比其他解決方案容易得多,但它需要額外的表格內存(當然)。

這除了在其他鏈接提交的答案。

+0

我喜歡在服務器會話密鑰中使用隨機密鑰的想法,但我也不喜歡它。到目前爲止,我已經能夠完全避免會話(沒有客戶端鏈接狀態)。我想對每個響應加密/傳輸一個隨機對稱密鑰也是一樣的。我拍攝的另一個功能是獨特項目的URL的非唯一性(細節/ 987343和細節/ 12392可能會返回相同的項目)。我意識到,以明文形式分離salt並不會提供這個...正如你所說的,只是迭代所有加密的ID。雖然,由於大多數不會存在,但實際上每日配額將擊敗這一點。 – shannon 2012-07-29 03:26:40

+0

另外,它不僅僅是在服務器上有更多的內存來將ID映射到隨機ID。這意味着地圖會保留在我的數據庫中,或者無法跨服務器或應用程序重新啓動。我仍然在處理你的答案,並且可能會接受它,儘管我的架構可能是真正的約束。我想我可以有一個獨立的電子郵件半持久性項目URL的機制,他們只會有一個到期日期。 – shannon 2012-07-29 03:33:43

+0

感謝您的幫助,我接受此答案並從另一個角度發佈問題。 – shannon 2012-07-29 03:38:45