有关用户名/密码与秘密URL的安全问题

时间:2011-09-28 13:39:32

标签: security web password-protection

我有一个带注册表单的简单网站。目前,用户可以通过个人(秘密)URL补充他们在注册时无法获得的(非关键,“低安全性”)信息。

即,一旦他们点击提交,他们会收到如下消息:

  

感谢您注册。您可以通过以下个人网址添加信息来补充您的注册:

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

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

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

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

如果有人更改其他用户注册信息,那么这不是世界末日。 (这只需要一些额外的手工劳动。)我不会为这个应用程序设置https。

6 个答案:

答案 0 :(得分:2)

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

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

更好的方案需要一些不在电子邮件中的小秘密。但是,确定应该是什么秘密可能具有挑战性。通常答案是:密码。

答案 1 :(得分:2)

另一个潜在的问题在于用户自己。大多数人都意识到密码是他们应该尝试保护的东西。但是,有多少用户可能会认识到他们应该采取某种措施来保护您的秘密网址?

答案 2 :(得分:1)

这里的问题是虽然很难猜出任何特定用户的URL,但是如果有足够的用户,那么为某些用户猜测一个正确的URL变得相对容易。

这是birthday attack的典型例子。

ETA:错过了关于秘密大小的部分,所以这并不适用于你的情况,但会留下答案,因为它可能适用于更一般的情况。

答案 3 :(得分:0)

“秘密URL”通常被默默无闻称为安全性。问题在于编写一个脚本非常简单,该脚本将尝试各种字母,符号和数字的组合来暴力破解这个方案。

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

答案 4 :(得分:0)

  

可以补充他们的注册(非关键,“低安全性”)信息

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

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

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

下进行。

答案 5 :(得分:0)

如果您不使用SSL,则秘密网址没有任何意义。如果您仍然让最终用户明确地通过互联网传输他们的识别信息,那么您是如何让他们进入的并不重要:他们仍然暴露在外。