12 октября 2026

Пароль — не про сложность, а про случайность

Утром попалось на глаза, как статья про пароли объясняет, почему «P@ssw0rd!2026» — это не защита, а приглашение. И понял: всё, что кажется безопасным, может быть ловушкой. Особенно если это на вашем сайте.

Читал статью про то, как пароли вроде «корова-лампа-поезд-ромашка» устойчивы, а P@ssw0rd!2026 — нет. И понял: дело не в том, насколько он выглядит «сложным», а в том, как он был создан. Если человек придумал его, он уже предсказуем. А если случайно — то даже если выглядит просто, он надёжный.

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

Как это устроено — и почему система может быть сломана

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

Я проверяю это у клиентов: смотрю, какой алгоритм хеширования используется. Если это что-то старое — типа MD5 или SHA-1 — уже не годится. А если нет — значит, система может быть взломана, даже если пароль кажется надёжным. И это не про «кто-то взломал», а про то, что утечка данных — вопрос времени.

Как понять, что это касается вашего сайта

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

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

Что с этим делать — и как я это проверяю

Сначала — не ломать, а смотреть. Проверяю, какой алгоритм хеширования используется. Если старый — предлагаю заменить. Если нет — включаю проверку на устаревшие настройки. Потому что даже если пароль кажется надёжным, система может быть слабой.

Дальше — не только настройки. Я смотрю, как пользователи придумывают пароли. Если видно, что все используют «имя+123» или «@» вместо «а» — это сигнал. И тогда я включаю проверку на уязвимые шаблоны. Не по поводу взлома, а чтобы не дать повода.

Что здесь даёт поддержка

На постоянной поддержке я закрываю эту задачу не разово, а системно. Проверяю, как хранятся данные, как настроена регистрация, как обрабатываются пароли. И если что-то устарело — меняю, не дожидаясь утечки.

Работаем с 2002 года, более 100 клиентов по всему миру. И да — мы не просто «включаем» защиту. Мы смотрим, как она устроена. И если что-то может быть сломано — мы его меняем. До того, как это станет проблемой. Это не про «мы починим», а про то, чтобы не думать об этом вообще.