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

#1 楼

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

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

出于这个原因，专用URL通常仅用于一次性操作，例如密码重置，并且通常仅在有限的时间内有效。


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

#2 楼

注意：
很多人似乎将“私有” URL与身份验证混淆了。同样，似乎有些混乱，认为通过受信任实体发送链接是对两因素身份验证的尝试。明确地说，我们正在谈论的是一种可公开访问的资源，尽管这是一个很难猜到的资源。
使用私有URL时，您应始终假定它会受到危害-您应设计这样的URL因此即使资源遭到破坏，资源也不会向攻击者泄漏信息。

私有/难以猜测的URL不等同于基于密码的身份验证。从本质上讲，私有URL根本不是私有的-它们是可公开访问的资源。我认为“专用” URL一词是用词不当，而是“晦涩”的URL。
在某些情况下，使用“专用” URL是可以接受的，但是它们本质上不如传统的身份验证方法安全。作为密码身份验证或基于密钥的身份验证。
我经常看到的一些使用“私有” URL的地方是：

密码重置电子邮件
证书生成电子邮件
>帐户/电子邮件确认电子邮件
交付购买的内容（电子书等）
其他杂项，例如登机手续，打印登机牌，使用私人URL以及传统身份验证

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

正如罗伯特·哈维（Robert Harvey）指出的那样，安全使用随机/私有URL的一种方法是动态生成页面，并以某种方式将URL提交给用户，以便可以将用户视为半认证用户。这可能是电子邮件，SMS等。
随机生成的/私有URL通常具有一些属性：

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

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

#3 楼

几乎所有身份验证方案都可以归结为证明您知道秘密。您可以通过证明自己知道秘密密码或秘密URL或其他一些高级协议（例如OAUTH，Kerberos等）来对自己的服务进行身份验证。证明您知道秘密而不实际传送秘密。这很重要，因为除了猜测外，还有更多的方法可以获取“无法使用的”秘密。

我可能和自己坐在同一家网吧，当您键入“难以置信的网址”。那时，如果您不使用SSL，或者如果我可以利用SSL实施中的最新错误，那么我也会知道您的秘密。

#4 楼

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


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


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

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

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

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

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

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

#5 楼

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

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

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

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

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

#6 楼

在任何地方都没有注意到的另一个项目是“猜测”的节流。对于大多数密码身份验证系统，在锁定或限制进一步的身份验证尝试之前，您会尝试进行有限次数的猜测，以猜测用户的密码。

虽然可以用“猜测”做类似的事情反对您的URL方案，将很难实施。如果您的URL生成有可识别的模式，那么可能很难阻止某人进行设置以在您的“随机” URL空间中进行工作。

#7 楼

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

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

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

然后，让我们假设有人在Google URL缩短器上共享了此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-six-characters -短网址认为对云服务有害/