关于用户名/密码与秘密 URL 的安全问题答案

【问题标题】：Security concerns regarding username / password vs secret URL关于用户名/密码与秘密 URL 的安全问题
【发布时间】：2011-09-28 13:39:31
【问题描述】：

我有一个带有注册表单的简单网站。目前，用户可以通过个人（秘密）URL 使用注册时不可用的（非关键、“低安全性”）信息来补充他们的注册。

即，一旦他们点击提交，他们就会收到如下消息：

感谢您的注册。您可以通过此个人 URL 添加信息补充您的注册：

http://www.example.com/extra_info/cwm8iue2gi

现在，我的客户要求我扩展应用程序以允许用户完全更改他们的注册，包括更敏感的信息，例如帐单地址等。

我的问题：使用秘密网址而不是完整的用户名/密码系统是否存在任何安全问题？

我能想到的唯一问题是 URL 存储在浏览器历史记录中。不过，这并不让我担心。我错过了什么吗？

如果有人更改了其他用户的注册信息，这不是世界末日。（这只会涉及一些额外的体力劳动。）我不会为这个应用程序设置 https 的范围。

【问题讨论】：

【解决方案1】：

此方法不适用于敏感信息，因为它是 HTTP 请求 URL 的一部分，未加密并显示在代理和其他服务器日志等许多地方。 ~~即使使用 HTTPS，您也无法加密这部分负载，因此它不是传递令牌的合适方式。~~

顺便说一句，这个方案的另一个问题是，如果您通过电子邮件将 URL 发送给用户。这为攻击开辟了更多途径。

更好的方案需要一些电子邮件中没有的小秘密。但要决定这个秘密应该是什么可能具有挑战性。通常答案是：密码。

【讨论】：

1) 使用 HTTP 时，用户名/密码也以明文形式发送，所以我敢打赌它会出现在 URL 出现的大多数地方。 2）如果我确实使用了HTTPS，我相信URL也会被加密。
1) 不正确。 URL 在访问日志中，包括代理访问日志。 HTTP 数据包是瞬态的。 2）你是对的；固定。

【解决方案2】：

另一个潜在的问题在于用户本身。大多数人意识到密码是他们应该尝试保护的东西。但是，有多少用户可能认识到他们应该采取某种措施来保护您的秘密 URL？

【讨论】：

是的。我已经认识到这种担忧，并在处理他们的个人地址时特别小心地告诉用户这一点……不过，这点很好。 +1
不幸的是，他们不太可能阅读和/或理解该信息。
不幸的是，情况可能并非如此。用户通常会忽略和/或几乎不浏览 UI 中呈现给他们的消息。你可以敲一个大的、闪烁的、红色的“重要”，他们仍然会忽略它，特别是如果它很长的话。您最好坚持使用大多数用户已经了解的保护范例。如果他们想添加额外信息，请为他们提供一种身份验证方式以保护该信息。
好的。不过，我对技术方面更感兴趣......无论如何，谢谢。

【解决方案3】：

这里的问题是，虽然很难猜出任何特定用户的 URL，但如果有足够的用户，猜出某些用户的正确 URL 相对容易。

这将是 birthday attack 的经典示例。

ETA：错过了关于秘密大小的部分，所以这并不真正适用于您的情况，但会在此处留下答案，因为它可能适用于更一般的情况。

【讨论】：

我可以轻松确保 URL 与用户名/密码的任意组合具有相同的“熵”。即，“生日攻击”同样适用于用户名密码，不是吗？
只有在空间不稀疏时才适用。他有一个 51 位的空间（大约 3 万亿次可能性）。如果地球上的每个人都有一个 URL，那么他正在使用大约 0.00016% 的空间。那是相当稀疏的。然后的问题是你可以多快蛮力，但是通过添加更多位可以轻松解决这部分问题。这仍然是一个糟糕的解决方案，但不是因为暴力攻击。这很糟糕，因为 HTTP。
@aioobe：正确。用户名+密码只是一个更长的令牌，每比特的熵更少。如果用户名是已知的，你的令牌比用户名+密码有更多的熵，如果用户名是非随机的，则几乎一样多。
@RobNapier，示例网址只是……一个示例。我的应用程序中有更多“秘密”字符。

【解决方案4】：

可以用（非关键、“低安全性”）信息补充他们的注册

很难想象用户提供的信息究竟是什么“低安全性”；即使您要求客户提供密码和用户名，您也可能违反了对客户的注意义务；大量用户将在多个站点上使用相同的用户名/密码。第三方可以使用有关您的用户的任何信息以及可能的大量有关交易的信息来破坏该用户的身份。

应以加密格式（例如通过 https）提供有关用户的任何信息。并且您应该采取适当的措施来保护您存储的数据（例如散列密码）。

您使用秘密 URL 的想法，意味着只有您，用户，与用户在同一网络上的任何人，在 wifi 上的用户附近，连接到您和用户之间的任何网络，或者拥有访问用户硬件会知道 URL。当然，这还没有考虑到有人尝试对 URL 进行暴力攻击的可能性。

C.

【讨论】：

【解决方案5】：

如果您不使用 SSL，秘密 URL 将毫无意义。如果您仍然让最终用户在互联网上以明文方式传输他们的识别信息，那么您如何让他们进入并不重要：他们仍然暴露在外。

【讨论】：

所以你是说如果在 HTTP 上使用秘密 url 和登录表单一样（不）安全？
是的。他们阻止了随意的“黑客”，但这通常不是我们担心的人。互联网安全取决于加密。默默无闻只会带你走这么远。 SSL 证书既便宜又易于安装，确实没有充分的理由不使用 SSL 进行身份验证和保护个人信息。

【解决方案6】：

“秘密 URL”通常被称为安全性。问题是编写一个脚本来尝试各种字母、符号和数字的组合来蛮力破解这个方案非常简单。

因此，如果存储了任何敏感信息，您绝对应该至少使用用户名和密码来保护它。

【讨论】：

虽然我同意这个特定的方案不好，但这并不是因为它晦涩难懂。该页面由大约 51 位的机密保护（假设它是 10 个小写字母加数字）。这与用户名和密码没有根本区别，尤其是在用户名众所周知的情况下。由于 HTTP 的工作方式，这仍然不是一个好方法，但问题不在于“秘密 URL”。用“令牌”或“自动生成的密码”替换“秘密 URL”，这才是真正的意思。您的蛮力方法同样适用于密码。
同意抢。我没有这么认为。