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

«Не менее 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 комментариев
Написать комментарий...
Ася Власова

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

Ответить
Развернуть ветку
Виталий Воробьев

Гугл потихоньку продивигает Google passkeys. Аутентификация через сканирование qr кода с телефона. У технологии много плюсов, но, как и все продукты гугл, она может умереть в зачатке.

Ответить
Развернуть ветку
Невероятный Блондин

Это продукт Apple изначально.
Они объединились с Google и Microsoft на базе стандарта FIDO альянса, W3O.
И этот стандарт (Passkeys) уже никуда не денется, не переживай. Все крупные тех. гиганты уже добавили к себе этот метод авторизации.

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

P.S. Необязательно через QR, на Apple устройствах можно и через Face ID/ Touch ID

Ответить
Развернуть ветку
Vikarti Anatra

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

Вот только насчет "всех крупных"... Яндекс с ВК видимо не крупные? Где у них поддержка?
Ладно, где у Facebook поддержка именно Passkeys?( ключи безопасности аппаратные и TOTP-генераторы кодов - поддерживаются но именно в рамках штатной двухфакторки, пароль все равно вводить надо)

Ответить
Развернуть ветку
Невероятный Блондин

Хаха, ну ладно, не все ещё 😀

Но и Яндекс и ВК — больше не техгиганты, а госкомпании, к тому же российские, с ними можно даже не надеяться.

У этих уже есть Adobe, PayPal, Shopify, Godaddy, Nvidia, Wordpress, Robinhood и тд.

Для FB нужно выбрать Security key.
Тоже самое для Twitter, и прочих где это есть.

К сожалению имплементация идет медленно

Ответить
Развернуть ветку
Vikarti Anatra

Security key это НЕ Passkeys, это именно аппаратный ключ. У меня вот привязать именно телефон на андроиде - не вышло через "Security key", как и добится входа _только_ вводом логина и подтверждением с телефона

Ответить
Развернуть ветку
Невероятный Блондин

При создании ключа может предложить использовать passkey в качестве флешки.
Зависит от реализации разработчиками.

По идее, webauthn можно использовать с passkeys.

Но да, это половинчатое решение как второй фактор.
Лучше чтобы просто поддержку passkeys добавляли.

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