最安全的 Devise 配置是什么？
我即将开始在我们公司设置一个仅供员工使用的 Rails 应用程序，用于处理敏感信息。会有防火墙、物理安全措施等。我现在关心的是应用程序的登录过程。
我想使用 Devise 进行身份验证。 Devise 最安全的配置是什么？
我想我会执行以下操作：
- 在少量登录尝试失败后锁定帐户
- 使用
config.paranoid以便攻击者无法判断他们是否猜测了有效的电子邮件地址 - 也许禁用通过电子邮件重置密码？
我不确定的一些具体事情，用斜体引用 devise.rb ：
- Peppers。 Devise 有一个选项“设置一个胡椒来生成加密的密码。” 我的理解是，这是一个单一的、特定于应用程序的值，它将诸如“password123”之类的愚蠢密码转换为“password123K#(!@akdlwekdf”或“*%!kd39gpassword123”或散列之前的任何内容，这是为了阻止彩虹表攻击，但我的理解是 这篇文章 的优点是它不如每个密码唯一的盐。然后再次，这篇文章和本文 说bcrypt 内置了盐。将胡椒与 bcrypt 一起使用真的会添加任何东西吗？我可以并且有必要也有一个盐柱吗？
- 伸展。 “对于 bcrypt，这是哈希密码的成本，默认为 10。” 基于 这个问题，我正在考虑使用工作因子 12。这看起来合理吗？
- 密码长度。一般来说，较长的密码似乎更安全，但我不希望它太难，以至于用户将其写在一张纸上的某个地方。如果我们使用 bcrypt，密码长度重要吗？
- SSL cookies。对于启用了 SSL 的公共应用程序，将 cookie 标记为“只能通过 HTTPS 传输”可以防止 Firesheep 式攻击。但我不确定为内部应用程序拥有安全证书有多大意义。这很傻吗？
我还缺少什么？
I'm about to start setting up an employees-only Rails application at our company for working with sensitive information. There will be a firewall, physical security measures, etc. My concern right now is the login process for the application.
I'd like to use Devise for authentication. What is the most secure possible configuration for Devise?
I'm thinking I wil do the following:
- Lock accounts after a small number of failed login attempts
- Use
config.paranoidso an attacker can't tell if they've guessed a valid email address - Maybe disable password resets by email?
Some of the specific things I'm unsure of, with quotes from devise.rb in italics:
- Peppers. Devise has an option to "Setup a pepper to generate the encrypted password." My understanding is that this is a single, app-specific value that transforms a stupid password like "password123" into something like "password123K#(!@akdlwekdf" or "*%!kd39gpassword123" or whatever before hashing. This is meant to thwart rainbow table attacks, but my understanding from this article is that it's not as good as a per-password unique salt. Then again, this article and this paper say that bcrypt has salts built in. Does using a pepper with bcrypt really add anything? Can I, and is there any need to, also have a salt column?
- Stretches. "For bcrypt, this is the cost for hashing the password and defaults to 10." Based on this question, I'm thinking of using a work factor of 12. Does that seem reasonable?
- Password length. A longer password seems more secure in general, but I don't want it to be so hard that the user writes it on a piece of paper somewhere. Does password length matter much if we're using bcrypt?
- SSL cookies. For public apps with SSL enabled, marking cookies as "this can only be transmitted over HTTPS" protects against Firesheep-style attacks. But I'm not sure how much sense it makes to have a security certificate for an internal app. Is that silly?
What else am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Peppers：是的，你是对的。如果您使用盐，则胡椒粉并不会带来太多额外的安全性。
拉伸：12是合理的，但bcrypt只能确保恒定的时间。您应该考虑使用较新的 scrypt，因为它允许您指定恒定时间和要使用的内存量。密码学上，bcrypt 和 scrypt 大致相同，但 scrypt 使暴力破解变得更加困难。
密码长度：强制执行任何类型的密码规则都会减少密码的熵。唯一的限制应该是最小长度，许多研究建议至少 8 个字符。
SSL Cookie：如果可以的话请使用它们。安全性应该始终从一开始就构建，而不是后来添加。您永远无法确定谁可能正在嗅探您的内部网络。仅仅因为您假设没有外部人员可以嗅探数据，并不意味着内部员工不会因为某种原因而无法嗅探数据。您有责任保护您的员工免受彼此以及外部威胁的侵害。
Peppers: yes you are correct. There is not much additional security achieved with a pepper if you are using salt.
Stretches: 12 is reasonable, however bcrypt only ensures a constant time. You should consider using the newer scrypt as it allows you to specify both a constant time and the amount of memory to use. Cryptyograhpically bcrypt and scrypt are about the same but scrypt makes brute forcing harder.
Password length: forcing any sort of password rules reduces the entropy of passwords. The only restriction should be a minimum length and numerous studies have suggested at least 8 characters.
SSL Cookies: use them if you can. Security should always be built from the start and not added later. You can never be sure who might be sniffing you internal network. Just because you assume no outsiders can sniff data, does not mean inside employees wouldn't for one reason or another. You have a responsibility to protect your employees from each other as well as external threats.
对于密码，您可以查看https://github.com/bitzesty/devise_zxcvbn，它拒绝弱熵密码，并检查已知的破解密码。
For passwords, you can checkout https://github.com/bitzesty/devise_zxcvbn which rejects passwords with weak entropy, and checks against known cracked passwords.