Какова наиболее безопасная конфигурация Devise?

Question

Я собираюсь приступить к настройке приложения Rails только для сотрудников в нашей компании для работы с конфиденциальной информацией. Будет брандмауэр, физические меры безопасности и т. Д. Сейчас меня беспокоит процесс входа в приложение.

Я бы хотел использовать Devise для аутентификации. Какая конфигурация наиболее безопасна для Devise?

Я думаю, что сделаю следующее:

• Блокировка учетных записей после небольшого количества неудачных попыток входа в систему
• Используйте config.paranoid, чтобы злоумышленник не мог определить, угадал ли он действительный адрес электронной почты
• Может быть, отключить сброс пароля по электронной почте?

Некоторые конкретные вещи, в которых я не уверен, с цитатами из devise.rb, выделенными курсивом:

• Peppers. У Devise есть опция "Настройка перца для генерации зашифрованного пароля." Насколько я понимаю, это единственное значение, специфичное для приложения, которое преобразует глупость пароль типа «password123» в нечто вроде «password123K # (! @ akdlwekdf» или «*%! kd39gpassword123» или что-либо еще до хэширования. Это предназначено для предотвращения атак радужной таблицы, но, как я понимаю из этой статьи , что она не так хороша, как уникальная соль для каждого пароля. С другой стороны, эта статья и эта статья говорят, что в bcrypt есть встроенные соли. Действительно ли использование перца с bcrypt действительно добавляет что-нибудь ? Могу ли я, и есть ли необходимость, также иметь столбец соли?
• Отрезки . «Для bcrypt это стоимость хеширования пароля и по умолчанию 10». Исходя из этого вопроса , я подумываю использовать коэффициент работы 12. Это кажется разумно?
• Длина пароля . В целом более длинный пароль кажется более безопасным, но я не хочу, чтобы он был настолько сложным, чтобы пользователь записывал его где-нибудь на листе бумаги. Имеет ли значение длина пароля, если мы используем bcrypt?
• SSL cookie . Для общедоступных приложений с включенным протоколом SSL пометка файлов cookie как «это может быть передано только через HTTPS» защищает от атак типа Firesheep . Но я не уверен, какой смысл иметь сертификат безопасности для внутреннего приложения. Это глупо?

Что еще мне не хватает?

Answer 1

Перцы : да, вы правы.При использовании соли с перцем не так много дополнительной защиты.

Stretches : 12 разумно, однако bcrypt обеспечивает только постоянное время.Вам следует подумать об использовании более нового скрипта, поскольку он позволяет указывать как постоянное время, так и объем используемой памяти.Cryptyograhpically bcrypt и scrypt - это примерно одно и то же, но scrypt усложняет грубое форсирование.

Длина пароля : принудительное использование паролей любого типа уменьшает энтропию паролейЕдинственным ограничением должна быть минимальная длина, и многочисленные исследования предложили не менее 8 символов.

SSL-куки : используйте их, если можете.Безопасность всегда должна быть построена с самого начала, а не добавлена ​​позже.Вы никогда не можете быть уверены, кто может быть нюхает вашу внутреннюю сеть.То, что вы полагаете, что никакие посторонние не могут прослушивать данные, не означает, что сотрудники по той или иной причине не будут.Вы несете ответственность за защиту своих сотрудников друг от друга, а также от внешних угроз.

Answer 2

Для паролей вы можете проверить https://github.com/bitzesty/devise_zxcvbn, который отклоняет пароли со слабой энтропией и проверяет известные взломанные пароли.