【问题标题】:Encrypt integer with a secret and shared salt使用秘密和共享盐加密整数
【发布时间】:2012-07-28 04:20:36
【问题描述】:

我需要一种方法将我的项目 ID 传输到浏览器,以防止对项目进行爬取/爬取。

我的想法是使用秘密和共享盐来加密整数 ID。这允许同一唯一项目有大量永久但不可预测的 URL。假设我需要传输记录 1 和 2 的结果。而不是明文传输 ID:

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

我将首先在网络服务器上加密 ID:

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

实际传输给客户端的是盐值和加密值:

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

当客户端选择一个item查看详情时,AJAX请求包含salt和加密值。

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

在服务器上,使用请求中包含的客户端的 SECRET 和 SALT 对 ID 进行解密。

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

这是信息:Simple integer encryption 还有这个:Way to encrypt a single int

这两篇文章都没有谈到使用盐。可能,如果我只是将秘密分成两部分并传输一半,没有人会努力破解它,但我知道滥用算法经常会破坏它,我更愿意正确地做到这一点.

有什么建议吗?没有必要将 ID 保持为 int,但我将大量传输它们,并且确实需要保持它们很小。由于会有大量的 ID 并且加密过程会阻塞结果 UI,所以它应该不会太昂贵。如果这利用了开箱即用的 .NET (C#) 加密,那就太好了

编辑:在我看来,另一种(更高带宽)方法是向每个 ID 添加一个随机的高 32 位并使用密钥对其进行加密,而不是使用盐。这会很好用,除非这是对算法的另一种滥用,用户从同一个 ID 生成多次迭代的能力很可能会危及秘密(或者不太重要的是个人 ID)。

【问题讨论】:

  • 你应该检查format preserving encryption。您找不到任何有关盐的信息的原因是加密不使用盐。它可以使用 IV 或 NONCE,但盐通常用于密钥派生函数。
  • 感谢您对盐的澄清。
  • 我想知道基于与每个响应相关联的秘密(加密并与响应和相关请求一起发送)简单地对 ID 执行一些非秘密操作是否会达到相同的结果 -详细信息,或存储在服务器会话状态中)。我真的不需要加密数字。所以只需将它们添加或异或到 ID。
  • 在这种情况下,加密似乎并不是唯一可能的答案。如果它存在,它应该是一个经过深思熟虑的方案的一部分。加密不是魔法(不幸的是,它会让我成为魔术师 :))。

标签: .net encryption


【解决方案1】:

格式保留加密可能是您正在寻找的东西,但实现起来并不容易。您可以使用链接到服务器上的会话的随机密钥。攻击者可以简单地请求所有值,但无法猜测它们。

CTR 密码可以加密任何值并返回相同的大小(以位为单位)。它们具有更好的可用性(在 API 中),但它们需要使用相同密钥的每次加密都有一个 NONCE。

或者,您可以简单地在服务器上保留一个表并记住一个随机 ID 到项目 ID。这样,攻击者除了通过服务器提交给他的项目外,根本无法检索任何东西。这可能比其他解决方案容易得多,但它需要额外的表内存(当然)。

这除了在其他链接中提交的答案。

【讨论】:

  • 我喜欢在服务器会话密钥中使用随机密钥的想法,但我也不喜欢它。到目前为止,我已经能够完全避免会话(没有客户端链接状态)。我想为每个响应加密/传输随机对称密钥也是如此。我正在拍摄的另一个功能是唯一项目的 URL 的非唯一性(detail/987343 和 detail/12392 可能返回相同的项目)。我意识到以明文形式分离盐并不能提供此功能……正如您所说,只需迭代所有加密的 ID。虽然,由于大多数都不存在,但实际上每日配额会打败这一点。
  • 另外,在服务器上拥有从 ID 到随机 ID 的内存映射不仅仅是更多的内存。这意味着地图要么保留在我的数据库中,要么跨服务器无效或应用程序重新启动。我仍在处理您的答案,并且可能会接受它,尽管我的架构可能是真正的限制。我想我可以有一个单独的机制来通过电子邮件发送半永久项目 URL,它们只有一个到期日期。
  • 感谢您的帮助,我接受这个答案并从另一个角度发布问题。
  • 这是我的后续问题:stackoverflow.com/questions/11706613/…
猜你喜欢
  • 2012-07-07
  • 1970-01-01
  • 2016-09-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-02-28
  • 2014-11-30
  • 1970-01-01
相关资源
最近更新 更多