Политика блокировки и одноразовые пароли
У меня есть система одноразовых паролей, реализованная для моего сайта с использованием RFC 4226. Этот пароль отправляется с помощью SMS на мобильное устройство. Пользователь может получить пароль только на своем мобильном устройстве, и срок действия пароля истекает через 15 минут.
Пользователи также имеют стандартный буквенно-цифровой "мастер-пароль", который обычно используется. Я реализовал рабочий процесс блокировки 3-х сбоев. Этот локаут длится 15 минут.
Мой вопрос с точки зрения безопасности: допустимо ли блокировать только "мастер-пароль"? Должен ли я разрешить пользователям обходить политику блокировки, если они используют функцию одноразового пароля? Я открываю какие-нибудь дыры в безопасности?
2 ответа
Это не совсем ответ на ваш вопрос, но при создании подобных систем вы должны иметь в виду, что удобство использования превосходит безопасность каждый раз, когда две прикладные головки. Чем труднее вы делаете свою политику безопасности для конечных пользователей, тем больше у них будет мотивации придумывать небезопасные обходные пути для выполнения своей работы.
Шнайер сказал, что лучше, чем я могу резюмировать здесь, я бы посоветовал почитать там его материалы.
Я понимаю вашу точку зрения на безопасность и удобство использования. Я предлагаю вам внедрить механизм статической блокировки паролей, который стал стандартом де-факто практически для каждого веб-сайта.
здесь объяснено очень хорошо, поэтому мне не нужно вводить снова:
Большинство механизмов блокировки паролей сегодня являются статическими, то есть они блокируют пользователя после определенного количества попыток ввода неверного пароля. Эта функция реализована для предотвращения попыток перебора против входа в систему. Несмотря на то, что эта функция делает то, что должна, у нее тоже есть свои недостатки. С точки зрения безопасности, эта функция может быть использована злоумышленником для блокировки большинства или всех пользователей путем написания сценария со всеми возможными перестановками и комбинациями для имени пользователя (которые в основном представляют собой алфавиты, если не алфавитно-цифровые), в результате чего в отказе в обслуживании.
С точки зрения удобства использования всегда ведутся споры относительно количества попыток, которые должны быть разрешены до блокировки учетной записи пользователя. Большинство веб-сайтов допускают 3 попытки, в то время как некоторые (очень немногие) допускают 5 или иногда 7.
Intellipass пытается преодолеть разрыв между безопасностью и удобством использования этой функции. Сохраняя каждую попытку входа пользователя в систему, Intellipass может разумно понимать поведение пользователя в прошлом и действовать соответственно. Например Если пользователь блокирует себя каждый раз, то Intellipass будет динамически увеличивать количество попыток с 3 до 5 или с 5 до 7. С другой стороны, если пользователь входит в систему первый или второй раз каждый раз, когда он или она пытались войти в систему В прошлом, но по какой-то причине в этот раз предпринимались 3 попытки, Intellipass автоматически уменьшит количество попыток с 7 до 5 или с 5 до 3. Второй компонент Intellipass добавляет случайную капчу или вставляет задержку между Логин пытается предотвратить автоматические атаки.