rest - 散列已知纯文本的危险

Question

我有很容易猜到的内部标识符(自动递增的数字)，我想让我的客户根据这些标识符访问资源。

因为我不能向他们提供像这样的 URL:

https://example.com/order/13

因为他们很容易猜到如何从此 URL 访问订单 #14。

因此，我考虑为他们提供标识符的加盐散列，例如:

https://example.com/order/4643ef…

在哪里

4643ef… = sha256(13 + 'supersecretsalt')

从安全角度来看，这是一种好方法吗？

Answer 1

首先，您不应该仅根据 uri 授予对任何资源的访问权限。换句话说，用户 A 不应该能够访问属于用户 B 的资源，即使他知道相关的 uri。为了缓解这种情况，您应该在允许访问任何( secret ？)资源之前添加某种形式的身份验证和授权。

也就是说，如果您仍然想混淆 uri，您可以使用 GUID为此，而不是生成任何类型的哈希。相反，对于每个订单 ID，只需将一个 GUID 与其一起存储，然后在 URL 中使用该 GUID 时查找该 ID。

---

旁注:如果您确实想让您的客户仅根据 url(即不需要身份证明)来查找一些订单详细信息，您至少可以资源的可用性是临时的。您可以通过存储例如有效期至 - 与 GUID 一起。

现在用户 A 将能够通过带有 guid 的 url 查看与其资源相关的信息，但可能仅限于例如3天。其他用户也可以访问它，但这种情况发生的可能性较小，因为很难猜测 GUID，而且他们只有 3 天的时间来这样做。

如果用户 A 以后需要再次访问他的资源，也许您可​​以提供一种方法来扩展 GUID 的有效性，或者只是提供一个指向同一资源的新 GUID，但是具有不同的有效期。

显然，您需要考虑这对于您的特定情况和安全需求是否现实/可接受。