4

我只是在考虑我当前 Web 项目的 URL。用户可以访问不同的资源，例如使用网站的图像。URL 看起来像这样http://localhost:2143/p/AyuducjPnfnjZGfnNdpAIumehLiWaYQKbZLMeACUqgsYJfsqarTnDMRbwkIxWuDd

现在，我真的需要高性能，一种方法可能是省略额外的往返数据库进行身份验证，只依靠 URL 来猜测。

Google 使用Picasa 网络相册执行此操作，您可以将相册设为私有或不公开。这可以保护相册，但不能保护照片本身。拍这张斯卡恩（丹麦）的照片；http://lh4.ggpht.com/_Um1gIFFfF614/TQpVMvN3hPI/AAAAAAAANRs/GY5DxrDPHUE/s800/IMG_4074.JPG，其实是在私人相册里，不过大家都能看到。

那么您对此有何看法？一个 64 字符长的随机字符串是否足够“安全”？还有其他方法吗？

假设我选择对资源的每个请求进行身份验证。用户已经登录到 somedomain.com 上的站点，在那里他们可以访问他们的相册，比如说相册。丢弃 cookie 以维持其身份验证。

现在，实际照片是通过某种形式的 CDN 或存储服务在完全不同的 URL 上提供的。

您将如何跨多个域维护身份验证？假设两个专辑的内容可以从不同的服务器传送。

4

5 回答 5

5

算一算。从 62 个可能值（26+26+10：大写/小写/数字）的字母表中以加密方式随机选择的 64 个字符（不是 rand()！）将产生 5.16e+114 个可能值 (62^64)。每秒尝试一百万个组合，猜密码需要 1.63e+101 年（比 googol 更糟）。它可能已经足够好了。一个较短的可能也很不错。

于 2010-12-16T18:21:02.467 回答
1

64 个字符 * 每个 6 位熵（Base-64 编码，对吗？）是 384 位密钥。如果可以离线测试密钥，那么按照今天的标准，这将被认为是相当弱的。只要密钥只能使用您的实时系统进行测试，它可能会非常有效，您还可以添加主动对策来阻止尝试许多坏密钥的客户端。

密钥通过服务器日志、浏览器日志、引用标头、透明代理等公开的风险可能要高得多。

于 2010-12-16T18:25:27.380 回答
0

仅使用“不可猜测”的 URL 肯定存在风险。这实际上取决于您要保护的内容类型。以 picasa 为例，它们是受保护的照片，而不是银行记录，因此可以使用随机查询字符串。另外，您的网站越大，您打开的攻击面就越大。如果只有一个页面是一回事，可能需要进行相当多的扫描才能尝试找出正在使用的单个 URL。但是，如果您有数十万个这样的页面，那么攻击者更有可能“猜出”正确的页面。

所以，我真的没有给你答案，只是关于“不可猜测”的 url 方法的一些建议：不要这样做。它不安全。

干杯，

于 2010-12-16T18:19:00.767 回答
0

没有不可猜测的 URL，即使您第一次通过非 SSL 连接使用它，任何人、ISP 和代理、缓存等都可以看到它。你真的希望您的用户/客户相信他们的私人照片“不可猜测”？

使 URL 不可猜测并不是一种很好的安全方法，除非您的唯一 URL 对其有用性有时间限制（例如，它们是短暂的 URL）

于 2010-12-16T18:21:23.757 回答
0

这是我的 2 美分。我有类似的问题。我们最初的方法是使用随机但唯一的名称重命名文件，并使用该名称的复杂密钥进行双向加密。但事情最终归结为这样一个事实，即一旦 URL 到了某人的手中，你就无法保证这些东西的隐私。我们最终采用了基于数据库的身份验证路由。看这里

编辑#1：关于 CDN 问题，我不确定解决方案是什么。但即使马尔托纳所说的是正确的。CDN 的目的之一是减少主服务器的负载，并且为每个资源 ping 回服务器可能不是一个好主意。

于 2010-12-16T18:28:35.217 回答