Проверка паролей по словарям и базам утекших данных

«Не менее 8 символов, включая цифры и заглавные буквы», — требует очередной сервис. «Gfhjkm2023», — набирает пользователь, не задумываясь, что он уже взломан.

Привет! Мы — RooX, российский разработчик веб-решений. У нас есть своя система аутентификации и авторизации RooX UIDM. И мы умеем проверять пароли по словарям и базам утекших данных.

Зачем вообще проверять пароли по базам? Чтобы вовремя предложить или даже заставить пользователя сменить пароль на более безопасный.

В чем опасность паролей? Опасность не в паролях, а в дизайне человека. Чтобы защитить что-то паролем, человек должен этот пароль а) придумать и б) помнить. Сервисов, в которые нужно логиниться, у современного пользователя, не один и не два. Придумывать и помнить много разных сложных паролей человеку трудно, он оптимизирует эти процессы — массово сочиняет простые пароли, а также использует одинаковые или малоотличающиеся комбинации символов для нескольких сервисов. А то, что просто придумать, просто и взломать.

Что такое проверка пароля по словарям и базам утекших данных? Если коротко, это сверка паролей и/или логинов со списком часто используемых или скомпрометированных. Алгоритмы поиска на совпадение со словарными паролями могут быть не 1-к-1 (например, без учета регистра или без учета цифр и спецсимволов).

Откуда берутся словари и базы утекших данных? Их составляют специально обученные и мотивированные люди ) Например, эксперт по безопасности из Microsoft Трой Хант создал и поддерживает сервис утекших паролей Have I Been Pwned. Есть и другие подобные сервисы: Firefox Monitor, DeHashed, GhostProject, LeakCheck. Это не просто и не все такие сервисы выживают, например, BreachAlarm остановил работу после 10 лет.

Некоторые компании создают и поддерживают свои непубличные базы.

Первые экраны сайтов Have I Been Pwned, DeHashed, LeakCheck, GhostProject.

Что касается словарных паролей, они создаются и обогащаются за счет анализа содержимого утечек. Например, российский сервис разведки утечек данных и мониторинга даркнета DLBI (Data Leakage & Breach Intelligence) ежегодно публикует исследования логинов и паролей пользователей. По их данным от февраля 2023 года топ-10 самых популярных паролей по всем утечкам с 2017 года состоит из: 123456, 123456789, qwerty123, 12345, qwerty, qwerty1, password, 12345678, 111111 и 1q2w3e.

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

Какой самый большой слив на данный момент? Лето 2021, файл RockYou2021.txt, выложен пользователем с одноименным ником RockYou2021, объем ~100 ГБ, 8,4 млрд паролей внутри (8 459 060 239 уникальных записей). Логинов в файле нет, только пароли размером от 6 до 20 символов, включая сложные пароли со спецсимволами.

А разве пароли хранятся не в зашифрованном виде? Должны, но не всегда их хранят в зашифрованном виде. Вот, например, широко известная соцсеть в 2019 году призналась, что «пароли пользователей хранились во внутренней базе данных в читаемом формате».

Что будет, если украдут зашифрованный пароль? Если алгоритм шифрования не взломан и пароль не словарный, то ничего не будет. Но достаточное число сервисов шифровало (или продолжает шифровать) пароли алгоритмами MD5 и SHA1, а они, увы, уже взломаны.

Как хакеры используют эти базы? Простым перебором ищут среди пользователей того или иного сервиса тех, кто поленился придумать надежный пароль. Или берут известные в результате утечки данные пользователя с одного сервиса (логин и пароль) и применяют такую же комбинацию на других сервисах.

От перебора нас должна спасти капча, разве нет? Стандартные средства защиты от перебора (капча или автоматическая блокировка после нескольких неверных попыток ввода) могут не сработать, так как в таких случаях идет не перебор разных паролей для одного логина, а разных логинов для одного пароля.

Может, тогда нужно отказаться от паролей? Может, но не сейчас. Конечно, отчеты консалтеров о трендах мира аутентификации наполнены прогнозами о беспарольном будущем. Но это будущее еще не наступило.

Какие системы отвечают за проверки по словарям и базам утекших паролей? Это системы управления доступом. В аббревиатурах, которые обозначают классы этих систем, есть некоторая неоднозначность, но в целом встречаются следующие:

  • IDM (Identity management),
  • IAM (Identity and Access Management),
  • IGA (Identity Governance and Administration) (скорее, на международном рынке),
  • CIAМ (Customer Identity and Access Management) (если говорят о специализированных решений для внешних пользователей – клиентах, партнерах, поставщиках).

Когда делается проверка? Проверки встраиваются в сценарии регистрации, аутентификации и авторизации пользователей в следующие точки:

  • установка, восстановление, смена пароля;
  • вход в систему;
  • выполнение действия, для которого требуется дополнительная авторизация.

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

Что делает система, если обнаружен плохой пароль? Зависит от настроек. В нашей системе аутентификации и авторизации RooX UIDM можно настроить, насколько жесткой будет реакция в той или иной точке сценария. Диапазон — от нежного «просто проинформировать» до неумолимого «не пускать дальше, пока пользователь не сменит пароль на безопасный».

Почему важна проверка по базам словарных и скомпрометированных паролей? В современные редакции стандартов безопасности больше не входят рекомендации использовать в паролях заглавные буквы, цифры и спецсимволы. Главное — это длина пароля и те самые проверки на словарность и скомпроментированность. Кстати, рекомендация регулярно менять пароли тоже устарела. Она + дизайн человека, о котором мы говорили выше, приводят только к ухудшению ситуации. Актуальная рекомендация — менять пароль по факту или подозрению в его скомпроментированности.

Подписывайтесь на блог RooX. Мы специализируемся на цифровых каналах взаимодействия с пользователями (порталы, личные кабинеты, приложения, в том числе, в виде PWA) и управлении доступом к ним (RooX UIDM).

И еще мы завели русскоязычное сообщество в ТГ по аутентификации и авторизации. Присоединяйтесь и задавайте вопросы.

0
80 комментариев
Написать комментарий...
Evgeny Afanasev

Когда успели «взломать» МД5 ?
И как можно взломать хеширование?
Я что-то проспал?

Ответить
Развернуть ветку
Yurii Bychkov

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

Ответить
Развернуть ветку
Evgeny Afanasev

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

Ответить
Развернуть ветку
Alexey Remizov

А почему ее не знаешь? Заводишь на этом сервере учётку, тырешь базу, реверсишь пароли, и на базе своей учетки видишь что ты вводил, и что там хранится в реальности

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
77 комментариев
Раскрывать всегда