SSL将保护传输中的查询参数;但是,电子邮件本身并不安全,电子邮件可能会在到达目的地之前沿任意数量的服务器反弹。
此外,根据您的Web服务器,可能会在其日志文件中记录完整的URL。根据数据的敏感程度,您可能不希望IT人员访问所有令牌。
此外,带有查询字符串的URL将保存在用户的历史记录中,允许同一台计算机的其他用户访问该URL。
最后,这使得这个非常不安全的是,URL在Referer头中发送给任何资源的所有请求,甚至是第三方资源。因此,如果您使用Google Analytics(分析),则会向Google发送URL令牌及其全部内容。
在我看来,这是一个坏主意。
对于存在严重隐私问题的情况,我真的不会认为这足够安全。您在(可能是明文)电子邮件中发送URL的事实是迄今为止最薄弱的环节。在此之后,对令牌进行暴力攻击的风险(缺乏真正的身份验证机制的结构)可能比构建良好的用户名和密码设置更容易受到攻击。
顺便提一句,https请求中的参数完全没有问题。
事实上,这是一个坏主意。您将通过简单的使用来确保安全性。如前所述,SSL只会保护服务器和客户端浏览器之间的信息传输,只会阻止中间人攻击。电子邮件非常危险且不安全。
最好的是用户名和密码验证来访问信息。
我或多或少喜欢cookie的想法。您也应该加密cookie信息。 您还应该使用salt和关键短语以及$ _SERVER ['HTTP_USER_AGENT']生成令牌,以限制攻击的可能性。在cookie中存储有关客户端的尽可能多的非敏感信息以供验证使用。
关键短语可以存储在cookie中以方便使用,但请记住,cookie也可能被盗=(。
最好让客户输入他提供的关键短语,它也与他的数据一起存储在数据库中。
或者,如果此人使用不同于$ _SERVER ['HTTP_USER_AGENT']参数的机器或仅仅错过了cookie,则可以使用该密钥。因此cookie可以被转移或设置。
还要确保在数据库中加密敏感数据。你永远都不会知道 ;)
您知道如果任何黑客可以访问您的数据库,可以自由地提供许多个人信息吗?
在那之后,我会说这不是坏主意。我不会使用MD5或SHA1,因为它们对于散列不是很安全。它们可以很容易地“解密”(我知道它不是加密)。
否则我可能会使用不会通过电子邮件发送密码的第二个信息。原因很简单,如果有人可以访问用户的电子邮件(如果你不杀死你的会话就很容易使用hotmail),他将可以访问用户发送的任何信息。
请注意,HTTPS将保护从您的站点发送给最终用户的数据和加密数据。没有别的,把它作为一个安全的tunel。没有什么比这更重要了。
电子邮件本质上是不安全的。如果任何人都可以点击该链接并获取数据,那么您并没有真正保护它。
我会用饼干。工作流程应如下所示:
现在,用户想要在不同的计算机上使用不同的浏览器。在这种情况下,请提供“转移”按钮。当用户点击此按钮时,她将获得“令牌”。她可以在另一台计算机上使用此令牌来重置cookie。这样,用户就决定了她想要转移令牌的安全性。
那么令牌在通过SSL时是安全的。您将遇到的问题是,通过能够查看URL,人们(不是那些不适合的人)可以使用它。
如果它是像SSN这样的私人信息,我认为我不会通过电子邮件发送URL。我宁愿让他们为网站创建用户名和密码。使用您和他们所涉及的那种信息来妥协电子邮件太容易了。如果有人的帐户被证实,那么它将会出现问题。从严格的CYA角度来看,您越安全越好。
根据我对你的想法的理解,理论上有人可以输入一个随机的40个字符串或MD5哈希,并获得别人的细节。虽然这可能是非常不可能的,但它只需要发生一次。
更好的解决方法可能是向用户发送令牌然后要求他们输入一些细节,例如他们的姓名,邮政编码,ssn或这些的组合。