32

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?

Community
  • 1
  • 1
Nathan Long
  • 122,748
  • 97
  • 336
  • 451
  • 2
    SSL isn't silly. It is *always* important when you're sending login credentials across the network. – user229044 Jul 26 '11 at 15:33
  • 4
    I have the same question. Could you post a self-answer to share what you have learned and what you used? – KobeJohn Jan 17 '12 at 16:05

2 Answers2

21

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.

chris
  • 6,653
  • 6
  • 41
  • 54
  • If you want a class for an scrypt encryptable for devise, I have written one. You can use and improve. – chris Jul 24 '12 at 03:04
  • is your scrypt class for Devise open sourced? – Nathan Long Jul 24 '12 at 13:38
  • 3
    My current understanding is that a "pepper" is a single, app-wide salt, which can be applied in addition to user-specific salts, and which resides in the application code (*not* the database). In theory, if the database were compromised but the application code were not, this could help. But at best it's an additional measure to something like bcrypt or scrypt. – Nathan Long Jul 24 '12 at 13:41
  • https://github.com/chrismcleod/files/blob/master/devise/encryptable/encryptors/scrypt.rb – chris Jul 24 '12 at 14:40
  • 1
    so if the project is open source, wouldn't a pepper on top of the salt be a good idea because if your database is compromised, they have access to your hashed passwords (including their salts) AND the encryption scheme? But if you had a pepper, it would presumably not be checked into the project, so that would be another layer of security – bdwain Apr 15 '13 at 01:02
  • Could you reason a bit more? Your points are good but seem too opinionated for somebody who doesn't know these matters. – schmijos Dec 29 '15 at 11:11
  • 2
    There is good reasoning on security.stackexchange.com explaining that [in some circumstances, peppers can be helpful](http://security.stackexchange.com/a/3289/86593). – weston Feb 10 '16 at 19:51
4

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

MatthewFord
  • 2,918
  • 2
  • 21
  • 32