Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Отправлять свои пароли POST'ом. Нет, спасибо.
Я, возможно, отстал от индустрии сайтостроения, но как отправлять их правильно?
Я к индустрии сайтостроения отношения практически не имею, но для подобного сервиса, вероятно, стоило использовать полностью автономное решение на JS.
Это ведь не сервис. Это бандл для Symfony framework который просто имеет демку как он работает)
Хорошо, скорее всего, все так и есть. Но, как вы говорите, для простого пользователя, скачать и развернуть у себя демку вряд ли будет легче, чем скачать файл с паролями и воспользоваться поиском по нему. А предлагать такому пользователю проверять пароль, отправляя его на какой-то сторонний сервис, выглядит, как минимум, подозрительно.
Я ведь и не предлагаю пользователям (или кому то другому) проверять пароль используя демку)) Речь идет о внедрении в проекты, которые будут это делать для своих же пользователей.
Да даже само скачивание такой демки и разворачивание её у себя не менее подозрительно. Учитывая изощрённость методов добычи данных для доступа — всё может оказаться совсем не тем, чем кажется.
Кстати, есть такой сайт: https://howsecureismypassword.net/ Насколько я вижу тут все в js. И никакой отправки на сервер нет.
Он правда проверяет по 10 000 распространенных паролей.
Он правда проверяет по 10 000 распространенных паролей.
В принципе, я с этим утверждением согласен, но никто не мешает авторам автономного решения на JS подключить как бы невзначай аналитический сервис (хоть бы и Google Analytics), и отправить чего лишнего. Впрочем, можно поставить браузерное расширение, блокирующее сбор аналитики, но и тут нельзя быть уверенным на 100% в его прозрачности.
Я тут было подумал, что обрубить сбор информации можно гораздо проще и произачнее — отключиться от сети (авиарежим, WiFi, и т. п.), и выполнить проверку оффлайн, но ведь и тут засада — если сайт использует localStorage, Service Workers или некую другую комбинацию техник, то собранную информацию можно придержать до первого удобного случая и отправить позже.
По идее, добавление предосторожности в виде Incognito Mode поставит шах и мат в этой комбинации, так как не удастся накопить информацию в оффлайн-режиме, но и тут надо быть осторожным и не забыть закрыть все вкладки посещенного сайта-проверялки до того как вы включите интернет.
Я это все веду к тому, что «простому пользователю» для обеспечения безопасной проверки пароля в рамках некого веб-сервиса (причем безотносительно метода его доставки — автономное JS-приложение или почти чистое серверное) придется овладеть очень непростыми познаниями в предметной области или довериться экспертам, что тоже имеет свою цену и риски.
P. S. Кстати, можно было бы добавить в статью прямые ссылки на текстовые базы паролей 100,000 и 1,000,000, «для максимального эффекта».
Я тут было подумал, что обрубить сбор информации можно гораздо проще и произачнее — отключиться от сети (авиарежим, WiFi, и т. п.), и выполнить проверку оффлайн, но ведь и тут засада — если сайт использует localStorage, Service Workers или некую другую комбинацию техник, то собранную информацию можно придержать до первого удобного случая и отправить позже.
По идее, добавление предосторожности в виде Incognito Mode поставит шах и мат в этой комбинации, так как не удастся накопить информацию в оффлайн-режиме, но и тут надо быть осторожным и не забыть закрыть все вкладки посещенного сайта-проверялки до того как вы включите интернет.
Я это все веду к тому, что «простому пользователю» для обеспечения безопасной проверки пароля в рамках некого веб-сервиса (причем безотносительно метода его доставки — автономное JS-приложение или почти чистое серверное) придется овладеть очень непростыми познаниями в предметной области или довериться экспертам, что тоже имеет свою цену и риски.
P. S. Кстати, можно было бы добавить в статью прямые ссылки на текстовые базы паролей 100,000 и 1,000,000, «для максимального эффекта».
Так вот же они на гитхабе: https://github.com/Nidhognit/PassSecurityBundle/tree/master/DataFiles
Скачайте код и разверните свое приложение, как я и рекомендую в статье, в чем же проблема?
В наше время цифрового мошенничества и всякого фишинга — вариант проверки пароля на сайте просто идеален для ловли нужных паролей.
Для этого открыт исходный код, и указана рекомендация проверять локально, этот код скачав себе. Это же демка, а не рабочий сайт.
Тем не менее, многие могут ломануться изучать на этой демке «боевые» пароли, может привести к печальным последствиям. Также можно на основе этой демки собрать «сайт для проверки пароля» и набивать собственный сборник паролей, после чего ломиться по «засвеченным» адресам. Конечно, можно такую подставу орагнизовать и другими способами, но тем не менее.
Скачивание локально также не исключает возможности подмены дистриба на «скомпрометированный» и после чего «выловить» нужные пароли. А при локальном исполнении можно и логины послушать в сети, скинув их «куда следует».
Может быть, конечно, я просто параноик и везде вижу только угрозу, но вот такой вот штук мне доверия вообще не внушает.
Скачивание локально также не исключает возможности подмены дистриба на «скомпрометированный» и после чего «выловить» нужные пароли. А при локальном исполнении можно и логины послушать в сети, скинув их «куда следует».
Может быть, конечно, я просто параноик и везде вижу только угрозу, но вот такой вот штук мне доверия вообще не внушает.
Можно сделать форк, если есть страх что оригинал будет изменен, или просто реализовать свой собственный поиск, там все очень просто.
Я обновил статью чтобы обозначить что демка — это просто демка, а не рабочий сервис.
По поводу собственного сайт по сборке паролей, я не очень понимаю как IP (часто динамические и одинаковые для большой группы пользователей) + пароль могут скомпрометировать определенного пользователя, но такой сайт может возникнуть не зависимо от того есть демка, или ее нет.
Я обновил статью чтобы обозначить что демка — это просто демка, а не рабочий сервис.
По поводу собственного сайт по сборке паролей, я не очень понимаю как IP (часто динамические и одинаковые для большой группы пользователей) + пароль могут скомпрометировать определенного пользователя, но такой сайт может возникнуть не зависимо от того есть демка, или ее нет.
Если ИП — динамика, да ещё и «серый» — то проблем не так и много. А вот если он «белый», что у очень многих организаций, и админ по какой-то причине туда сунулся проверять свой «боевой» пароль (причина по сути не важна) — «профит» можно поиметь.
Опять же на «сайте-подложке» можно организовать «введите почту, а мы вам вышлем результат» — добраться до логинов в таком случае уже вообще не проблема.
Опять же на «сайте-подложке» можно организовать «введите почту, а мы вам вышлем результат» — добраться до логинов в таком случае уже вообще не проблема.
Не нашел куда ввести логин.
39 — jennifer
Недавно была противоположная этой статья, процитирую первый комментарий:
Я пользователь.
Я хочу свободно заходить на этот сайт не задумываясь над паролем.
Я не введу никогда сюда свои персональные данные или номер банковской карты.
Почему. Мне. Нельзя. Использовать. Простой. Словарный. Пароль?
йцукен
Congratulations! Your password is a hard nut to crack
как-тот так:)
Congratulations! Your password is a hard nut to crack
как-тот так:)
Прочитал как "Congratulations! Your password is a hard not to crack"
Можно кстати запилить страницу на которой все эти пароли в алфавитном порядке и пользователь будет просто прокручивать страницу пока не найдет нужное место где может быть его пароль. И тогда не понятно будет нашёл ли он его и если да то какой из тех что на странице.
Не туда ответил ну пусть уж будет здесь.
Проще подгрузить их в js файле на страницу и сделать офлайн поиск. Да, загрузка сожрет десяток метров трафика и займет приличное время, но для настольного компьютера не критично.
Сделал так. Полностью совпадения не нашёл но есть у которого первых 5 символов те же.
https://github.com/Nidhognit/PassSecurityBundle/tree/master/DataFiles
Отличная идея с сервисом, нужно двигать ее дальше.
Как будет действовать хакер, который хочет заняться перебором? Он не будет просто исходить из списка самых популярных 100к\1м\10м паролей — он найдет все возможные «сливы» паролей за всё время жизни Интернета, и будет проходить по ним от начала и до конца. Мне кажется, нужно действовать аналогичным образом.
Идеальный сервис был бы тот, который включает в себя максимальную базу всех существовавших сливов паролей (желательно, конечно, в открытом виде, для офлайн поиска в txt), чтобы можно проверить пароль не на отсутствие в списке самых частых, а вообще на отсутствие аналогов в мире.
Впрочем, насколько я помню, подобные зарубежные сервисы уже были — возможно, в комментариях кто-нибудь поделится ссылкой (желательно опенсорс, если таковые есть).
По теме статьи, в идеальном варианте перебор паролей убивается на корню банальным ограничением запросов, который должен быть в любом уважающем себя сервисе авторизации.
Как будет действовать хакер, который хочет заняться перебором? Он не будет просто исходить из списка самых популярных 100к\1м\10м паролей — он найдет все возможные «сливы» паролей за всё время жизни Интернета, и будет проходить по ним от начала и до конца. Мне кажется, нужно действовать аналогичным образом.
Идеальный сервис был бы тот, который включает в себя максимальную базу всех существовавших сливов паролей (желательно, конечно, в открытом виде, для офлайн поиска в txt), чтобы можно проверить пароль не на отсутствие в списке самых частых, а вообще на отсутствие аналогов в мире.
Впрочем, насколько я помню, подобные зарубежные сервисы уже были — возможно, в комментариях кто-нибудь поделится ссылкой (желательно опенсорс, если таковые есть).
По теме статьи, в идеальном варианте перебор паролей убивается на корню банальным ограничением запросов, который должен быть в любом уважающем себя сервисе авторизации.
Идея в принципе лишена смысла, поскольку непонятно какие длины паролей брать. К тому же можно извратиться ASCII-символами.
По теме последнего абзаца вашего комментария. Речь идет не только о переборе паролей на живом сайте, но больше о профилактике от раскалывания украденной базы паролей в сжатые сроки — насколько я понимаю, имея на руках хэши, соли и словарь часто используемых паролей, можно в сжатые сроки подобрать около 5-10% паролей минимум. То есть подобная валидация — это последняя линия защиты, когда база уже угнана, но владельцы сайта еще не знают об этом и не успели сбросить всем пользователям пароли и разослать публичное письмо об утечке. Не секрет, что с крупными сервисами это периодически происходит, так что эта линия защиты имхо имеет право на жизнь.
Не пойму проблем с проверкой. Скачать файл с паролями (скачал на 1 000 000), открыл в блокноте (да, да блокнот Windows 7 его за 15 секунд открыл), и через Ctrl+F ввёл свой пароль.
Долго использовал пароль qwerty (занял 4 место) и 1q2w3e4r (256 место). После того как ломанули почту пересмотрел свои пароли. Теперь надежные.
Читаю вторую статью про пароли за неделю и не могу «догнать» проблему. Так все усложнили — пароли, словари, нужно нагибать пользователей чтоб придумывали пароли сложнее, а то подбирают быстро и т.п. А еще мощности компьютеров растут — прямо ужас. На этой теме можно зарабатывать. :) Но вот что мешает поступить проще?
Введите таймаут на ответ по авторизации на 10 секунд, к примеру. Пользователь же входит не сто раз в день, 10 секунд потерпит, особенно, если ему мультик показать. А вот перебирать даже по словарю из 1 000 000 паролей уже замучаешься. На это уйдет больше 3 лет непрерывного взлома, который можно не только засечь по логам, но еще и программно. Да можно и не засекать — попросить пользователей менять пароли раз в год с одним условием — чтоб новый пароль не совпадал со старым, одним старым прошлым паролем… и все… взломать можно будет только случайно.
Почему так сделать то нельзя?
Введите таймаут на ответ по авторизации на 10 секунд, к примеру. Пользователь же входит не сто раз в день, 10 секунд потерпит, особенно, если ему мультик показать. А вот перебирать даже по словарю из 1 000 000 паролей уже замучаешься. На это уйдет больше 3 лет непрерывного взлома, который можно не только засечь по логам, но еще и программно. Да можно и не засекать — попросить пользователей менять пароли раз в год с одним условием — чтоб новый пароль не совпадал со старым, одним старым прошлым паролем… и все… взломать можно будет только случайно.
Почему так сделать то нельзя?
Что помешает сделать 1000 параллельных запросов на сервер? Если пароль очень простой, этого хватит чтобы угадать, если сервер слабый, этого хватит чтобы его положить.
Кроме того, такая «тяжелая страница» — отличный вариант для DDOS атаки.
Кроме того, такая «тяжелая страница» — отличный вариант для DDOS атаки.
А что мешает отклонять все запросы по одному логину кроме самого первого в течении тех 10 секунд хотя бы?
Почему сервер должен лечь и ДДОС? Т.е. имеется в виду, что сервер пока общается по паролю с одним пользователем, не может ответить другому? А если у того пинг хреновый, то сервер тоже подвисает? :) Что-то тут не так. Ну можно как-то иначе отдалить по времени ответ на авторизацию, чтоб сервер не нагружался.
Или, как тоже уже много раз делалось, при неудачных запросах по одному логину повторный запрос разрешать только через минуту. Пользователь, если ошибся, не сильно устанет, а вот взломщик сильно. Ограничить опять же число попыток по логину в 10 штук в сутки и все.
Мне кажется такие методы намного более действенны, чем увеличивать сложность пароля, привнося этим кучу проблем для пользователя и не давая реальной защиты навсегда, а лишь пока не вырастет мощность компьютеров по перебору…
Почему сервер должен лечь и ДДОС? Т.е. имеется в виду, что сервер пока общается по паролю с одним пользователем, не может ответить другому? А если у того пинг хреновый, то сервер тоже подвисает? :) Что-то тут не так. Ну можно как-то иначе отдалить по времени ответ на авторизацию, чтоб сервер не нагружался.
Или, как тоже уже много раз делалось, при неудачных запросах по одному логину повторный запрос разрешать только через минуту. Пользователь, если ошибся, не сильно устанет, а вот взломщик сильно. Ограничить опять же число попыток по логину в 10 штук в сутки и все.
Мне кажется такие методы намного более действенны, чем увеличивать сложность пароля, привнося этим кучу проблем для пользователя и не давая реальной защиты навсегда, а лишь пока не вырастет мощность компьютеров по перебору…
.
Автор, такие подсказки дает уютная жжшечка. Там словарный пароль не поставить. Причем сравнение идет с существующей базой юзеров в том числе.
А насчет пароля 18 единиц — он очень плох: его раскусит любой сторонний наблюдатель. перебирать потребуется только количество единиц, если кто-то увидел как такой пароль вводят.
А насчет пароля 18 единиц — он очень плох: его раскусит любой сторонний наблюдатель. перебирать потребуется только количество единиц, если кто-то увидел как такой пароль вводят.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Часто используемые пароли: как не попасться самому и уберечь пользователей