什么是最安全的Devise配置？

Question

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

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

我想我会做以下事情:

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

一些我不确定的具体事情,用devise.rb斜体字引用:

• 胡椒.Devise可以选择"设置胡椒来生成加密密码".我的理解是,这是一个单独的,特定于应用程序的值,它将诸如"password123"之类的愚蠢密码转换为类似"password123K#(!@ akdlwekdf"或"*%!kd39gpassword123"或类似之前的任何哈希值).这是为了挫败彩虹表攻击,但我对这篇文章的理解是,它不如每个密码的独特盐那么好.然后,这篇文章和本文说bcrypt有内置的盐.使用胡椒与bcrypt真的添加任何东西吗？我可以,还有什么需要,还有一个盐柱吗？
• 伸展."对于bcrypt,这是散列密码的成本,默认为10." 基于这个问题,我正在考虑使用12的工作系数.这看起来合情合理吗？
• 密码长度.一般来说,较长的密码似乎更安全,但我不希望它太难以让用户将它写在某张纸上.如果我们使用bcrypt,密码长度是否重要？
• SSL cookie.对于启用了SSL的公共应用程序,将cookie标记为"这只能通过HTTPS传输"可以防止Firesheep风格的攻击.但我不确定为内部应用程序获得安全证书会有多大意义.这很傻吗？

我还缺少什么？

Answer 1

辣椒:是的,你是对的.如果你使用盐,胡椒没有太多额外的安全性.

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

密码长度:强制任何类型的密码规则都会降低密码的熵.唯一的限制应该是最小长度,并且许多研究表明至少8个字符.

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