What's the most secure possible Devise configuration?

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.paranoid so 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?

---

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.

---

For passwords, you can checkout https://github.com/bitzesty/devise_zxcvbn which rejects passwords with weak entropy, and checks against known cracked passwords.