Применение стойких хеш-алгоритмов и “соление” паролей в разы усложняет задачу их грубого перебора, поэтому следующей легкой целью злоумышленников становятся распространенные среди широких масс пароли, которые несложно подобрать “по словарю”. Такой подход и проще, и результативнее, ведь не важно насколько стойкий у вас алгоритм хеширования, популярные пароли могут составить львиную долю всей украденной базы, и раз их можно перебрать за минимальное время, то есть все шансы успеть ими воспользоваться прежде, чем утечка будет обнаружена и пользователи сменят пароли.
Можно ли с этим бороться? — легко! Борются ли с этим? — не встречал. Значит, пора начать.
На многих ресурсах к форме регистрации подключают валидатор сложности пароля, но, к сожалению, сам подсчет является спорным и субъективным — зачем-то требуются спецсимволы, большие и малые регистры, при этом не всегда учитывается то, что длина пароля защищает его куда больше. С другой стороны, длинный но простой пароль может быть часто используемым, что никак не делает его безопасным. Это немного отходит от основной темы статьи, поэтому о длине пароля — под спойлером.
Для примера и демонстрации идеи которую я хочу донести, я возьму несколько паролей, например таких:
- KCEvcefv4v (10 Символов)
- 111111111111111111 (18 символов)
- yTp3HHuuCTo9kyTp3HHuuCTo9kyTp3HHuuCTo9k (39 символов)
Сложность полного перебора для этих паролей составляет:
- 62^10 = 839E+15 вариантов
- 10^18 = 1000E+15 вариантов
- 62^39 = … 8E+69 вариантов.
Сравнив первый и второй пароли, получаем, что длинный пароль из цифр не только оказывается сложнее короткого пароля из букв разного регистра и цифр, но и легче запоминается ввиду того, что это просто 18 единиц. Важно понимать, что так как единички захеширование, и атакующему неизвестно какие символы нужно использовать, то для подбора пароля будут использоваться все варианты символов. Но, если вдруг после прочтения статьи все начнут использовать такой пароль, то реальное время его взлома будет миллисекунды, так как он станет часто используемым.
Остается вопрос — зачем приведен длинный и явно “непробиваемый” пароль в этом списке? Внезапно! “утренний стояк” (yTp3HHuuCTo9k), повторенный три раза и достигающий длины 39 символов, входит в первый миллион часто используемых паролей, и при всей своей сложности прогоняется по списку за секунду,
Но нигде я не видел подсказок типа “эй, друг, этот пароль не то чтобы не сложный, он просто на 10-м месте часто используемых паролей, поэтому на конфиденциальность особо не рассчитывай”.
При определенном желании и сноровке, вы можете найти в интернете кучу бесплатных подборок паролей для просмотра, в том числе и для скачивания. Конечно, для любого специалиста знакомого с консолью и магией “grep” несложно пройтись по файлу с паролями и проверить свой собственный (другой вопрос, что вам скорее всего будет лень, как и мне).
А вот пользователям немного сложнее: они вряд ли тесно знакомы с консолью, у них нет списков часто используемых паролей, и наверняка они даже не подозревают, что с их паролями может быть что-то не так.
Устранять данную несправедливость я решил руководствуясь следующими принципами:
- Максимально простое решение.
- Быстрое решение.
- Возможность гибкой настройки, и работы как с файлами так и БД.
- Научиться писать сторонние бандлы для Symfony
Посмотреть код или установить бандл вы можете по ссылке:
> https://github.com/Nidhognit/PassSecurityBundle
Есть демка, где вы можете проверить пароль (UPD: подразумевается тестовая проверка пароля, и не рекомендуется использование реальных паролей) в режиме онлайн: https://demo-pass-security-bundle.herokuapp.com/
UPD: ВАЖНО! Демка не является сервисом/сайтом/полноценным приложением, и служит только и исключительно для демонстрации работы кода, ссылка на который дана чуть выше. То есть, я в статье расказываю не о сайте где можно проверить пароль, а о решении, которое можно установить себе на проект, и помогать пользователям проверять пароли (как я понял по комментариям это было не очевидно, решил уточнить).
Примечание: В целях обеспечения конфиденциальности, я не храню логи (даже средства логирования не подключаю), не веду статистику, не сохраняю отправленные пароли, а весь код полностью открыт для ознакомления. В качестве платформы для демки выбран heroku.com, отчасти потому, что он со временем убивает сервер и разворачивает его заново с утратой всех промежуточных состояний (поэтому иногда вы можете увидеть 500 при переходе по ссылке, но если обновить страницу, через несколько секунд все будет ок). Однако, я не могу гарантировать полную конфиденциальность — для максимального эффекта разворачивайте проект у себя локально.
Бандл занимается только одной вещью — проверяет пароль по списку, и возвращает номер, под которым тот был найден, либо null.
Изначально, конечно, было желание написать полноценный валидатор пароля, с оценкой сложности и вынесением вердикта, но я остановился на простом поиске позиции, ведь для каждого проекта свои требования к безопасности (хотя, по моему мнению, если пароль найден в списке, то, независимо от его места, он не безопасен, но у вас может быть другое мнение).
В бандл вшиты два файла со списками паролей на 100 тысяч (используется по умолчанию) и на 1 миллион. К слову, если у вас есть интересные списки часто используемых паролей, и вы не против ими поделиться с общественностью, буду благодарен.
Немного об опыте использования
После того как я написал бандл, я протестировал на нем все свои пароли (да, до “grep” руки так и не дошли). С удивлением обнаружил, что один из домашних паролей, несмотря на грозный вид и длину более чем 11 символов, занял совсем не почетное место в списке.
Друзья и знакомые, которые просматривали демку, также обнаружили некоторые свои пароли в числе небезопасных, и пока лидирует знакомый, пароль которого был найден на 39-м месте. Кто сможет опередить его, расскажите :)
Комментарии (43)
Isfandiar
15.03.2017 14:16+2В наше время цифрового мошенничества и всякого фишинга — вариант проверки пароля на сайте просто идеален для ловли нужных паролей.
Nidhognit
15.03.2017 14:25Для этого открыт исходный код, и указана рекомендация проверять локально, этот код скачав себе. Это же демка, а не рабочий сайт.
Isfandiar
15.03.2017 14:51Тем не менее, многие могут ломануться изучать на этой демке «боевые» пароли, может привести к печальным последствиям. Также можно на основе этой демки собрать «сайт для проверки пароля» и набивать собственный сборник паролей, после чего ломиться по «засвеченным» адресам. Конечно, можно такую подставу орагнизовать и другими способами, но тем не менее.
Скачивание локально также не исключает возможности подмены дистриба на «скомпрометированный» и после чего «выловить» нужные пароли. А при локальном исполнении можно и логины послушать в сети, скинув их «куда следует».
Может быть, конечно, я просто параноик и везде вижу только угрозу, но вот такой вот штук мне доверия вообще не внушает.Nidhognit
15.03.2017 15:05Можно сделать форк, если есть страх что оригинал будет изменен, или просто реализовать свой собственный поиск, там все очень просто.
Я обновил статью чтобы обозначить что демка — это просто демка, а не рабочий сервис.
По поводу собственного сайт по сборке паролей, я не очень понимаю как IP (часто динамические и одинаковые для большой группы пользователей) + пароль могут скомпрометировать определенного пользователя, но такой сайт может возникнуть не зависимо от того есть демка, или ее нет.Isfandiar
15.03.2017 15:12+1Если ИП — динамика, да ещё и «серый» — то проблем не так и много. А вот если он «белый», что у очень многих организаций, и админ по какой-то причине туда сунулся проверять свой «боевой» пароль (причина по сути не важна) — «профит» можно поиметь.
Опять же на «сайте-подложке» можно организовать «введите почту, а мы вам вышлем результат» — добраться до логинов в таком случае уже вообще не проблема.
Fen1kz
15.03.2017 15:56+2Недавно была противоположная этой статья, процитирую первый комментарий:
Я пользователь.
Я хочу свободно заходить на этот сайт не задумываясь над паролем.
Я не введу никогда сюда свои персональные данные или номер банковской карты.
Почему. Мне. Нельзя. Использовать. Простой. Словарный. Пароль?
Loki3000
15.03.2017 16:16йцукен
Congratulations! Your password is a hard nut to crack
как-тот так:)
ivan386
15.03.2017 16:55Можно кстати запилить страницу на которой все эти пароли в алфавитном порядке и пользователь будет просто прокручивать страницу пока не найдет нужное место где может быть его пароль. И тогда не понятно будет нашёл ли он его и если да то какой из тех что на странице.
Не туда ответил ну пусть уж будет здесь.
Nidhognit
15.03.2017 17:13Проще подгрузить их в js файле на страницу и сделать офлайн поиск. Да, загрузка сожрет десяток метров трафика и займет приличное время, но для настольного компьютера не критично.
ivan386
15.03.2017 17:17Поиск по странице в браузер встроен. И опять же его надо куда-то вводить что рискованно. А тут визульный поиск.
ivan386
15.03.2017 17:14Сделал так. Полностью совпадения не нашёл но есть у которого первых 5 символов те же.
dankovsky
15.03.2017 17:39Отличная идея с сервисом, нужно двигать ее дальше.
Как будет действовать хакер, который хочет заняться перебором? Он не будет просто исходить из списка самых популярных 100к\1м\10м паролей — он найдет все возможные «сливы» паролей за всё время жизни Интернета, и будет проходить по ним от начала и до конца. Мне кажется, нужно действовать аналогичным образом.
Идеальный сервис был бы тот, который включает в себя максимальную базу всех существовавших сливов паролей (желательно, конечно, в открытом виде, для офлайн поиска в txt), чтобы можно проверить пароль не на отсутствие в списке самых частых, а вообще на отсутствие аналогов в мире.
Впрочем, насколько я помню, подобные зарубежные сервисы уже были — возможно, в комментариях кто-нибудь поделится ссылкой (желательно опенсорс, если таковые есть).
По теме статьи, в идеальном варианте перебор паролей убивается на корню банальным ограничением запросов, который должен быть в любом уважающем себя сервисе авторизации.Isfandiar
15.03.2017 17:46Идея в принципе лишена смысла, поскольку непонятно какие длины паролей брать. К тому же можно извратиться ASCII-символами.
noomorph
15.03.2017 17:49По теме последнего абзаца вашего комментария. Речь идет не только о переборе паролей на живом сайте, но больше о профилактике от раскалывания украденной базы паролей в сжатые сроки — насколько я понимаю, имея на руках хэши, соли и словарь часто используемых паролей, можно в сжатые сроки подобрать около 5-10% паролей минимум. То есть подобная валидация — это последняя линия защиты, когда база уже угнана, но владельцы сайта еще не знают об этом и не успели сбросить всем пользователям пароли и разослать публичное письмо об утечке. Не секрет, что с крупными сервисами это периодически происходит, так что эта линия защиты имхо имеет право на жизнь.
yanab
16.03.2017 13:19Не пойму проблем с проверкой. Скачать файл с паролями (скачал на 1 000 000), открыл в блокноте (да, да блокнот Windows 7 его за 15 секунд открыл), и через Ctrl+F ввёл свой пароль.
Nidhognit
16.03.2017 13:21Никаких) речь была о том чтобы подсказывать пользователям при регистрации, ведь далеко не каждый захочет скачивать и проверять сам.
nikolay206
16.03.2017 15:38Долго использовал пароль qwerty (занял 4 место) и 1q2w3e4r (256 место). После того как ломанули почту пересмотрел свои пароли. Теперь надежные.
Canep7
17.03.2017 10:53Читаю вторую статью про пароли за неделю и не могу «догнать» проблему. Так все усложнили — пароли, словари, нужно нагибать пользователей чтоб придумывали пароли сложнее, а то подбирают быстро и т.п. А еще мощности компьютеров растут — прямо ужас. На этой теме можно зарабатывать. :) Но вот что мешает поступить проще?
Введите таймаут на ответ по авторизации на 10 секунд, к примеру. Пользователь же входит не сто раз в день, 10 секунд потерпит, особенно, если ему мультик показать. А вот перебирать даже по словарю из 1 000 000 паролей уже замучаешься. На это уйдет больше 3 лет непрерывного взлома, который можно не только засечь по логам, но еще и программно. Да можно и не засекать — попросить пользователей менять пароли раз в год с одним условием — чтоб новый пароль не совпадал со старым, одним старым прошлым паролем… и все… взломать можно будет только случайно.
Почему так сделать то нельзя?Nidhognit
17.03.2017 10:54Что помешает сделать 1000 параллельных запросов на сервер? Если пароль очень простой, этого хватит чтобы угадать, если сервер слабый, этого хватит чтобы его положить.
Кроме того, такая «тяжелая страница» — отличный вариант для DDOS атаки.Canep7
17.03.2017 13:10А что мешает отклонять все запросы по одному логину кроме самого первого в течении тех 10 секунд хотя бы?
Почему сервер должен лечь и ДДОС? Т.е. имеется в виду, что сервер пока общается по паролю с одним пользователем, не может ответить другому? А если у того пинг хреновый, то сервер тоже подвисает? :) Что-то тут не так. Ну можно как-то иначе отдалить по времени ответ на авторизацию, чтоб сервер не нагружался.
Или, как тоже уже много раз делалось, при неудачных запросах по одному логину повторный запрос разрешать только через минуту. Пользователь, если ошибся, не сильно устанет, а вот взломщик сильно. Ограничить опять же число попыток по логину в 10 штук в сутки и все.
Мне кажется такие методы намного более действенны, чем увеличивать сложность пароля, привнося этим кучу проблем для пользователя и не давая реальной защиты навсегда, а лишь пока не вырастет мощность компьютеров по перебору…
MaxxxZ
18.03.2017 10:08Автор, такие подсказки дает уютная жжшечка. Там словарный пароль не поставить. Причем сравнение идет с существующей базой юзеров в том числе.
А насчет пароля 18 единиц — он очень плох: его раскусит любой сторонний наблюдатель. перебирать потребуется только количество единиц, если кто-то увидел как такой пароль вводят.
Elsedar
Отправлять свои пароли POST'ом. Нет, спасибо.
Lamaster
Я, возможно, отстал от индустрии сайтостроения, но как отправлять их правильно?
Elsedar
Я к индустрии сайтостроения отношения практически не имею, но для подобного сервиса, вероятно, стоило использовать полностью автономное решение на JS.
Nidhognit
Это ведь не сервис. Это бандл для Symfony framework который просто имеет демку как он работает)
Elsedar
Хорошо, скорее всего, все так и есть. Но, как вы говорите, для простого пользователя, скачать и развернуть у себя демку вряд ли будет легче, чем скачать файл с паролями и воспользоваться поиском по нему. А предлагать такому пользователю проверять пароль, отправляя его на какой-то сторонний сервис, выглядит, как минимум, подозрительно.
Nidhognit
Я ведь и не предлагаю пользователям (или кому то другому) проверять пароль используя демку)) Речь идет о внедрении в проекты, которые будут это делать для своих же пользователей.
Elsedar
Nidhognit
Согласен, не очевидная формулировка, изменил описание
Isfandiar
Да даже само скачивание такой демки и разворачивание её у себя не менее подозрительно. Учитывая изощрённость методов добычи данных для доступа — всё может оказаться совсем не тем, чем кажется.
Nidhognit
Демка состоит из десятка файлов, которые вы можете просмотреть и проанализировать.
Можете просто подключить код к фреймвору, который дан по первой ссылке, там и вовсе немного кода.
nmk2002
Кстати, есть такой сайт: https://howsecureismypassword.net/ Насколько я вижу тут все в js. И никакой отправки на сервер нет.
Он правда проверяет по 10 000 распространенных паролей.
Nidhognit
У них подключена гугл аналитика со всеми вытекающими рисками)
noomorph
В принципе, я с этим утверждением согласен, но никто не мешает авторам автономного решения на JS подключить как бы невзначай аналитический сервис (хоть бы и Google Analytics), и отправить чего лишнего. Впрочем, можно поставить браузерное расширение, блокирующее сбор аналитики, но и тут нельзя быть уверенным на 100% в его прозрачности.
Я тут было подумал, что обрубить сбор информации можно гораздо проще и произачнее — отключиться от сети (авиарежим, WiFi, и т. п.), и выполнить проверку оффлайн, но ведь и тут засада — если сайт использует localStorage, Service Workers или некую другую комбинацию техник, то собранную информацию можно придержать до первого удобного случая и отправить позже.
По идее, добавление предосторожности в виде Incognito Mode поставит шах и мат в этой комбинации, так как не удастся накопить информацию в оффлайн-режиме, но и тут надо быть осторожным и не забыть закрыть все вкладки посещенного сайта-проверялки до того как вы включите интернет.
Я это все веду к тому, что «простому пользователю» для обеспечения безопасной проверки пароля в рамках некого веб-сервиса (причем безотносительно метода его доставки — автономное JS-приложение или почти чистое серверное) придется овладеть очень непростыми познаниями в предметной области или довериться экспертам, что тоже имеет свою цену и риски.
P. S. Кстати, можно было бы добавить в статью прямые ссылки на текстовые базы паролей 100,000 и 1,000,000, «для максимального эффекта».
nmk2002
Так вот же они на гитхабе: https://github.com/Nidhognit/PassSecurityBundle/tree/master/DataFiles
Nidhognit
Скачайте код и разверните свое приложение, как я и рекомендую в статье, в чем же проблема?