HMAC URL而不是登录？

Question

在实施我的网站（Rails网站，如果它有所不同），我的设计优先事项之一是减轻用户创建另一个用户名和密码的需要，同时仍然提供有用的每用户功能。

我计划这样做的方式是：

1. 用户在网站上输入信息。信息通过服务器端会话与用户相关联。
2. 用户完成输入信息，服务器通过电子邮件向用户发送访问URL，大致形式为：http://siteurl/<user identifier>/<signature: HMAC(secret + salt + user identifier)>
3. 用户点击URL，站点查找用户ID和salt，并使用服务器存储的密钥计算HMAC，并验证计算的HMAC和签名是否匹配。

我的问题是：这是一种相当安全的方式来完成我想要做的事情吗？是否存在会导致无用的常见攻击？是否有令人信服的理由放弃避免用户名/密码的愿望？是否有关于这个主题的必读书籍或文章？

请注意，我并未处理信用卡号码或任何非常私密的信息，但我仍希望保持信息的合理安全。

Answer 1

一个词（好吧，实际上是两个） - Referer标题。 访问您的用户后访问的下一个站点将在此标题中看到他的凭据。此外，用户在以这种方式遭到入侵后将无法更改其凭据。

用户名/密码验证的想法是它涉及两条独立的信息 - 一个已知的用户ID和一个可以按用户自由更改的未知密码。在你的系统中（除了Referer之外），所有人都有一个密码 - “秘密”。我还怀疑强制签名（因为我知道我的用户ID）并恢复秘密会很容易，使整个系统无用。

Answer 2

我考虑过类似的无密码登录iPhone应用程序 - 网络应用程序的最大问题是登录变得不必要地繁琐。

那就是说，这是一个简单的修改：

1. 用户输入电子邮件地址。
2. 服务器生成随机身份验证（例如128位/ dev / urandom，base64编码）令牌并将H(authtoken)与时间戳一起保存到数据库，然后发送一封https://example.com/login/userid?auth=authtoken <的电子邮件/ LI>
3. 用户点击网址，服务器检查该令牌是否在数据库中且未过期，从数据库中删除令牌并设置会话cookie。

您的服务器需要存储更多状态，但无论如何都需要存储状态。它的工作方式与任何良好的密码重置流大致相同，可能使理论上 同样安全。但是，实际上，它并没有像account-hijack-via-password-reset那样明显的审计跟踪，因为“密码重置”流程现在是正常的登录流程。

您还可以使用MAC和时间戳(uid,timestamp,MAC_k(uid,timestamp))执行类似操作 - 基本问题是任何有权访问MAC密钥的人（例如数据库备份）都可以生成任意身份验证令牌，并且数据库泄漏所有时间。

当散列/ MACing时，要注意“加密拼接”攻击。

此外，一个常见的错误是显示给定的电子邮件地址是否有帐户（通常登录名称为“无效的电子邮件/密码”，但密码重置流程将其丢弃 - 更好的方法是始终发送电子邮件，并且说“电子邮件中没有与此电子邮件关联的帐户”，理想情况下与成功响应的字节数相同！）。