Регистрация попыток аутентификации, включая пароли

Question

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

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

Однако было бы невозможно реализовать расширенную защиту без сохранения некоторых необработанных паролей, поэтому я пытаюсь найти лучший способ сделать это.

Вот несколько возможных решений, о которых я подумал:

• Не храните более 24 часов попыток входа в систему. Это на самом деле не решение, а просто ограничение ущерба, если пароли скомпрометированы.
• Очистить неудачные попытки пользователей, если они успешно аутентифицированы.

Кто-нибудь имеет какое-либо мнение по этому поводу? Это хорошая / плохая идея? Стоит ли использовать двустороннее шифрование?

Answer 1

Существует большая разница между пользователем, совершившим ошибки и атакой методом перебора / словаря: объем запросов . Не храните неудачные попытки - вы совершенно правы в том, что незашифрованный пароль должен обрабатываться минимально - просто посмотрите на схему попыток. Это должно быть достаточно данных.

что-нибудь еще, и ваша «повышенная безопасность» начинает выглядеть как «расширенные возможности вектора атаки».

Answer 2

Это похоже на чрезмерную инженерию. Я бы просто отслеживал неудачные попытки входа в систему и после $ x количества неудачных попыток входа в систему вы затем блокировали IP-адрес от попытки другого входа в систему в течение 1-24 часов или около того.

Если вы обеспокоены тем, что кто-то нацелен на конкретную учетную запись, вы можете отметить количество неудачных попыток для определенного имени пользователя и затем принять соответствующие меры, такие как ограничение количества неудачных входов в систему для этого имени пользователя до 2 или 3 за 24 часа на любом ip адрес.

Я могу придумать способы, с помощью которых вы можете попытаться обнаружить словарные / грубые атаки с помощью сравнения, но вам придется собирать данные пользователя и сравнивать их с предыдущими попытками, это может быть проблемой безопасности, если вы храните немного с ошибками допустимые пароли в базе данных. Кроме того, для каждого входа в систему потребуется довольно много ресурсов процессора.

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

Хотя теперь, когда я думаю об этом немного больше, метод предотвращения также может быть способом отказа в обслуживании, блокируя пользователям возможность входа в систему, поэтому примите это к сведению.

Answer 3

Регистрация необработанных паролей кажется очень плохой идеей, как вы сами отметили.

Не могли бы вы просто зарегистрировать имя пользователя и время неудачных попыток входа без фактической регистрации паролей? Было бы довольно очевидно, если бы была грубая атака, если бы в течение короткого времени были предприняты сотни попыток входа Вы также можете войти в IP-адрес.

Answer 4

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

В моем ограниченном опыте вы взяли бы введенный пользователем пароль, хэшировали его (с солью, той же солью, которая использовалась для хеширования сохраненного пароля) и сравнивали с сохраненным хешированным значением. Если проверка не пройдена (хэшированные значения не равны), зарегистрируйте текстовую версию пароля, использованного для попытки.

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

Answer 5

Как уже отмечали другие, это очень плохая идея хранить незашифрованные пароли, и правильное решение - ограничить / ограничить попытки входа в систему.

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

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

Ужасная правда в том, что пароли - плохой способ подтвердить личность, но альтернативы более дороги и громоздки.

Answer 6

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

Тем не менее, я не думаю, что анализ паролей даст какую-либо полезную информацию.

Answer 7

Как уже говорили, регистрация паролей - плохая идея.

Гораздо лучшая идея - попытки входа в систему газа .

Если все сделано правильно, регулирование может значительно снизить риск парольных атак, а также ограничить атаки типа «отказ в обслуживании».

Answer 8

Думал ли ты об установленном количестве входов в систему тогда по времени? Если при входе в систему произойдет сбой 3x / 5x / 10x, при необходимости полностью заблокируйте учетную запись на указанный период времени.

Делая это, вы делаете кропотливую работу настолько трудоемкой, что они, вероятно, просто не потрудятся попробовать. Регистрация каждой неудачной попытки, и даже более того, даже мысль паролей в виде простого текста - плохая идея. Скорее используйте следующую аналогию:

"If I make my house so difficult to get into, they'll try the neighbours first."

Сделайте жизнь грубой силы трудной, и они не будут беспокоить.

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

НТН,

Кайл

Answer 9

В зависимости от выбранного протокола аутентификации, например, в случае Kerberos , у вас может даже не быть доступа к введенному паролю.