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 回答