带有令牌参数的 https URL：它有多安全？

SSL 将保护传输中的查询参数；但是，电子邮件本身并不安全，电子邮件在到达目的地之前可能会在任意数量的服务器上反弹。

此外，根据您的 Web 服务器，完整的 URL 可能会记录在其日志文件中。根据数据的敏感程度，您可能不希望您的 IT 人员访问所有令牌。

此外，带有查询字符串的 URL 将保存在您的用户历史记录中，允许同一台机器的其他用户访问该 URL。

最后，使这非常不安全的是，URL 是在任何资源的所有请求的Referer 标头中发送的，甚至是第三方资源。因此，例如，如果您使用 Google Analytics（分析），您将向 Google 发送 URL 令牌并将其全部发送给他们。

在我看来，这是一个坏主意。

---

我会为此使用cookie。工作流程应该是这样的：

用户第一次访问您的网站。站点设置 cookie 用户输入数据。使用存储在 cookie 中的某个键将数据存储在数据库中。当用户离开时，您会向他们发送一封带有 https: 链接的电子邮件。当用户回来时，站点会发现 cookie 并可以向用户提供旧数据。

现在，用户想要在不同的机器上使用不同的浏览器。在这种情况下，提供一个“转移”按钮。当用户点击这个按钮时，她会得到一个“令牌”。她可以在另一台计算机上使用此令牌来重置 cookie。这样，用户可以决定她想要转移令牌的安全性。

---

SSL 保护传输中的数据内容，但我不确定 URL。

无论如何，减轻攻击者重复使用该 URL 令牌的一种方法是确保每个令牌只能使用一次。您甚至可以设置一个 cookie，以便合法用户可以继续使用该链接，但在第一次访问后，它只对拥有 cookie 的人有效。

如果用户的电子邮件被泄露并且攻击者首先获得了链接，那么你就完蛋了。但用户也有更大的问题。

---

电子邮件本质上是不安全的。如果任何人都可以单击该链接并获取数据，那么您并没有真正保护它。

---

那么令牌在通过 SSL 传递时是安全的。您将遇到的问题是，人们（那些不适合使用它的人）可以通过查看 URL 来使用它。

如果是像 SSN 这样的私人信息，我认为我不会通过电子邮件发送 URL。我宁愿让他们为该站点创建用户名和密码。对于您和他们来说，使用此类信息危及您的利益的电子邮件太容易泄露。如果某人的帐户被盗用，就会有人质疑这到底是谁的错。从严格的 CYA 角度来看，您越安全越好。

---

您是否知道，如果任何黑客访问您的数据库，可以免费提供大量个人信息？

在那之后，我会说这不是一个坏主意。我不会使用 MD5 或 SHA1，因为它们对于散列不是很安全。它们可以很容易地“解密”（我知道这不是加密）。

否则，我可能会使用不会通过电子邮件发送的第二个信息，例如密码。原因很简单，如果有人可以访问用户的电子邮件（如果您不终止会话，使用 hotmail 很容易），他将可以访问用户发送的任何信息。

请注意，HTTPS 将保护和加密从您的站点发送到最终用户的数据。没有别的，把它当作一个安全的隧道。不多不少。

---

对于存在严重隐私问题的情况，我真的认为这不够安全。您在（可能是明文）电子邮件中发送 URL 的事实是迄今为止最薄弱的环节。之后是对令牌进行暴力攻击的风险，令牌（缺乏真正的身份验证机制的结构）可能比结构良好的用户名和密码设置更容易受到攻击。

顺便说一句，https 请求中的参数完全没有问题。

---

事实上，这将是一个坏主意。您将轻松使用安全性。如前所述，SSL 只会保护服务器和客户端浏览器之间的信息传输，只会防止中间人攻击。电子邮件非常危险且不安全。

最好的方法是通过用户名和密码身份验证来访问信息。

我或多或少喜欢饼干的想法。您还应该加密 cookie 信息。您还应该使用盐和关键短语以及 $_SERVER['HTTP_USER_AGENT'] 生成令牌以限制攻击的可能性。在 cookie 中存储尽可能多的关于客户端的非敏感信息以供验证使用。

关键短语可以存储在 cookie 中以便于使用，但请记住，cookie 也可能被盗 =(.

最好让客户键入他提供的关键词，该关键词也与他的数据一起存储在数据库中。

或者，如果该人使用 $_SERVER['HTTP_USER_AGENT'] 参数不同的不同机器或只是错过了 cookie，则可以使用该密钥。所以cookie可以被传输或设置。

还要确保数据库中的敏感数据已加密。你永远不会知道 ;）

---

根据我对您的想法的理解，理论上有人可以输入随机的 40 个字符串或 MD5 哈希并获取其他人的详细信息。虽然这可能极不可能发生，但它只需要发生一次。

更好的解决方案可能是向用户发送令牌，然后要求他们输入一些详细信息，例如他们的姓名、邮政编码、ssn 或这些的组合。

---