私有的，不可猜测的URL是否等于基于密码的身份验证？

我想在网络上公开资源。我想保护此资源：确保只有某些个人可以访问它。

我可以设置某种基于密码的身份验证。例如，我只能允许在提供文件之前通过Web服务器访问资源，该Web服务器检查传入的请求以获取正确的凭据（可能针对用户的某些后备数据库）。

或者，我可以只使用私有URL。就是说，我可以简单地将资源托管在一些无法猜到的路径上，例如https://example.com/23idcojj20ijf...，它将访问权限限制为知道确切字符串的用户。

从想访问此资源的邪恶者的角度来看，这些方法是否等效？如果没有，是什么使它们与众不同？就可维护性而言，在实施一种或另一种方法之前，我应该意识到这两种方法的优缺点吗？

即使URL的位大小与凭据的位大小相同，私有URL也比使用凭据的身份验证弱一些。原因是URL可能更容易“泄漏”。它被缓存在浏览器中，登录在服务器上，依此类推。如果您有出站链接，则专用URL可能会显示在其他站点的引荐来源标头中。（也可以通过看着您的肩膀的人看到。）

如果它泄漏（偶然或由于用户的粗心大意），它可能最终被公开，甚至被Google编入索引，这将使攻击者可以轻松地搜索所有泄漏到您网站的URL！

因此，私有URL通常仅用于一次操作，例如密码重置，并且通常仅在有限的时间内有效。

信息安全中有一个相关主题：随机URL是保护个人资料照片的安全方法吗？-一个答案可以解决这个问题：在Google退税后，Dropbox会禁用旧的共享链接。因此，这不仅仅是理论上的风险。

注意：

很多人似乎将“私有” URL与身份验证混淆了。同样，似乎有些困惑，认为通过可信实体发送链接是对两因素身份验证的尝试。明确地说，我们正在谈论的是一种可公开访问的资源，尽管这种资源很难猜测。

使用私有URL时，应始终假定它会遭到破坏-您应设计这样的URL，以便即使受到破坏，该资源也不会将信息泄漏给攻击者。

专用/难以猜测的URL不等同于基于密码的身份验证。从本质上讲，私有URL根本不是私有的-它们是可公开访问的资源。我认为“私有” URL一词用词不当，而是“晦涩”的URL。

在某些情况下，使用“私有” URL是可以接受的，但是它们本质上不如诸如密码认证或基于密钥的认证之类的传统认证方法安全。

我经常看到的一些使用“私有” URL的地方是：

1. 密码重置电子邮件
2. 证书生成电子邮件
3. 帐户/电子邮件确认电子邮件
4. 交付购买的内容（电子书等）
5. 其他杂项，例如航班办理登机手续，打印登机牌，除传统身份验证外，还使用私有URL

这里的共同点是随机URL通常仅适合一次操作。此外，传统的身份验证和随机URL 也不互斥 -实际上，它们可以相互结合使用，以在交付资源时提供额外的安全性。

正如罗伯特·哈维（Robert Harvey）所指出的那样，安全地使用随机/私有URL的唯一方法是动态生成页面并以某种方式将URL提交给用户，从而可以认为用户是半认证的。这可能是电子邮件，短信等。

随机生成的/私有URL通常具有一些属性：

1. 它应该在合理的时间后过期
2. 它应该是一次性URL：IE，它应该在第一次访问后过期。
3. 它应该将用户的身份验证推迟到它信任的其他一些实体，以安全地对用户进行身份验证。（通过电子邮件或短信等发送链接）
4. 现代计算机不可能在到期前的时间范围内强行使用URL-通过限制暴露资源的API的速率或创建具有足够熵的url端点以致无法猜测它。
5. 它不应泄漏有关用户的信息。IE：如果该页面要重置密码：该页面不应显示请求者的帐户信息。如果爱丽丝请求密码重置链接，而鲍勃以某种方式猜出了该URL，则鲍勃应该无法知道他正在重置谁的密码。
6. 如果确实泄漏了有关用户的信息，则应在传统身份验证的基础上使用它，例如，如果页面设置了cookie或session_id仍然有效，则页面可能会认为用户已通过身份验证。

不同的资源需要不同的安全级别。例如，如果您想与一些朋友共享秘密食谱，则可以使用随机/私有URL与他们共享。但是，如果该资源可用于窃取某人的身份或损害他们在其他服务提供商处的帐户，则您可能会更关心限制对该资源的访问。

几乎所有身份验证方案都可以归结为证明您知道秘密。您通过证明知道秘密密码，秘密URL或...来验证您对某些服务的身份。

一些更高级的协议（例如OAUTH，Kerberos等）使您能够证明自己知道秘密，而无需实际传输秘密。这很重要，因为除了猜测之外，还有更多的方法可以获取“无法使用的”秘密。

我可能和您坐在同一家网吧，当您键入“无法使用的” URL时，就在窃听您的WiFi连接。到那时，如果您没有使用SSL，或者如果我可以利用SSL实施中的最新错误，那么我也将知道您的秘密。

这个线程中已经有很多好的答案，但是直接解决这个问题：

从想访问此资源的邪恶者的角度来看，这些方法是否等效？如果没有，是什么使它们与众不同？

让我建立一个定义。“认证”是提供凭证以证明对身份的要求。访问控制通常基于用户的标识。

您的秘密URL未绑定到特定用户。正如其他人指出的那样，它可能最终会存储在代理的日志文件中，或者最终被Google索引为搜索请求，或者可能以其他方式泄漏出去。

另一方面，密码与唯一的用户帐户绑定。您可以重置它，或仅允许将其用于用户的家庭位置，已知的IP地址或任意数量的其他控件。

用户名/密码使您可以更精细地控制访问。

访问控制允许身份（主题）访问资源（对象）。在您的URL示例中，身份是“通过任何方式获得URL的任何人”。

如果可以，请输入用户名/密码。随着时间的推移，URL会以各种意外的方式泄漏出去。

秘密URL与秘密密码一样安全。但是，密码比URL更容易保密，因为每个人及其程序都知道密码必须保密。

例如，您的浏览器将不会在屏幕上显示密码，仅在您允许的情况下存储密码，并提供保护该密码存储（例如，由主密码解锁的加密存储）的手段。相反，它将始终在屏幕上显示URL，可能会通过引荐来源标头泄漏URL，并在没有任何进一步保护的情况下将它们自动存储在浏览历史记录中。

同样，HTTP代理通常不会记录密码，而URL通常会被记录。

使用URL进行身份验证还意味着共享URL共享身份验证，这使得很难单独撤消（或记录）访问。

当然，秘密URL会继承秘密密码的所有弱点。特别是，使用密码进行身份验证会将密码泄露给服务器以及任何能够读取您的通信的人。

另一个没有提到的项目是“猜测”的节流。对于大多数密码身份验证系统，在锁定或限制进一步的身份验证尝试之前，您会获得有限次数的尝试来猜测用户的密码。

尽管您可以针对URL方案对“猜测”执行类似的操作，但要实现起来有些困难。如果您的URL生成有可识别的模式，那么可能很难阻止某人进行设置以在您的“随机” URL空间中进行工作。

还有一个我还没有提到的方面-URL缩短器。

在最近的出版物（2016年4月）中，声称URL缩短服务完全抵消了随机生成的“无法使用的” URL所提供的增强的安全性。较短的服务的URL空间比您随机生成的URL小得多，这意味着与较短的服务共享的任何此类“安全” URL都可以以比预期容易的方式进行猜测。

为了说明-假设您的随机URL长128位（即GUID）。另外，我们假设您的随机数生成器确实很强大，并且您以统一的方式生成这些位。猜测128位数字非常困难，并且可能需要花费大量时间-您的URL实际上受到128位密钥的保护。

然后，假设有人在Google URL Shortener上共享了该URL。今天，该服务会发出一个由10个字符组成的ID，由字母和数字组成。（26 + 10）^ 10〜= 3.6 * 10 ^ 15 <2 ^ 52-因此，我们已经将密钥强度从128位有效地减半了至52位。

此外，由于其他考虑因素，生成器不会占用整个空间，因此您可以发起有效的攻击，将蛮力与旁通道结合在一起（最有可能预分配的随机URL缓冲区）。

原始文章：http : //arxiv.org/pdf/1604.02734v1.pdf
一篇总结文章的博客文章（作者）：https : //freedom-to-tinker.com/blog/vitaly/gone-in-六个字符的短网址被认为对云服务有害/