Что доказывает локальный список слабых паролей и почему это не поиск по всей сети

Сначала одним предложением — ответ на запрос

Локальный список слабых паролей доказывает только одно: введённую строку можно или нельзя сопоставить с публичным списком высокой частоты, который уже скачан в эту вкладку. Он не доказывает «во всей сети такого не встречали» и не отвечает на вопрос «попала ли моя почта в утечку». Диапазонный запрос Pwned Passwords в Have I Been Pwned (HIBP) — отдельный путь: устройство считает SHA-1 и отправляет только первые пять шестнадцатеричных символов на https://api.pwnedpasswords.com/range/{prefix}; оставшийся суффикс сравнивают на клиенте.

Заметка для разработчиков и администраторов, которые хотят «просто проверить» старый пароль, и для поддержки, которой коллега прислал ссылку на «онлайн-проверку пароля». Она не заменяет инструкцию к проверке пароля и не повторяет общий разбор Network про то, ушёл ли открытый текст при локальном шифровании. Унести отсюда стоит другое: что каждый метод отпускает с устройства, до каких деформаций доходит локальный список и какую фразу попадание или промах можно поставить в тикет.

Три «проверки на утечку» — это не одна и та же работа

Поиск «проверить пароль на утечку» смешивает протоколы, у которых общее только слово на кнопке. Одни сайты делают POST того, что вы только что ввели. Другие вызывают диапазонный API HIBP с k-анонимностью. Третьи скачивают короткий словарь и ищут совпадение в браузере. Все три умеют нарисовать бейдж «не найдено» или «утёк». Строка запроса разная — и разное утверждение, которое потом можно защитить.

OWASP Authentication Cheat Sheet советует на регистрации и смене пароля отсекать распространённые и уже скомпрометированные пароли и прямо называет и Pwned Passwords, и открытые списки вроде SecLists. Документ не ставит знак равенства между локальным списком на восемьсот строк и корпусом из миллиардов хешей. Если в тикете написано только «проверили, не утекал», следующий читатель не поймёт, с какой базой вы сверялись.

У третьего способа сеть всё равно есть: браузер делает GET файла списка. Файл — публичный словарь, не ваш пароль. Считать любой запрос доказательством «пароль ушёл, раз страница ходила в сеть» — путать границу. Считать слово «локально» на странице доказательством — пропустить сайты первого типа.

С чем на самом деле сверяется локальный список

На странице проверки пароля FastPwd список забирается с того же источника по пути data/leaked-top10k.txt, затем во вкладке строится таблица «ключ в нижнем регистре → место». Имя файла говорит top10k, потому что так часто называют публичные списки высокой частоты. Откройте ответ и посчитайте непустые строки: их чуть больше восьмисот; в начале стоят 123456, password, qwerty — строки, которые кочуют из дампа в дамп. В продуктовых текстах этот файл не называют «десятью тысячами записей» и не выдают за «все утечки сети».

Поиск — не одно сравнение на равенство. Реализация проходит четыре ступени. Попадание на любой из них красит пароль красным и принудительно ставит оценку «Слабый».

1. Точное совпадение: ввод равен записи списка.
2. Свёртка регистра: сначала нижний регистр, поэтому Password и password — одна запись.
3. Срез хвоста 0–999: qwerty123 сжимается до qwerty, затем ищется снова.
4. Обычный leet: @/4→a, 3→e, 1/!→i, 0→o, 5/$→s, 7→t. Тот же шаг можно прогнать после среза хвостовых цифр.

Если ввод длиннее 128 символов, последние две ступени не запускаются — остаются только точное совпадение и свёртка регистра. Если файл списка не загрузился, страница переходит на встроенный минимум: password, 123456, 12345678, qwerty, admin123, а в строке статуса всё равно написано, что проверка закончилась на этом устройстве. Место в списке нужно только для подсказки: Top 100, Top 500, Top 1,000 или запасной вариант «Публичный список утечек». Это не счётчик HIBP вида «встречался N раз».

NIST SP 800-63B-4 требует от проверяющей стороны при создании учётки и смене пароля сравнивать кандидата целиком со списком распространённых, ожидаемых или уже скомпрометированных паролей — не как подстроку — и не наслаивать сверху отдельный набор правил состава. Локальный список высокой частоты закрывает слой «отрезать то, что подбирают первым». Файл намного меньше словарей, которыми распыляют атаки, и намного меньше хешей утечек, которые HIBP постоянно подмешивает. В июне 2026 года одна только партия June 2026 Stealer Logs добавила около 124 миллионов уникальных паролей. Чуть больше восьмисот публичных частых слов поймают 123456. Они не поймают длинную фразу, которая встретилась только во внутреннем дампе одной компании.

Что отправляет диапазонный запрос HIBP — и чего не отправляет

На собственной странице паролей HIBP написано: промах «не обязательно значит, что пароль хороший; значит лишь то, что его нет в данных, которые держит этот сайт». Протокол описан в API v3 · Pwned Passwords. Клиент хеширует пароль SHA-1 (или NTLM, если mode=ntlm), берёт первые пять шестнадцатеричных символов и делает GET https://api.pwnedpasswords.com/range/{prefix}. Сервер возвращает все суффиксы под этим префиксом и число появлений. Оставшиеся 35 символов сорокасимвольного хеша остаются на устройстве для сравнения.

Опубликованный масштаб можно сверить на месте: диапазонный запрос обычно возвращает около 800 суффиксов; пространство префиксов — 16⁵ = 1 048 576 значений, от 00000 до FFFFF, и каждый префикс должен ответить HTTP 200, а не 404. Необязательный заголовок Add-Padding: true добивает ответ до 800–1000 строк, чтобы наблюдатель не угадал префикс по длине ответа. В статье Cloudflare Validating Leaked Passwords with k-Anonymity это называют диапазонным запросом с k-анонимностью: сервер никогда не получает полный хеш пароля, которого ещё нет в корпусе, и поэтому не может потом «снять маску» с этого одного запроса.

Поиск по почте — другой путь. Документация прямо говорит: адрес в пути запроса отдаёт этот адрес HIBP. k-анонимный поиск почты отправляет первые шесть символов SHA-1 от адреса, а не первые пять от хеша пароля. Если в тикете написано «проверил в HIBP», запишите, спрашивали вы префикс хеша пароля или почту. Граница приватности разная, и вывод тоже.

FastPwd не вызывает ни один из этих интерфейсов HIBP. Проверка пароля умеет оценить энтропию на устройстве и сверить этот публичный список высокой частоты. Если нужен корпус на миллиард хешей, откройте официальную страницу HIBP или свою офлайн-копию и сами посмотрите в Network, что в строке запроса только пять шестнадцатеричных символов. Не считайте само собой разумеющимся, что «любой безопасный инструмент сам спросит HIBP».

Сверьте в Network, что проверяемый пароль не ушёл

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

1. Откройте DevTools → Network и включите Preserve log. Фильтр сначала оставьте пустым, чтобы не спрятать отчёты аналитики.
2. На странице проверки пароля введите канарейку вроде CanaryPwd-20260902-xK9 и дождитесь локального расчёта — около 280 миллисекунд после последнего нажатия.
3. Поищите канарейку в списке запросов. Её не должно быть в строке запроса, в query, в теле и в поле формы.
4. Должен быть GET с того же источника: data/leaked-top10k.txt. Откройте ответ: по одному публичному паролю на строку, и вашей канарейки среди них быть не должно.
5. Если сайт заявляет, что ходит в HIBP, ищите api.pwnedpasswords.com/range/: в пути должны быть пять шестнадцатеричных символов, а не открытый текст.

Аналитика посещений при этом может существовать. События проверки FastPwd отправляют только имена — например «начали проверку», «результат слабый» или «попадание в список утечек» — и не кладут содержимое поля ввода в параметр. Откройте отчёт на /tj/matomo.php и поищите канарейку; совпадения быть не должно. Закрытие вкладки не оставляет этот ввод на сервере FastPwd — если он никогда не приходил как прикладные данные. Эту фразу должен держать только что выполненный поиск, а не мысль «я закрыл страницу».

Если канарейка всплыла в любом запросе, вывод переворачивается. Что бы ни было написано на кнопке — «локально», «приватно», «в браузере» — эта проверка уже вынесла пароль из вкладки. Смените инструмент или перейдите на офлайн-список и повторите те же шаги.

Что можно утверждать при попадании и чего нельзя при промахе

При попадании в тикет годится такая фраза: «Строка совпала с публичным списком высокой частоты, скачанным вместе со страницей (точно / по регистру / по хвостовым цифрам / по leet). На этом устройстве она считается крайне частым слабым паролем. Смените его и не используйте на других сайтах.» Не годится фраза: «Сервер другой стороны подтвердил, что это открытый текст утечки X года Y.» У локального списка нет имени инцидента и нет счётчика появлений — только подсказка места.

При промахе защищаемая фраза короче: «Нет совпадения с текущим публичным списком высокой частоты и его четырьмя ступенями деформации.» Нельзя писать «никогда не утекал», «можно оставить» или «чище, чем HIBP». Список из чуть больше восьмисот частых слов не проектировали как доказательство безопасности. Словари распыления, исторические пароли компании и длинная фраза из одного закрытого дампа на этой странице не появятся.

Энтропия — третий, параллельный сигнал. Страница оценивает биты по длине и классам символов: ≥ 80 — «Очень сильный», ≥ 60 — «Сильный», ≥ 40 — «Средний», остальное — «Слабый». Офлайн-перебор показывают из расчёта около 10 миллиардов попыток в секунду; онлайн с ограничением частоты — около 1000 в секунду. Эти числа сравнивают относительную стоимость. Это не обратный отсчёт. Короче 8 символов или попадание во встроенный набор частых слабых паролей принудительно ставит «Слабый». Попадание в публичный список переписывает оценку на «Слабый» даже при высокой энтропии — потому что словарная атака не идёт по пути «среднего полного перебора».

Частые вопросы

Если пароль не попал в локальный список слабых паролей, значит он никогда не утекал?

Нет. Промах значит только то, что в публичном списке высокой частоты этой вкладки не сошлись точное совпадение, свёртка регистра, срез хвоста 0–999 и обычный leet. Это не доказывает, что строка не встречалась ни в одном дампе, не попадала в Have I Been Pwned и что её можно продолжать использовать.

Отправляет ли проверка пароля в Have I Been Pwned открытый текст?

Если клиент следует официальному API — нет. Диапазонный запрос Pwned Passwords принимает только первые пять символов хеша SHA-1 или NTLM и возвращает около 800 суффиксов; полное сравнение остаётся на клиенте. Открытого текста и полного хеша в запросе быть не должно. Проверка почты — другой интерфейс: адрес в пути отдаёт этот адрес сервису. Верьте строке запроса, которую открыли в Network, а не подписи на кнопке.

Обращается ли проверка пароля FastPwd к Have I Been Pwned?

Нет. Она сверяет публичный список высокой частоты, скачанный вместе со страницей. Проверяемый пароль не уходит как прикладные HTTP-данные и не пишется в аналитику. Аналитика посещений записывает только имена событий вроде «начали проверку» или «результат слабый / средний / сильный». Открыли — и можно пользоваться, аккаунт не нужен, и на сайте нет хранилища паролей, куда можно было бы сложить запись проверки.

Если энтропия высокая, но список сработал, пароль всё ещё сильный?

На этом устройстве попадание в публичный список слабых паролей принудительно ставит оценку «Слабый». Энтропия оценивает стоимость полного перебора по пространству символов. Список отвечает, сидит ли эта строка уже в словаре атакующего. Два вопроса друг друга не отменяют. NIST SP 800-63B-4 требует сверять кандидата целиком со списком распространённых или скомпрометированных паролей, а не опираться только на правила состава или календарь обязательной смены.

Пройдите шаги на фальшивом пароле

Если нужна страница, на которой граница вычислений записана явно, откройте проверку пароля FastPwd. Открыли — и можно пользоваться, регистрация не нужна. Сначала введите password или qwerty123: должно быть попадание в публичный список и принудительная оценка «Слабый». Затем введите канарейку выше: в список она попасть не должна, а поиск в Network не должен её найти. GET файла списка можно открыть и посчитать строки; они должны сойтись с «чуть больше восьмисот частых слов» в этой заметке.

После оценки «Слабый» откройте генератор паролей и наберите новую строку на этом устройстве: в случайном режиме длина 6–128 символов, по умолчанию 16; короче 8 помечается как более слабая защита. Если новый пароль нужно отдать коллеге, перейдите на Burn-Link: устройство шифрует алгоритмом AES-256-GCM, сервер хранит только шифротекст, ключ стоит в ссылке после решётки. Полную ссылку Burn-Link обратно в любое поле «онлайн-проверки» не вставляйте.

Смысл упражнения не в том, чтобы доказать, что какой-то один сайт «абсолютно безопасен». Смысл — дать сверку, которую можно показать коллеге до нажатия «Проверить»: этот запуск отдал открытый текст, отправил префикс хеша или использовал короткий локальный список; при попадании смените пароль; при промахе не пишите «никогда не утекал». Те же шаги работают на любом расширении «оценка безопасности» или «поиск утечек».

В следующий раз, когда кто-то вставит пароль в поле проверки, задайте три вопроса. Первый: унёс ли запрос открытый текст или полный хеш? Второй: сверяли около восьмисот частых слов или запускали диапазонный запрос в духе HIBP? Третий: какую фразу поставят в тикет, если совпадения нет? В собственный стандарт паролей стоит класть только ту сверку, которую можно повторить.

Что ещё почитать

Чтобы убедиться, что сама страница проверки не унесла исходную строку, пройдите более полный разбор Network с той же канарейкой: Как проверить, что локальное шифрование в браузере не отправило открытый текст. Когда полный секрет нужно отдать человеку, а не полю проверки, смотрите, почему ключ можно класть после решётки и когда этот слой ломается: Почему после решётки в URL можно класть ключ и когда эта защита ломается. Перед тем как тикеты и логи уйдут в окно ИИ, сверьте поля у источника: Перед тем как вставить тикеты и логи в ИИ, сверьте, какие поля покинут это устройство.