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

В этой статье я разберу аутентификацию с самого начала: почему пароли до сих пор актуальны, как оценить их реальную стойкость (с честными расчётами), что происходит с паролем на сервере и какие ошибки допускают разработчики. В конце — чек-лист для обеих аудиторий.

Нейрослоп, но получилось атмосферно
Нейрослоп, но получилось атмосферно

Изобретение велосипеда

Зачем вообще сегодня нужны пароли? Существует несколько способов ограничить доступ к информационным системам, и у каждого есть свои плюсы, минусы и сценарии использования.

  1. Логины и пароли — исторически первый способ организации защиты, восходящий ещё к произнесению секретных слов при личной встрече. Исключительно прост для понимания пользователями и реализации программистами (хотя тут есть важные оговорки, к которым мы вернёмся).

  2. Бумажные (а в новейшей истории пластиковые) документы — годятся для подтверждения личности при общении с людьми. Для защиты от подделок их снабжают элементами, которые проверяются специальными средствами (ультрафиолет, увеличительные стёкла). Могут содержать в себе аппаратные ключи.

  3. Аппаратные ключи — таблетки, RFID-метки, смарт-карты, USB-токены. Их невозможно забыть, относительно сложно подделать, но можно потерять. Они подтверждают, что владелец физически обладает ключом, но часто требуют дополнительного оборудования и ПО.

  4. Программные ключи — фрагменты данных, которые используются для криптографических операций: подпись запросов (HMAC, JWT), асимметричное шифрование (SSH-ключи, PGP), хранение сертификатов в защищённых контейнерах. Позволяют подтверждать идентичность, целостность данных и подлинность сообщений без передачи самого секрета.

  5. Одноразовые пароли (OTP) — обычно служат для подтверждения намерений и в качестве дополнительного фактора к обычному паролю. Такая связка называется двухфакторной аутентификацией (2FA). Именно так одноразовые пароли применяются чаще всего: первый фактор (знание пароля) дополняется вторым (владение устройством, генерирующим OTP, или доступом к SMS/почте). Генерация может быть аппаратной или программной.

  6. Биометрия — комплекс измерений, позволяющий с достаточной степенью достоверности утверждать, что измеряется конкретный организм — носитель личности. Биометрия удобна, но у неё есть принципиальная слабость: отпечатки пальцев или лицо нельзя сменить, как пароль. Поэтому в современных системах биометрические данные обычно хранятся локально на устройстве (в защищённом элементе) и не передаются на сервер.

  7. Отдельно стоит упомянуть WebAuthn — стандарт, который позволяет использовать биометрию или внешние ключи (USB-токены) для аутентификации без передачи пароля. Закрытый ключ никогда не покидает устройство, а серверу передаётся только открытый ключ. Это делает биометрию не «секретом», который можно украсть из базы, а средством локальной разблокировки криптографического ключа.

Почему пароли?

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

Логин — это утверждение: «я такой-то». Пароль — доказательство этого утверждения через знание секрета, известного только владельцу учётной записи.

Миф об идеальной защите

Некоторые пользователи уверены: если аккаунт защищён паролем, посторонние не могут получить к нему доступ («взломать»). Это опасное заблуждение. Правильная формулировка звучит иначе:

Правильное проектирование, реализация и использование парольной защиты делает взлом системы экономически невыгодным.

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

Стойкость пароля

Основа безопасности — достаточно сложный для подбора пароль.

Почему плох пароль «12345»? Он состоит только из цифр. Если злоумышленник предполагает, что это так, то для полного перебора всех возможных пятизначных цифровых паролей ему потребуется не более 105 = 100 000 попыток (в реальности меньше, если правильный пароль не окажется последним в переборе). Даже вручную, без автоматизации, четырёхзначный цифровой пароль можно перебрать за час-другой, а пятизначный — уже за несколько дней. Но автоматизация делает перебор пятизначного пароля делом секунд.

Добавим другие символы. 26 латинских букв + 10 цифр — уже алфавит из 36 символов, и для пароля длиной 5 количество комбинаций увеличивается до 365 = 52 521 875. Вручную подобрать уже совершенно невозможно. Но простейший скрипт, делающий 10 запросов в секунду, гарантированно справится за два месяца (в реальности быстрее). Такая атака становится возможной, если сервис не ограничивает частоту и количество попыток.

Вывод 1: троттлинг (ограничение частоты запросов) необходим. Простое ограничение числа запросов с одного адреса заставляет злоумышленника использовать распределённые системы, что значительно сложнее и сопряжено с резким ростом затрат.

Допустим, в атаке задействован ботнет из 10 000 устройств, и сервис успевает обрабатывать все запросы — по 10 в секунду от каждого. Итого проверяется 100 000 вариантов в секунду, и полный перебор пятисимвольных паролей из 36-значного алфавита займёт меньше 9 минут.

Вывод 2: короткий пароль из букв и цифр опасен.

Расширим набор символов: добавим латиницу в другом регистре. Теперь мощность алфавита 10 + 26 + 26 = 62 символа, и 5 знаков дают 625 = 916 132 832 комбинаций. Для наихудшего уже рассмотренного случая (100 000 вариантов в секунду) время полного перебора — не более 2,5 часов. Уже чуть лучше, но всё равно так себе.

Добавим специальные символы: !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ и пробел. Всего 33 штуки. 10 + 26 + 26 + 33 = 95, и для 5 знаков 955 = 7 737 809 375. Перебор с ботнетом займёт уже 21 час. По-прежнему печально.

Мы можем дальше наращивать алфавит? Технических проблем с любым символом, представимым в UTF-8, быть не должно. Добавим кириллицу — 66 новых символов. Но вот тут стоп. Да, мы получим более стойкий пароль, но всего лишь в разы. А представьте, что пользователю понадобится ввести такой пароль на чужом компьютере без кириллической раскладки — приплыли. То же верно для любого национального алфавита. Зато все символы ASCII можно ввести на любом устройстве, хотя для экранных клавиатур иногда требуются дополнительные действия.

Вывод 3: возможности расширения алфавита ограничены, но поощрять использование специальных символов всё же стоит.

Что же делать? Увеличим длину строки! Используем наш последний успешный алфавит из 95 символов и возьмём 8 символов. 958 = 6 634 204 312 890 625 комбинаций. При скорости 100 000 комбинаций в секунду полный перебор займёт более 2000 лет. Даже с уменьшенным алфавитом без спецсимволов (628 = 218 340 105 584 896) получим около 70 лет.

Вывод 4: длина строки важнее размера алфавита. Это очевидно из сравнения степенной и показательной функции, но мы только что подкрепили теорию практическими расчётами.

Но так ли всё хорошо? Что, если я предложу пароли длиной даже 10 символов, которые проходят формальную проверку на сложность, но взлом которых займёт секунды? Не верите? Пожалуйста: Qwertyuio1, Abcdefghi0, 88ElePHANT. И даже P@ssW0rD36 — последний, пожалуй, наименее плох. Но все они плохи, потому что есть в словарях (или являются результатом набора в другой раскладке — например, Ghbdtn на самом деле «Привет»). Перемешанные регистры? Несколько цифр? Замена букв на похожие символы? Это улучшает ситуацию, но не настолько, чтобы считать такие пароли безопасными.

Намного лучше — фразы из нескольких слов. Классический пример: correct horse battery staple(но не используйте его буквально!). Здесь полный перебор невозможен, но пароль составлен из слов. Важно: фразы должны быть случайными, а не цитатами из книг или песен. Достаточно 4–6 случайных слов из словаря (чем больше, тем лучше). Можно добавлять разделители (дефисы, пробелы) и цифры для увеличения алфавита, но основа — длина и случайность.

Если принять, что активный словарь носителя английского языка — около 20 000 слов, то 20 0004 = 1.6 × 1017 вариантов, что даёт десятки тысяч лет перебора. И это только строчные буквы без цифр. Так что это хорошая рекомендация. Если же не хочется использовать фразы, то достаточно длинная строка с большим алфавитом — уже хорошая защита.

Вывод 5: пароль можно считать надёжным, если его подбор требует времени, превышающего актуальность цели атакующего, и затрат, заметно превышающих потенциальную выгоду.

Вывод 6: отдельное словарное слово или распространённый паттерн (даже с заменой букв символами) — ненадёжны. Фраза из нескольких случайных слов (passphrase) — надёжна, если слова выбраны случайно и их достаточно (4–6).

А как же PIN-коды? 4 цифры — это всего 10 000 комбинаций, но они остаются стандартом для банковских карт и SIM. Секрет в контексте: PIN защищён не криптографической стойкостью, а физическим ограничением попыток (обычно 3–10 неверных вводов, после чего устройство или карта блокируется). Если злоумышленник получает хеш пина, задача становится тривиальной. Поэтому используются специальные, обычно аппаратные, методы защиты, не позволяющие получить хеш. Это хороший пример того, как требования к паролю кардинально меняются в зависимости от условий использования.

Надеюсь, теперь понятно, зачем нужны сложные пароли и как объяснить их необходимость пользователям.

Возражения пользователей

«Да кому я нужен? Зачем меня ломать?»

Современные хакеры редко занимаются целенаправленными атаками на конкретного человека. Гораздо чаще это массовые «ощупывания» интернета роботами и ботнетами, и слабые пароли утекают первыми. А дальше — полный набор сценариев: от угона аккаунта в соцсети до потери всех денег на банковских счетах. Любое из этих последствий достаточно серьёзно, чтобы прямо сейчас поменять пароли на всех сервисах и больше не грешить.

И ещё: на каждом сервисе должен быть уникальный пароль. Если пароли одинаковы, а один из сайтов взломают (или просто сольют базу), остальные аккаунты автоматически попадают в группу высокого риска. Это называется credential stuffing — злоумышленники просто перебирают связки логин-пароль по разным популярным сервисам. Причём утечь может даже хороший пароль, как мы увидим дальше.

«Но я не смогу запомнить разные сложные пароли от десятков сервисов!»

Идеальный пароль — случайная мешанина из букв, цифр и спецсимволов достаточной длины. Но даже строку из 8 символов запомнить непросто, а уж несколько, да ещё не перепутать — практически нереально.

Выход — менеджеры паролей. Они бывают двух типов:

  • Локальные (KeePass, KeePassXC) — все данные хранятся в зашифрованном файле на вашем устройстве.
    Плюсы: полный контроль, открытый исходный код, не зависит от сторонних облаков.
    Минусы: нужно самостоятельно синхронизировать базу между устройствами (например, через своё облако или вручную). Если потерять базу или забыть мастер-пароль — доступ потерян навсегда.

  • Облачные (Bitwarden, 1Password, встроенные в браузеры и iCloud Keychain) — хранилище синхронизируется через сервер провайдера.
    Плюсы: удобство, автозаполнение, встроенные генераторы, синхронизация «из коробки».
    Минусы: данные хранятся у третьей стороны, нужно доверять провайдеру. Однако при сильном шифровании на клиентской стороне и хорошем мастер-пароле риски приемлемы.

Главное правило для любого менеджера: мастер-пароль должен быть очень стойким (фраза из 4–5 случайных слов или длинная случайная строка). Также стоит включить двухфакторную аутентификацию для доступа к самому менеджеру.

Важно: если менеджер паролей позволяет разблокироваться только по биометрии (отпечаток, Face ID) без ввода мастер-пароля, это удобно, но снижает безопасность. Биометрию проще подделать (муляж, качественное фото) или принудительно использовать (приложить палец спящего, поднести телефон к лицу), чем получить мастер-пароль из головы. Кроме того, биометрические данные могут быть скомпрометированы при утечке с устройства. Поэтому настоятельно рекомендуется требовать ввод мастер-пароля хотя бы время от времени (например, при каждой перезагрузке или через определённый интервал), а биометрию использовать как дополнительный, а не единственный фактор. Эта практика уже реализована во многих платформах: Apple (iOS, macOS) требует пароль после перезагрузки или длительного отсутствия, аналогично работают Bitwarden, 1Password и KeePass.

Социальная инженерия — человеческий фактор

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

Самые распространённые приёмы:

  • Звонок от «сотрудника службы безопасности» — просят сообщить пароль для проверки или восстановления. Настоящие сотрудники никогда этого не сделают.

  • Фишинговые письма — копия письма от сервиса (банка, соцсети) со ссылкой на поддельную страницу входа. Адрес может отличаться на один символ.

  • Поддельные страницы входа — домены-двойники, точная копия интерфейса. Пользователь вводит логин и пароль, они уходят злоумышленнику.

Как защититься:

  • Никогда и ни при каких обстоятельствах не сообщайте свой пароль. Даже если звонящий представляется сотрудником службы безопасности вашего банка. Даже если это ваш лучший друг или близкий родственник. Пароль — это секрет, который не должен покидать вашего сознания (или защищённого менеджера паролей). Если по какой-то причине вы всё же сообщили пароль (ситуации бывают разные), немедленно смените его при первой же возможности, даже если вы абсолютно доверяете тому, кому сообщили. Устройство собеседника может быть взломано, и пароль утечёт без его злого умысла.

  • Проверяйте адрес сайта перед вводом пароля. Убедитесь, что протокол — https://, а в адресной строке нет лишних символов. В мобильных приложениях, где адрес не виден, не вводите пароль, если вы не уверены в подлинности приложения (скачивайте только из официальных магазинов).

  • Не игнорируйте предупреждения браузера о небезопасном соединении или подозрительном сайте. Если браузер кричит — лучше уйти.

  • Если вам очень нужно зайти на сайт, который браузер считает опасным, подумайте: может, это фишинг? В 99% случаев безопаснее поискать альтернативу или подождать.

  • Включите двухфакторную аутентификацию. При фишинге злоумышленник может украсть пароль, но без второго фактора (особенно аппаратного, как WebAuthn) войти не сможет.

  • Используйте менеджеры паролей — они автоматически не подставляют пароль на поддельном сайте (домен не совпадает), что служит дополнительной защитой.

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

А как хранятся пароли?

Очевидно, что чем сложнее пароль, тем сложнее его запомнить или ввести вручную, но пароли пользователей не только запоминаются (или хранятся в менеджере паролей) — они также передаются на сервер и там должны обрабатываться с особой осторожностью. И вот тут начинается самое интересное для разработчиков.

Пароль есть? А если найду?

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

Что же делать? Возникает соблазн хранить пароли в зашифрованном виде, но это не сильно помогает: если злоумышленник получил базу зашифрованных паролей и знает хотя бы один пароль (например, свой собственный), он может атаковать ключ шифрования, а затем расшифровать всё. Даже если ключ не лежит в конфиге рядом с базой, наличие хотя бы одной пары «открытый текст — шифротекст» делает подбор ключа (или обход шифрования) значительно более реальным. Поэтому обратимые методы хранения паролей не решают проблему.

Хеширование — палка о двух концах

Существует целый класс односторонних криптографических функций — хешей. Такая функция принимает на вход произвольную строку (в нашем случае пароль) и выдаёт набор символов, похожий на случайный. Важные свойства:

  1. Для одинаковых входных строк хеши совпадают.

  2. Для разных входных строк с подавляющей вероятностью хеши различаются (коллизии возможны, но для современных функций крайне маловероятны).

  3. Даже незначительное изменение входной строки (один бит) приводит к масштабному и непредсказуемому изменению хеша.

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

Но современное железо позволяет вычислять миллиарды хешей в секунду. Если мы используем быстрый алгоритм (MD5, SHA-1, SHA-256), то даже хороший пароль становится уязвимым. Вернёмся к нашему «достаточно хорошему» варианту: строка длиной 8 из 95 символов. В офлайн-атаке при скорости 1 млрд хешей/с полный перебор займёт около двух с половиной месяцев. Для банка, где на счетах миллионы, такая атака становится экономически оправданной.

Соль, перец и медленные хеши

Для усложнения ситуации придуманы несколько механизмов:

  • Соль — случайная строка, уникальная для каждого пароля. Она добавляется к паролю перед хешированием и сохраняется вместе с хешем. Это делает бесполезными радужные таблицы (заранее вычисленные наборы хешей) и гарантирует, что даже у двух пользователей с одинаковыми паролями хеши будут разными.

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

  • Медленные хеш-функции (bcrypt, Argon2id) — алгоритмы, специально спроектированные для хранения паролей. Они требуют значительных вычислительных ресурсов (настраиваемый «фактор работы») и дополнительной памяти. При обычной аутентификации это незаметно, но для массового перебора скорость падает с миллиардов до десятков-сотен тысяч попыток в секунду, возвращая нас к безопасным оценкам даже для 8-символьных паролей.

При этом устаревшие функции (MD5, SHA-1) отправлены в отставку из-за обнаруженных коллизий и слишком высокой скорости. Их нельзя использовать не только для хеширования паролей, даже с солью, но и вообще для любой криптографии.

Делегируйте выбор алгоритма встроенным средствам

Современные языки и фреймворки предоставляют готовые, проверенные API для хеширования паролей. Например, в PHP это password_hash($password, PASSWORD_DEFAULT) и password_verify($password, $hash). В Python — werkzeug.security.generate_password_hash, в .NET — PasswordHasher и так далее.

Такие функции сами:

  • выбирают актуальный алгоритм (например, PASSWORD_DEFAULT в PHP сегодня указывает на bcrypt, но в будущем может переключиться на Argon2id без изменения вашего кода);

  • генерируют криптостойкую соль;

  • позволяют задать только «стоимость» (cost factor), не требуя вникать в детали;

  • упаковывают хеш, соль и параметры в единую строку для удобства хранения.

Если же вы начинаете выбирать алгоритм вручную (password_hash($pass, PASSWORD_BCRYPT)) или, хуже того, вызываете hash('sha256', $salt.$pass), вы берёте на себя ответственность за:

  • своевременный переход на более стойкий алгоритм в будущем;

  • правильную генерацию и хранение соли;

  • настройку фактора работы (и его последующее увеличение по мере роста железа);

  • защиту от коллизий и других подводных камней.

В криптографии такой подход — путь к уязвимостям. Делегируйте выбор алгоритма встроенным средствам языка или фреймворка. Не пытайтесь сами решить, какой алгоритм лучше — используйте API, которые делают это за вас.

Забыли пароль?

Даже если вы храните пароли безупречно, система восстановления доступа часто становится самым слабым звеном. Пользователь теряет пароль — и тут открывается множество способов взлома.

Типичные ошибки

  • Отправка текущего пароля по электронной почте — означает, что пароль либо хранится в открытом виде, либо зашифрован обратимо. Это недопустимо.

  • Секретные вопросы («девичья фамилия матери», «кличка собаки») — их ответы часто легко найти в социальных сетях или подобрать перебором. Это театр безопасности, о котором мы ещё поговорим.

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

  • Слабые проверки личности — когда достаточно ввести номер телефона, который легко подменить (SIM-своп), или ответить на секретный вопрос.

Правильное восстановление

  1. Никогда не отправляйте пароль. Только временный одноразовый токен (например, ссылка с UUID).

  2. Токен должен быть криптографически случайным и храниться в базе в хешированном виде.

  3. Короткое время жизни — 15–30 минут, не больше.

  4. После использования токен немедленно инвалидируется. Также нужно инвалидировать все предыдущие токены для этого пользователя при успешном сбросе пароля.

  5. Дополнительная проверка — при возможности используйте двухфакторную аутентификацию для подтверждения операции сброса (например, отправка кода в SMS или в приложение аутентификатора).

  6. Не полагайтесь на секретные вопросы. Вместо них — отправка подтверждения на заранее верифицированные каналы (почта, телефон).

И да, даже при сбросе пароля новый пароль должен проходить те же проверки на сложность и словарные атаки, что и обычный. Не позволяйте пользователю установить newpassword123.

Что делать, если потерян второй фактор?

Если пользователь потерял доступ к устройству с TOTP-генератором или к телефону для SMS, стандартный механизм восстановления (через почту) может оказаться недостаточным. Безопасные практики:

  • Резервные коды — при включении 2FA сервис выдаёт долговременные (постоянные) одноразовые коды, которые нужно сохранить в надёжном месте.

  • Запасные методы — разрешить использовать другой подтверждённый канал (например, второй телефон или почту).

  • Административное восстановление — только при личной идентификации сотрудником службы поддержки, с обязательным сбросом всех активных сессий и последующей принудительной сменой пароля и повторной настройкой 2FA.

Никогда не восстанавливайте доступ по звонку «я это я» без доказательств.

Возражения программистов

«Но я не банк! Кому нужно меня ломать?»

Та же ловушка, что и с пользователями. Если вы не банк, вас будут ломать тупые боты и ботнеты, постоянно ищущие, чем поживиться. Базу может слить недобросовестный админ дешёвого хостинга. Если база будет слита, найдутся желающие в ней поковыряться и использовать все находки. И в один прекрасный момент вы получите массовый угон учёток своих пользователей, многие из которых после такого инцидента к вам больше не вернутся.

Поэтому защищать пароли (и другие чувствительные данные) нужно всегда по высшему разряду. В современных условиях это не так уж сложно — если не изобретать велосипед и следовать рекомендациям, которые приведены выше.

Театр безопасности

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

Периодическая смена пароля

Помните требование «меняйте пароль каждые 30/60/90 дней»? Оно пришло из 90-х, когда считалось, что это ограничит время жизни скомпрометированного пароля. Сегодня NIST (Национальный институт стандартов и технологий США) в своей рекомендации SP 800-63B прямо говорит: не требуйте периодической смены паролей без признаков компрометации. Почему?

  • Пользователи, вынужденные часто менять пароли, выбирают предсказуемые паттерны: пароль1 → пароль2 → пароль3, добавляют сезонные суффиксы (весна2026) или просто увеличивают цифру в конце. Реальная стойкость падает.

  • Растёт нагрузка на службу поддержки — забытые пароли становятся эпидемией.

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

Когда менять нужно — только при подозрении на компрометацию (утечка базы, фишинг, подозрительная активность), при увольнении сотрудника или смене уровня привилегий. В остальных случаях — не трогайте. Вместо этого внедрите двухфакторную аутентификацию и мониторинг утечек.

Сложность по инструкции

«Пароль должен содержать заглавные, строчные, цифры и спецсимволы». Знакомая формулировка? Она порождает шедевры вроде P@ssw0rd123 — формально все требования соблюдены, но такой пароль есть в любом словаре для брутфорса. Это классический театр: вместо реальной защиты мы получаем утомлённого пользователя и ложное чувство безопасности.

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

Клиентское хеширование — абсолютно бесполезная затея

Иногда разработчики думают: «А давайте хешировать пароль на клиенте, чтобы на сервер не передавать пароль в открытом виде». Это бессмысленно и опасно. Почему?

  • Если злоумышленник перехватывает хеш (например, при отсутствии HTTPS), он может использовать его для аутентификации — хеш становится эквивалентом пароля.

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

  • Клиентское хеширование не заменяет TLS. Если у вас нет HTTPS, проблема не в передаче пароля, а во всей коммуникации.

Правило: не изобретайте велосипед. Передавайте пароль по HTTPS, а на сервере используйте медленные хеши с солью. Клиентское хеширование — это театр, который не решает реальных проблем.

Секретные вопросы — могила безопасности

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

  • находятся в социальных сетях;

  • подбираются перебором (словари имён, названий, фамилий);

  • узнаются через социальную инженерию.

Секретные вопросы нельзя использовать для восстановления доступа. Если вы всё ещё их применяете — немедленно прекратите. Вместо них — отправка временного токена на подтверждённые каналы (почта, телефон) и двухфакторная аутентификация.

Если вы, как пользователь, столкнулись с сервисом, который требует ответ на секретный вопрос и не даёт от него отказаться, установите в качестве ответа длинную случайную строку (сгенерируйте её в менеджере паролей). Не сохраняйте эту строку как «ответ на вопрос», просто сделайте её нечитаемой и не связанной с реальными фактами (или сохраните как суррогат долговременного токена сброса, но вы должны понимать, что делаете). Так вы фактически отключите этот опасный канал восстановления.

Запрет на сохранение паролей в браузере

«Мы запрещаем браузеру запоминать пароли — так безопаснее». Результат: пользователь записывает пароль в текстовый файл на рабочем столе или на стикер, приклеенный к монитору. Это повышает безопасность? Очевидно, нет. Гораздо разумнее — разрешить использовать встроенный менеджер паролей (или установить отдельный), но позаботиться о том, чтобы мастер-пароль был действительно сильным.

Хеширование для галочки

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

Как отличить реальную безопасность от театра?

Задайте себе вопрос: защищает ли эта мера от реальной угрозы, с учётом поведения реальных людей? Если мера работает только при условии, что пользователь ведёт себя идеально (не придумывает простые пароли, не записывает их, не использует паттерны), а на практике люди так не делают — это театр. Если мера опирается на современные стандарты и учитывает человеческий фактор — это реальная безопасность.

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

Чек-лист для читателей

Для пользователей

  • Используйте менеджер паролей (локальный или облачный) с очень сильным мастер-паролем.

  • Для каждого сервиса генерируйте длинный (не менее 12–16 символов) случайный пароль.

  • Включите двухфакторную аутентификацию везде, где это возможно.

  • Если менеджер недоступен, создавайте пароли-фразы из 4–5 случайных слов (или длинную строку с разными символами).

  • Никогда не повторяйте пароли на разных сайтах.

  • Не сообщайте пароль никому, даже если звонят из «техподдержки». Проверяйте адрес сайта перед вводом, обращайте внимание на https://.

  • Никогда не вводите свой пароль на сторонних сайтах, даже если они обещают проверить его безопасность. Используйте только официальные инструменты, которые работают без передачи полного пароля (например, Have I Been Pwned позволяет проверить по части хеша), но помните: даже такие сервисы не дают 100% гарантии. Безопаснее полагаться на собственный менеджер паролей и уведомления от сервисов, которые вы используете.

Для разработчиков

  • Храните только хеши паролей, никогда — открытые или зашифрованные (обратимые) пароли.

  • Используйте медленные хеш-функции с солью: bcrypt, Argon2id.

  • Делегируйте выбор алгоритма встроенным функциям языка/фреймворка (password_hash в PHP, аналоги в других средах).

  • Никогда не пишите свою криптографию и не используйте MD5, SHA-1 или просто SHA-256 для паролей.

  • Реализуйте троттлинг (ограничение частоты попыток входа) для защиты от онлайн-атак.

  • Внедрите двухфакторную аутентификацию и позволяйте пользователям её использовать.

  • Не требуйте периодической смены паролей без признаков компрометации.

  • Не используйте секретные вопросы для восстановления доступа.

  • Не пытайтесь хешировать пароли на клиенте — это не повышает безопасность.

  • Организуйте безопасное восстановление пароля: одноразовые токены с коротким сроком жизни.

  • Помните о юридической ответственности: в России хранение паролей в открытом виде может быть признано нарушением 152-ФЗ «О персональных данных» (необеспечение безопасности). В Европе — это прямое нарушение GDPR, влекущее крупные штрафы. Даже если ваше приложение «не банк», защищайте пароли как если бы вы хранили деньги.

Заключение

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

Надеюсь, эта статья поможет и тем, и другим сделать интернет хоть немного безопаснее.