盐渍哈希通过URL传递，用于持久登录而不使用Cookie

我正在制作其他人将放入其网站的脚本。它专为PHP知识有限的人设计，所以他们所要做的就是包含（）脚本并设置一些配置变量。这意味着头文件可能已经被发送，因此使用会话可能不起作用。我建议他们在自己的脚本中调用session_start，但我也想要一个后备选项。盐渍哈希通过URL传递，用于持久登录而不使用Cookie

我已经有一个隐藏的输入来处理表单，但我还需要链接来将查询字符串附加到它们的URI以识别会话。但是，如果散列仅基于密码+ salt，那么存在安全风险：登录的用户可以单击外部链接，外部站点的所有者可以在引用日志中看到带有散列的URI。他们所需要做的就是使用该散列并且他们将被登录。

因此，我想以时间敏感的方式对散列进行加盐，将会话限制为10分钟。我无法弄清楚如何做到这一点。当然，我可以使用time（）来加以限制，但是如何根据散列来检查会话的年龄？

来源

2010-09-11 Rafael

只是一个快速的时间暗示的建议，但它可能会包含IP地址的密码和盐吗？它不会创建一个依赖于时间的散列，但是读取日志并能够看到这些散列的人不太可能与合法用户处于相同的IP地址，从而使散列对他们基本无用。 – 2010-09-11 14:25:32

是的，但合法用户的IP可能会有所不同，因为大多数人不会从其ISP获得静态IP。 – Rafael 2010-09-11 17:18:49

10分钟后过期会话不会保护用户免受会话劫持攻击。它只能通过每10分钟强制登录一次就会让用户恼火。您提出的方案仍然存在各种各样的漏洞。你的腌过的哈希密码仍然可以通过许多其他渠道泄露给外部世界;数据包嗅探，中间代理，用户通过电子邮件发送链接到页面甚至保存的html，仅举几例。我建议你不要在自己的安全框架中成长，不要成为该领域的专家。即使这样，这是一个解决的问题。只需使用已知的可信解决方案。 Web安全中有许多微妙之处，容易搞砸。

来源

2010-09-11 14:24:00 Asaph

谢谢你，你部分地说服我抛弃这个想法，因为这一点在一分钟之内变得更加混乱。 – Rafael 2010-09-11 17:34:39

这听起来像一个真正的坏主意。也很复杂。我绝对不会推荐它。您可能可以使用这样的事情：

if (session_id() == "") session_start();

上述基本上会检查会话是否已启动，否则启动会话。

既然你打算分发给用户，整个方法似乎有点关闭给我。我不确定你想要达到什么目的，但你可以尝试使用一个JS来调用你的每页PHP文件。这会让你更容易。如果你能详细说明你正在开发什么样的应用程序，那么我可能会帮助你更好。我在大众消费软件应用程序方面有很多经验，与您正在做的相似。

来源

2010-09-11 14:22:02

谢谢。在我原来的文章中，我提到如果头文件已经被发送（即一些HTML已经被输出），session_start（）可能不起作用。尽管如此，我想通过确保登录表单提交给脚本本身（而不是包含器），然后我只是重定向回到包装器，就不需要任何垃圾并使用PHP会话。奥卡姆剃须刀再次工作。 – Rafael 2010-09-11 17:29:56

我的不好，我错过了那部分。无论如何，我希望你做一些有用的事情，以这种方式包括它。祝你好运。 – 2010-09-12 03:43:53

这不一定是个坏主意，但如果做得不正确，这会很危险。实际上，这是使用Hash-based Message Authentication Codes的多域单点登录的相当常见的实现。一些基本规则：

永远不要包括作为哈希（甚至盐）的一部分
要求时间戳一代必须随着哈希传递的哈希值的部分密码。
每个使用这个哈希的站点都应该有自己的32或64字节的guid作为独特的盐。
传递查询字符串中的特定数据，如用户名，时间戳，其他任何内容以及HMAC。因此，它看起来像？USER =史蒂夫&时间戳= 66343532233 & otherdata = otherdata & HMAC = AB3445-1234144-AFBBDEDD（你的想法）
当现场认证是由跨站点，应使用HTTP_REFERER（如果可能的话）来获得生成比较HMAC的密钥。
使用可靠的散列算法（SHA1是首选）来生成HMAC。尽可能随机地生成私人站点密钥。不要使用标准派生方法，只需确保最终结果足够大/足够独特。

来源

2010-09-11 20:14:50

盐渍哈希通过URL传递，用于持久登录而不使用Cookie

回答

相关问题