什么是最安全的Devise配置？

Question

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

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

我想我会做以下事情：

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

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

• Peppers。 Devise可以选择“设置胡椒来生成加密密码。”我的理解是，这是一个特定于应用程序的单一值，可以转换一个像“password123”这样的愚蠢的密码，比如“password123K＃（！@ akdlwekdf”或“*％！kd39gpassword123”或者之前的任何哈希值。这是为了阻止彩虹表攻击，但我对this article的理解是它不如每个密码的独特盐那么好。然后，this article和this paper说bcrypt内置了盐。使用胡椒与bcrypt真的添加任何东西吗？我可以，并且在那里任何需要，还有一个盐柱？
• 的伸展即可。 “对于bcrypt，这是散列密码的成本，默认为10。”基于this question，我正在考虑使用12的工作因子。这看起来合情合理吗？
• 密码长度。一般来说，较长的密码看起来更安全，但我不希望它变得如此困难以至于用户将其写在某张纸上。如果我们使用bcrypt，密码长度是否很重要？
• SSL Cookie 。对于启用了SSL的公共应用程序，将cookie标记为“这只能通过HTTPS传输”可防止Firesheep式攻击。但我不确定为内部应用程序获得安全证书会有多大意义。那太傻了吗？

我还缺少什么？

Answer 1

辣椒：是的，你是对的。如果你使用盐，胡椒没有太大的额外安全性。

拉伸：12是合理的，但是bcrypt只能确保一个恒定的时间。您应该考虑使用较新的scrypt，因为它允许您指定常量时间和要使用的内存量。 Cryptyograhpically bcrypt和scrypt大致相同，但scrypt使暴力变得更难。

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

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

Answer 2

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