在我们的网站上，我们根据用户的私人信息（通过表格提供）向他们提供模拟。我们希望允许他们稍后再获得其模拟结果，但又不必强迫他们创建登录名/密码帐户。
我们已经考虑过向他们发送带有链接的电子邮件，他们可以从中获取结果。但是，自然地，我们必须保护此URL，因为私有数据受到威胁。
因此，我们打算在URL中传递令牌（如字母和数字的40个字符的组合，或MD5哈希），并使用SSL。
最后，他们会收到这样的电子邮件：
嗨，
在https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn上获取结果
你怎么看待这件事？它足够安全吗？对于代币生成，您有什么建议？如何在https请求中传递URL参数呢？
Answers:
SSL将保护传输中的查询参数；但是，电子邮件本身并不安全，并且电子邮件可能会在到达目的地之前沿任意数量的服务器反弹。
另外，取决于您的Web服务器，完整的URL可能会记录在其日志文件中。根据数据的敏感程度，您可能不希望IT人员访问所有令牌。
此外，带有查询字符串的URL将保存在用户的历史记录中，从而允许同一计算机的其他用户访问该URL。
最后，最不安全的是，URL在所有资源（甚至第三方资源）的所有请求的Referer标头中发送。因此，例如，如果您使用的是Google Analytics（分析），则将URL令牌以及所有令牌发送给Google。
我认为这是一个坏主意。
我会为此使用cookie。工作流程应如下所示：
现在，用户希望在其他计算机上使用其他浏览器。在这种情况下，请提供一个“转移”按钮。当用户单击此按钮时，她将获得一个“令牌”。她可以在另一台计算机上使用此令牌来重置cookie。通过这种方式，用户可以决定她希望传输令牌的安全性。
那么令牌通过SSL传递时是安全的。您将要遇到的问题是，可以通过查看URL来使人（不适合其使用的人）满意。
如果是像SSN这样的私人信息，我认为我不会通过电子邮件发送URL。我希望他们为该网站创建一个用户名和密码。对于您和他们来说，危及具有此类危险信息的电子邮件太容易了。如果某人的帐户受到损害，就会引起怀疑，这实际上是谁的错。从严格的CYA角度出发，越安全越好。
对于存在严重隐私问题的情况，我真的不认为这样的安全性足够。到目前为止，您通过（可能是明文）电子邮件发送URL的事实是最弱的链接。之后，存在对令牌进行蛮力攻击的风险，这种令牌（缺乏真实的身份验证机制的结构）比结构合理的用户名和密码设置更容易受到攻击。
顺便说一句，https请求中的参数根本没有问题。
实际上，这将是一个坏主意。您将通过易于使用来破坏安全性。如前所述，SSL仅保护服务器和客户端浏览器之间的信息传输，并且仅防止中间人攻击。电子邮件非常危险且不安全。
最好的办法是使用用户名和密码验证来访问信息。
我或多或少喜欢cookie的想法。您还应该加密cookie信息。您还应该生成带有盐和关键字短语以及$ _SERVER ['HTTP_USER_AGENT']的令牌，以限制攻击的可能性。在Cookie中存储有关客户端的尽可能多的非敏感信息，以供验证使用。
关键字可以存储在cookie中以方便使用，但请记住，cookie也可能被盗=（。
最好让客户键入他提供的关键词，该关键词也与他的数据一起存储在数据库中。
或者，如果该人使用的其他机器的$ _SERVER ['HTTP_USER_AGENT']参数有所不同，或者只是错过了cookie，则可以使用该键。这样就可以传输或设置Cookie。
还要确保敏感数据在数据库中已加密。你永远都不会知道 ;）
您知道，如果有任何黑客可以访问您的数据库，那么可以免费提供许多个人信息？
之后，我想说这还不错。我不会使用MD5或SHA1，因为它们对于散列不是很安全。可以很容易地将它们“解密”（我知道这不是加密）。
否则，我可能会使用不会通过电子邮件发送的第二种信息作为密码。原因很简单，如果某人可以访问用户的电子邮件（如果您不取消会话，则很容易使用hotmail），他将有权访问该用户发送的任何信息。
请注意，HTTPS将保护和加密从您的站点发送给最终用户的数据。没什么，把它当作一个安全的隧道。没什么比没什么少。
根据我对您的想法的了解，从理论上讲，有人可以输入40个随机字符串或MD5哈希值，并获取他人的详细信息。尽管这不太可能发生，但是只需要发生一次。
更好的解决方法是向用户发送令牌，然后要求他们输入一些详细信息，例如他们的姓名，邮政编码，ssn或这些内容的组合。