ruby-on-rails - 设计的 token_authenticable 安全吗？

Question

我正在用 Rails API 构建一个简单的 api ，并想确保我在这里走在正确的 rails 上。我正在使用 devise 来处理登录，并决定使用 Devise 的 token_authenticatable选项，它会生成您需要随每个请求发送的 API key 。

我将 API 与主干/牵线木偶前端配对，并且通常想知道我应该如何处理 session 。我的第一个想法是将 api key 存储在本地存储或 cookie 中，并在页面加载时检索它，但是从安全角度来看，关于以这种方式存储 api key 的一些事情困扰着我。通过查看本地存储/cookie 或嗅探任何通过的请求并使用它无限期地模拟该用户来获取 api key 会不会很容易？我目前正在每次登录时重置 api key ，但即使这样看起来也很频繁 - 任何时候您在任何设备上登录，这意味着您会在其他设备上退出，这有点痛苦。如果我可以放弃这个重置，我觉得从可用性的角度来看它会有所改善。

我在这里可能完全错了(希望我是)，任何人都可以解释以这种方式进行身份验证是否可靠安全，如果不是，那么有什么好的选择？总的来说，我正在寻找一种方法，我可以安全地让用户“登录”到 API 访问，而无需经常强制重新进行身份验证。

Answer 1

token_authenticatable容易受到定时攻击，这在 this blog post 中有很好的解释.这些攻击是原因 token_authenticatable已从设计 3.1 中删除。见 plataformatec blog post了解更多信息。

为了拥有最安全的 token 认证机制， token :

必须通过 HTTPS 发送。

必须是随机的，具有加密强度。

必须安全地进行比较。

不得直接存储在数据库中。只有 token 的散列可以存储在那里。 (记住， token = 密码。我们不会在数据库中以纯文本形式存储密码，对吗？)

根据某种逻辑应该过期。

如果您为了可用性而放弃这些要点中的一些，您最终会得到一个不那么安全的机制。就这么简单。如果您满足前三个要求并限制对数据库的访问，那么您应该足够安全。

扩展和解释我的答案:

使用 HTTPS .这绝对是最重要的一点，因为它涉及嗅探器。

如果您不使用 HTTPS，那么很多地方都可能出错。例如:

要安全地传输用户的凭据(用户名/电子邮件/密码)，您必须使用摘要式身份验证，但 that just doesn't cut it these days since salted hashes can be brute forced .

在 Rails 3 中，cookies 只被 Base64 编码覆盖，所以它们很容易被发现。见 Decoding Rails Session Cookies了解更多信息。

但是从 Rails 4 开始，cookie 存储被加密，因此数据经过数字验证并且攻击者无法读取。只要您的 secret_key_base Cookie 就应该是安全的没有泄漏。

生成您的 token :

SecureRandom.hex 仅当您使用 Ruby 2.5+ 时。

gem sysrandom 如果您使用的是较旧的 Ruby。

要解释为什么这是必要的，我建议阅读 sysrandom 的自述文件和博客文章 How to Generate Secure Random Numbers in Various Programming Languages .

使用用户的 ID、电子邮件或其他一些属性查找用户记录。然后，将该用户的 token 与请求的 token 与 Devise.secure_compare(user.auth_token, params[:auth_token] 进行比较。 .
如果你使用 Rails 4.2.1+ 你也可以使用 ActiveSupport::SecurityUtils.secure_compare .

做 不是 使用 Rails finder 查找用户记录，例如 User.find_by(auth_token: params[:auth_token]) .这很容易受到定时攻击!

如果您要为每个用户同时拥有多个应用程序/ session ，那么您有两个选择:

将未加密的 token 存储在数据库中，以便在设备之间共享。这是一种不好的做法，但我想您可以以 UX 的名义这样做(并且如果您信任您的员工具有数据库访问权限)。

为每个用户存储尽可能多的加密 token ，以允许当前 session 。因此，如果您想在 2 个不同的设备上允许 2 个 session ，请在数据库中保留 2 个不同的 token 哈希。此选项实现起来不太直接，但绝对更安全。它还具有允许您通过撤销 token (就像 GitHub 和 Facebook 所做的那样)为您的用户提供结束特定设备中当前事件 session 的选项的好处。

应该有某种机制导致 token 过期。在实现此机制时，请考虑 UX 和安全性之间的权衡。

Google expires a token if it has not been used for six months .

Facebook expires a token if it has not been used for two months :

Native mobile apps using Facebook's SDKs will get long-lived access tokens, good for about 60 days. These tokens will be refreshed once per day when the person using your app makes a request to Facebook's servers. If no requests are made, the token will expire after about 60 days and the person will have to go through the login flow again to get a new token.

升级到 Rails 4 以使用其加密的 cookie 存储。如果你不能，那么你自己加密 cookie 存储，就像建议的 here .在加密的 cookie 存储中存储身份验证 token 绝对没有问题。

您还应该有一个应急计划，例如，一个用于重置 token 子集或数据库中每个 token 的 rake 任务。

要开始使用，您可以查看 this gist (由 Devise 的一位作者撰写)关于如何使用 Devise 实现 token 认证。最后， the Railscast on securing an API应该有帮助。