Политика блокировки и одноразовые пароли - PullRequest
0 голосов
/ 12 января 2011

Для моего сайта реализована система одноразовых паролей, использующая RFC 4226 .Этот пароль отправляется с помощью SMS на мобильное устройство.Пользователь может получить пароль только на своем мобильном устройстве, срок действия пароля истекает через 15 минут.

У пользователей также есть стандартный буквенно-цифровой «мастер-пароль», который обычно используется.Я реализовал рабочий процесс блокировки 3 сбоя.Эта блокировка длится 15 минут.

Мой вопрос с точки зрения безопасности: допустимо ли блокировать только «мастер-пароль»?Должен ли я разрешить пользователям обходить политику блокировки, если они используют функцию одноразового пароля?Я открываю какие-нибудь дыры в безопасности?

Ответы [ 2 ]

3 голосов
/ 12 января 2011

Это не совсем ответ на ваш вопрос, но при построении таких систем вы должны помнить, что удобство использования превосходит безопасность каждый раз, когда две прикладные головки.Чем труднее вы делаете свою политику безопасности для конечных пользователей, тем больше у них будет мотивации предлагать небезопасные обходные пути для выполнения своей работы.Здесь можно подвести итог, я бы посоветовал почитать там его материалы.

2 голосов
/ 13 января 2011

Я понимаю вашу точку зрения: безопасность и удобство использования. Я предлагаю вам внедрить статический пароль механизм блокировки, который стал стандартом де-факто практически для каждого веб-сайта.

здесь объяснено очень хорошо, поэтому мне не нужно вводить снова:

Большинство механизмов блокировки паролей сегодня являются статическими, что означает, что они блокируют пользователя после определенного числаневерный пароль пытается.Эта функция реализована для предотвращения попыток перебора против входа в систему.Несмотря на то, что эта функция делает то, что должна, у нее тоже есть свои недостатки.С точки зрения безопасности, эта функция может быть использована злоумышленником для блокировки большинства или всех пользователей путем написания сценария со всеми возможными перестановками и комбинациями для имени пользователя (которые в основном состоят из букв, если не буквенно-цифровых), что приводит кпри отказе в обслуживании .

С точки зрения удобства использования всегда ведутся споры относительно количества попыток, которые должны быть разрешены до блокировки учетной записи пользователя.Большинство веб-сайтов допускают 3 попытки, в то время как некоторые (очень немногие) допускают 5, а иногда и 7.

Intellipass пытается преодолеть разрыв между безопасностью и удобством использования этой функции.Сохраняя каждую попытку входа пользователя в систему, Intellipass может разумно понимать поведение пользователя в прошлом и действовать соответственно.НапримерЕсли пользователь блокируется каждый раз, то Intellipass будет динамически увеличивать количество попыток с 3 до 5 или с 5 до 7. С другой стороны, если пользователь входит в систему первый или второй раз каждый раз, когда он или она пытается войти в системув прошлом, но по какой-то причине в этот раз предпринимались 3 попытки, Intellipass автоматически уменьшит количество попыток с 7 до 5 или с 5 до 3. Второй компонент Intellipass добавляет случайную капчу или вставляет задержку междуЛогин пытается предотвратить автоматические атаки.

...