32

我即将开始在我们公司设置一个仅限员工使用的 Rails 应用程序，用于处理敏感信息。会有防火墙、物理安全措施等。我现在关心的是应用程序的登录过程。

我想使用 Devise 进行身份验证。Devise 最安全的配置是什么？

我想我会做以下事情：

  • 在少量失败的登录尝试后锁定帐户
  • 使用config.paranoid这样攻击者就无法判断他们是否猜到了一个有效的电子邮件地址
  • 也许通过电子邮件禁用密码重置？

一些我不确定的具体事情，用devise.rb斜体引用：

  • 胡椒。设计有一个选项“设置一个辣椒来生成加密密码”。我的理解是，这是一个单一的、特定于应用程序的值，它将“password123”之类的愚蠢密码转换为“password123K#(!@akdlwekdf”或“*%!kd39gpassword123”之类的东西，或者在散列之前的任何东西。这是为了阻止彩虹表攻击，但我从这篇文章的理解是它不如每个密码唯一的盐。再说一遍，这篇文章和这篇论文说bcrypt内置了盐。使用bcrypt的胡椒真的有什么好处吗？我可以，是否有必要，也有一个盐柱？
  • 伸展。“对于 bcrypt，这是散列密码的成本，默认为 10。” 基于这个问题，我正在考虑使用 12 的工作系数。这看起来合理吗？
  • 密码长度。一般来说，较长的密码似乎更安全，但我不希望它太难以至于用户将其写在某处的一张纸上。如果我们使用 bcrypt，密码长度是否很重要？
  • SSL cookie。对于启用 SSL 的公共应用程序，将 cookie 标记为“只能通过 HTTPS 传输”可以防止Firesheep式攻击。但我不确定拥有一个内部应用程序的安全证书有多大意义。这很傻吗？

我还缺少什么？

4

2 回答 2

21

辣椒：是的，你是对的。如果您使用盐，胡椒不会带来太多额外的安全性。

Stretches : 12 是合理的，但是 bcrypt 只能确保恒定的时间。您应该考虑使用较新的 scrypt，因为它允许您指定恒定时间和要使用的内存量。Cryptyograhpically bcrypt 和 scrypt 大致相同，但 scrypt 使暴力破解更加困难。

密码长度：强制任何类型的密码规则都会减少密码的熵。唯一的限制应该是最小长度，许多研究表明至少有 8 个字符。

SSL Cookies：如果可以，请使用它们。安全性应始终从一开始就建立，而不是以后添加。您永远无法确定谁可能在嗅探您的内部网络。仅仅因为您假设没有外部人员可以嗅探数据，并不意味着内部员工不会出于某种原因。您有责任保护您的员工免受彼此以及外部威胁。

于 2012-07-24T03:03:56.650 回答
4

对于密码，您可以查看https://github.com/bitzesty/devise_zxcvbn，它拒绝弱熵密码，并检查已知的破解密码。

于 2014-01-20T14:46:21.787 回答