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

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

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

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

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

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

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

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

Ответ 1

Peppers: да, вы правы. Если вы пользуетесь солью, вам не пригодится дополнительная безопасность.

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

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

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

Ответ 1

Ответ 2