Почему генератор паролей PassMakers безопасен

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

Архитектура: нет сервера — нет утечек

PassMakers — это полностью статический сайт. У проекта нет бэкенда, нет базы данных, нет логов запросов с пользовательскими параметрами. HTML, CSS и JavaScript загружаются с CDN, дальше всё исполняется на вашем устройстве. Сервер не знает, какие настройки вы выбрали, какой пароль сгенерировался и был ли он вообще сгенерирован.

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

CSPRNG: Web Crypto API

Все случайные значения — пароли, парольные фразы, пин-коды, токены — берутся из браузерного crypto.getRandomValues(). Это криптографически стойкий генератор, реализованный самим браузером поверх системного источника энтропии операционной системы (/dev/urandom в Unix, BCryptGenRandom в Windows).

Мы не используем Math.random() — он не предназначен для криптографии и его выход предсказуем при знании внутреннего состояния. Каждый символ пароля выбирается независимо через выборку с отбрасыванием (rejection sampling), чтобы исключить смещение распределения при размере алфавита, не кратном степени двойки.

Проверка на утечку: модель k-anonymity

Инструмент «Проверить пароль на утечку» использует Pwned Passwords API v3 сервиса Have I Been Pwned с моделью k-anonymity. Алгоритм:

  1. Пароль хешируется локально в браузере по SHA-1
  2. На сервер HIBP отправляются только первые 5 символов хеша (префикс)
  3. HIBP возвращает список всех хешей с этим префиксом (обычно 300–800 штук)
  4. Браузер сам ищет в списке полный хеш и определяет, был ли пароль скомпрометирован

Сам пароль — и даже его полный хеш — никогда не покидает ваше устройство. Сервер HIBP физически не может узнать, какой именно пароль вы проверяли: префиксу 5BAA6 соответствуют миллионы возможных паролей.

Что мы не делаем

История генераций хранится исключительно в LocalStorage вашего браузера и доступна только вам на этом устройстве. Очистка кэша браузера или нажатие кнопки «Очистить» удаляет её безвозвратно.

Strict Content Security Policy

В HTTP-заголовках сайт отдаёт жёсткую политику безопасности контента (CSP), которая запрещает загрузку любых внешних скриптов, кроме явно разрешённых:

default-src 'self';
script-src 'self' 'sha256-<inline-hash>';
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
connect-src 'self' https://api.pwnedpasswords.com;
frame-ancestors 'none';

Это означает: даже если злоумышленник найдёт XSS-уязвимость в HTML, браузер не выполнит произвольный JavaScript — он отклонит любой скрипт, который не подписан правильным SHA-256 хешем или не загружается с нашего домена. frame-ancestors 'none' блокирует встраивание сайта в iframe чужих страниц (защита от clickjacking).

Открытые стандарты

PassMakers не изобретает собственную «секретную криптографию». Используются проверенные временем открытые решения:

Все эти инструменты публичны, их код доступен для аудита независимыми исследователями.

Сетевой трафик

При обычной работе сайт делает только следующие сетевые запросы:

  1. Загрузка HTML, CSS, JavaScript при первом заходе (кэшируется на год)
  2. Загрузка шрифтов Inter и JetBrains Mono с Google Fonts (fonts.googleapis.com)
  3. Только при проверке пароля на утечку — один запрос к api.pwnedpasswords.com с префиксом хеша

Никаких фоновых пингов, никаких событий аналитики, никакой отправки данных при генерации паролей.

Что зависит от вас

Архитектура сайта защищает от утечки на нашей стороне, но не от угроз на вашем устройстве:

Любой генератор паролей даёт инструмент, но не гарантирует общую гигиену. Проверяйте, на каком устройстве работаете, и используйте двухфакторную аутентификацию там, где это возможно.

Проверьте сами

  1. Откройте DevTools браузера → вкладка Network → создайте пароль. Вы не увидите ни одного запроса с пользовательскими данными.
  2. Проверьте заголовок Content-Security-Policy в Response Headers — он соответствует описанному выше.
  3. Посмотрите исходный код страницы — весь JavaScript минифицирован, но читаем; никаких обфусцированных загрузчиков или скрытых SDK.

Если у вас есть вопросы по архитектуре или вы нашли уязвимость — напишите через страницу обратной связи.