Парольная безопасность

Вступление

Большинство людей уверены, что знают, как создать надёжный пароль. Добавляют цифру, заменяют «а» на «@», ставят восклицательный знак в конце и считают задачу решённой.

Но именно эти действия делают пароль предсказуемым: паттерны замены символов давно включены в словари для брутфорса, и «сложный» P@rr01! взламывается за секунды.

Слабые пароли — не единственная уязвимость. По данным DSEC (ГК «Солар»), в 73% российских компаний сотрудники использовали пароли по умолчанию или один и тот же пароль для разных учётных записей. Такой вывод содержится в отчёте «Ключевые уязвимости информационных систем российских компаний в 2025 году». Злоумышленники берут старые базы утечек и автоматически проверяют их по новым целям — одна скомпрометированная учётная запись превращается в цепочку взломов.

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

Рекомендации в этом материале построены на актуальных международных стандартах NIST и OWASP — для тех, кто хочет защитить аккаунты, а не просто выполнить формальные требования политики безопасности.

Главное

• Пароли взламывают не перебором — их берут из утечек. Злоумышленники проверяют старые базы по новым целям автоматически: одна скомпрометированная учётная запись открывает доступ ко всем сервисам, где используется тот же пароль.
• Длина важнее сложности. Случайная фраза из четырёх слов обладает большей энтропией, чем короткий пароль со спецсимволами.
• Повторное использование паролей — главная уязвимость корпоративных систем. По данным DSEC (ГК «Солар»), в 73% российских компаний сотрудники используют пароли по умолчанию или один пароль для разных учётных записей.
• Менять пароль по расписанию бессмысленно. NIST SP 800-63B прямо запрещает принудительную ротацию: она приводит к предсказуемым вариантам вида Parol2024 → Parol2025. Смена оправдана только при подтверждённой компрометации.
• Второй фактор закрывает риски, которые пароль не закрывает. МФА защищает от фишинга и утечек баз данных даже если пароль уже известен атакующему.

Почему старые правила создания паролей больше не работают

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

Миф 1: пароль нужно менять каждые 90 дней

Принудительная ротация паролей каждые 30, 60 или 90 дней — одна из самых живучих корпоративных политик. И одна из самых вредных.

Когда пользователя заставляют регулярно менять пароль, он предсказуемо адаптируется: Parol2024 → Parol2025. Исследования показывают, что принудительная смена паролей приводит к выбору более слабых вариантов, которые легче запомнить при следующей ротации.

Позиция Национального института стандартов и технологий США (NIST): верификаторы не должны требовать периодической смены паролей без конкретного основания. Смена оправдана только при подтверждённой компрометации, но не ранее.

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

Миф 2: сложный пароль лучше длинного

Пароль P@$$w0rd! выглядит сложным: заглавные буквы, цифры, спецсимволы. На практике он взламывается за секунды, потому что подстановка символов (a → @, o → 0) давно включена в словари для брутфорса, метода взлома систем путём автоматизированного перебора всех возможных комбинаций символов. Атакующие знают эти паттерны лучше, чем сами пользователи.

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

Миф 3: браузер надёжно хранит пароли

Встроенные менеджеры паролей в браузерах удобны, но уязвимы. Инфостилеры — вредоносные программы, специально разработанные для кражи сохранённых учётных данных, целенаправленно атакуют хранилища Chrome, Firefox и Edge. Инфостилеры остаются одним из главных каналов первичной компрометации паролей. Браузерное хранилище не шифруется мастер-паролем по умолчанию и доступно любому процессу, запущенному под вашей учётной записью.

Актуальные стандарты безопасности

Актуальные стандарты безопасности — NIST (Национальный институт стандартов и технологий США) и OWASP (Open Web Application Security Project). Это два главных ориентира в области парольной безопасности. Их рекомендации лежат в основе корпоративных политик и требований регуляторов по всему миру.

Требования NIST

В августе 2025 года NIST опубликовал четвёртую редакцию стандарта SP 800-63B. Это наиболее значительное обновление за последние годы — стандарт полностью переосмыслил подход к парольным политикам. Ключевые нормативные требования:

Длина:

• Минимум 15 символов для однофакторной аутентификации
• Минимум 8 символов при включённой многофакторной аутентификации (MFA)

Состав и ограничения:

• Разрешены все символы Unicode (универсальный стандарт кодирования символов), включая пробелы
• Запрещено устанавливать правила состава (обязательные цифры, спецсимволы, заглавные буквы), они снижают реальную энтропию
• Система не должна незаметно обрезать пароль, если он слишком длинный

Смена паролей:

• Периодическая принудительная смена запрещена
• Смена обязательна только при подтверждённой компрометации

Рекомендации OWASP

OWASP синхронизирован с NIST и дополняет его практическими требованиями для разработчиков и администраторов:

• Индикатор надёжности пароля при регистрации
• Защита от брутфорса: ограничение числа попыток, CAPTCHA, временные блокировки
• MFA — рекомендована как один из лучших элементов защиты для чувствительных операций

Старые vs. новые требования к паролям:

5 главных правил создания надёжного пароля

Надёжный пароль — длинный, случайный и уникальный для каждого сервиса. Его сложно подобрать автоматически и незачем запоминать: для этого существует менеджер паролей. Ниже практический минимум по стандартам NIST и OWASP, адаптированный для реальной работы с паролями.

1. Используйте парольные фразы

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

Принцип: четыре случайных слова дают пространство перебора, сопоставимое с миллиардами лет работы современного оборудования для взлома.

Хорошие примеры парольных фраз:

• stol-nebo-reka-kirpich-2025
• gora-oblako-veter-more
• Krasny-Fonar-Ulitsa-Drozd

Предсказуемые фразы:

• iloveyou2025 — словарная фраза
• privet-mir — слишком короткая и простая
• password-qwerty — очевидная комбинация

2. Длина важнее сложности

Минимум по NIST — 15 символов для однофакторной аутентификации. Это нижняя граница, а не цель. Парольная фраза из 25–30 символов обеспечивает большую защиту, чем 10-символьный «сложный» пароль.

Время перебора паролей по Hive Systems:

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

3. Уникальный пароль для каждого сервиса

Повторное использование паролей — главная причина масштабных взломов. Механизм атаки прост: злоумышленник получает базу логинов и паролей с одного взломанного сайта и автоматически проверяет их на десятках других сервисов.

По данным компании «Вебмониторэкс», в первом полугодии 2025 года около половины всех веб-атак на российские госорганизации составляли именно попытки подбора учётных данных. Госсектор оказался единственной отраслью, где этот тип атак стабильно занимает первое место среди всех веб-угроз.

Правило: один сервис — один уникальный пароль. Без исключений.

4. Никакой личной информации

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

Что нельзя использовать в пароле:

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

5. Двухфакторная аутентификация

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

Приоритет методов двухфакторной аутентификации:

1. Аппаратный ключ (FIDO2/WebAuthn). Максимальная защита, устойчив к фишингу.
2. TOTP-приложение (Google Authenticator, Яндекс.Ключ, Пассворк 2ФА и аналоги). Надёжно, не зависит от сети.
3. Пуш-уведомление в приложении. Удобно, но более уязвимо.
4. SMS-код. Наименее надёжный вариант, уязвим для SIM-свопинга, но лучше, чем ничего.

NIST относит SMS к ограниченно допустимым методам аутентификации и рекомендует переход на TOTP или FIDO2 для систем, обрабатывающих чувствительные данные.

Примеры надёжных и слабых паролей

Здесь конкретные сравнения, которые показывают разницу между паролем, который взломают за секунды, и паролем, который выдержит атаку.

Почему генератор паролей надёжнее человека?

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

Каждый символ выбирается независимо из заданного набора — без какой-либо логики, которую можно предугадать или воспроизвести. Результат: пароль вида xK9#mQ2@vL5$nR8!pT3 обладает максимальной энтропией для своей длины и не встречается ни в одном словаре для брутфорса. Запоминать его не нужно — менеджер паролей подставит его автоматически.

Менеджер паролей

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

Главное возражение против надёжных паролей: «я не смогу это запомнить». Это справедливо, если пытаться держать в голове xK9#mQ2@vL5$nR8!pT3. Менеджер паролей снимает эту проблему: вы запоминаете один мастер-пароль — надёжный, длинный, уникальный. Остальное он берёт на себя.

Что даёт корпоративный менеджер паролей:

• Генерация криптографически случайных паролей нужной длины и состава
• Хранение неограниченного числа уникальных паролей
• Автозаполнение на сайтах и в приложениях
• Предупреждение об использовании одного пароля на нескольких сервисах

Для корпоративного использования критически важны дополнительные возможности: управление доступом по ролям, журнал аудита действий, интеграция с Active Directory и возможность развернуть решение внутри собственной инфраструктуры. Это особенно актуально для организаций, работающих с персональными данными и обязанных соблюдать требования 152-ФЗ.

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

Ключевые возможности:

• Локальное развёртывание — все данные хранятся на серверах компании, без передачи третьим сторонам
• Ролевое управление доступом — гибкое разграничение прав: кто видит, кто редактирует, кто передаёт пароли
• Полный журнал аудита — каждое действие с паролем фиксируется: кто открыл, скопировал, изменил и когда
• Интеграция с Active Directory и LDAP — централизованное управление пользователями без дублирования учётных записей
• Шифрование AES-256 — данные зашифрованы на уровне хранилища, расшифровка происходит только на стороне клиента

Пассворк подходит для организаций, обязанных соблюдать требования 152-ФЗ: данные не покидают инфраструктуру, а журнал аудита обеспечивает доказательную базу при проверках.

Проверьте свой пароль на надёжность

Проверка пароля — это регулярная практика, которая состоит из оценки надёжности и проверки по базам утечек.

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

Тест: как вы на самом деле создаёте пароли?

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

Заключение

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

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

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

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

Следовать правильным принципам несложно, если есть подходящий инструмент.

Часто задаваемые вопросы

Какой пароль считается надёжным?

Надёжный пароль — длинный, случайный и уникальный для каждого сервиса. Минимальная длина — 15 символов при однофакторной аутентификации, 8 символов при включённом МФА. Случайная парольная фраза из четырёх слов надёжнее короткого пароля со спецсимволами: длина важнее состава.

Нужно ли регулярно менять пароли?

Плановая ротация каждые 90 дней снижает безопасность, а не повышает её. Когда пользователя заставляют менять пароль по расписанию, он предсказуемо выбирает более слабые варианты: Parol2024 → Parol2025. Меняйте пароль только при подтверждённой компрометации, утечке базы данных сервиса или подозрительной активности в аккаунте.

Чем парольная фраза лучше сложного пароля?

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

Где хранить уникальные пароли, если их много?

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

Насколько безопасна двухфакторная аутентификация через SMS?

SMS-коды защищают значительно лучше, чем отсутствие второго фактора, но уязвимы для перехвата через SIM-свопинг и фишинговые страницы в реальном времени. Для критически важных аккаунтов используйте TOTP-приложение или аппаратный ключ FIDO2 — они не зависят от телефонной сети и устойчивы к фишингу.

Как должна выглядеть современная корпоративная парольная политика?

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

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

Блог ПассворкаИлья Шелыгин

Двухфакторная аутентификация для бизнеса: внедрение и защита

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

Блог ПассворкаИлья Шелыгин

Кейс-стади: МТС Банк и Пассворк

Как МТС Банк объединил управление паролями в единой системе с помощью Пассворка и повысил уровень безопасности.

Блог ПассворкаАнастасия Лебедева

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

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

Рассмотрим, чем эти методы отличаются, какие алгоритмы актуальны сегодня и как выстроить защиту учётных данных с учётом не только кода, но и человеческого фактора.

Главное

1. Шифрование обратимо: компрометация сервера означает компрометацию ключа, а значит — всех паролей сразу. Для хранения паролей используют хэширование.
2. Хэш необратим, но детерминирован. Одинаковый пароль всегда даёт одинаковый хэш. Без соли злоумышленник, взломавший один хэш, автоматически получает доступ ко всем аккаунтам с таким же паролем.
3. Соль делает каждый хэш уникальным. Уникальная случайная строка, добавляемая к паролю перед хэшированием, нейтрализует радужные таблицы и массовые атаки. Соль хранится в БД открыто — её цель не секретность, а уникальность.
4. Перец закрывает сценарий утечки базы данных. Секретная строка, хранящаяся вне БД, делает перебор невозможным даже при наличии полного дампа с хэшами и солями. Перец не заменяет соль — только дополняет её.

Шифрование и хэширование: в чём принципиальная разница

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

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

Шифрование обратимо. Это его суть и одновременно проблема. Чтобы расшифровать данные, нужен ключ. Ключ хранится на сервере. Сервер компрометируют — ключ утекает вместе с базой. Злоумышленник получает и зашифрованные пароли, и инструмент для их расшифровки.

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

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

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

OWASP формулирует это прямо: пароли должны хэшироваться, а не шифроваться — за редкими исключениями, когда приложение вынуждено передавать пароль во внешнюю систему, не поддерживающую современные методы аутентификации (OWASP Password Storage Cheat Sheet).

Как работает хэш-функция

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

Хэш-функция принимает данные произвольной длины и возвращает строку фиксированного размера — хэш. Один и тот же входной пароль всегда даёт одинаковый хэш. Изменение даже одного символа полностью меняет результат.

Свойства хэш-функции

• Детерминированность. Одинаковый вход — всегда одинаковый выход. Это позволяет проверять пароль при входе: система хэширует введённый пароль и сравнивает с хранимым хэшем.
• Необратимость. Из хэша нельзя получить исходный пароль — только перебором вариантов.
• Эффект лавины. Минимальное изменение входных данных кардинально меняет хэш. Пароль password и Password дают совершенно разные хэши — никакой корреляции.
• Устойчивость к коллизиям. Два разных входа не должны давать одинаковый хэш. MD5 и SHA-1 эту устойчивость утратили — это одна из причин их непригодности.

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

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

Именно эту уязвимость закрывает соль.

Что такое соль и как она защищает пароли

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

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

Зачем нужна соль

1. Нейтрализация радужных таблиц. Хакер не может использовать готовые базы предвычисленных хэшей. Поскольку соль уникальна для каждого пользователя, хакеру придется вычислять радужную таблицу заново для каждой отдельной учётной записи, что делает атаку вычислительно нецелесообразной.
2. Скрытие одинаковых паролей. Соль гарантирует уникальность выходного хэша. Даже если у 100 сотрудников пароль Password123, в базе данных будут храниться 100 совершенно разных хэш-строк. Это не позволяет злоумышленнику выявлять группы пользователей со слабыми или стандартными паролями по совпадению хэшей.

Как правильно генерировать соль

• Минимум 128 бит (16 байт) длины
• Генерировать через криптографически стойкий генератор случайных чисел (CSPRNG) — os.urandom() в Python, random_bytes() в PHP, SecureRandom в Java
• Уникальная для каждого пользователя и каждой смены пароля

Без соли два пользователя с паролем qwerty123 имеют идентичные хэши. Атакующий взламывает один — получает доступ ко всем аккаунтам с таким паролем. С солью каждый хэш уникален, и атака масштабируется линейно с числом пользователей.

Соль решает проблему массовых атак и радужных таблиц. Но у неё есть архитектурное ограничение: она хранится в базе данных рядом с хэшем. Если злоумышленник получил полный дамп БД — через SQL-инъекцию, уязвимость в резервной копии или инсайдерский доступ — у него есть всё необходимое для перебора: хэши и соли каждого пользователя. Атака становится медленнее, но не невозможной.

Для этого сценария существует отдельный механизм защиты.

Что такое перец и чем он отличается от соли

Перец — секретная строка, общая для всех паролей в системе. В отличие от соли, перец не хранится в базе данных.

Перец добавляется к паролю перед хэшированием. Если базу украдут, без перца хэши никак не взломать подбором.

Сценарий, где перец критичен: злоумышленник получил полный дамп базы данных через SQL-инъекцию. У него есть все хэши и все соли. Без перца он может начать перебор. С перцем — каждый хэш вычислен с учётом секретной строки, которой в БД нет. Атака упирается в неизвестный параметр.

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

Как Пассворк защищает пароли: архитектура шифрования

Zero Knowledge: сервер не знает ничего

Архитектура Пассворка реализует принцип Zero Knowledge: сервер хранит только зашифрованные данные и зашифрованные ключи. Расшифровать их без мастер-пароля пользователя невозможно — в том числе администраторам сервера и техническим специалистам компании.

Мастер-пароль никогда не покидает устройство пользователя. Все криптографические ключи генерируются на клиенте — в браузере или приложении. Сервер получает уже зашифрованный материал.

Двухуровневая защита

Пассворк применяет два независимых уровня шифрования, которые работают одновременно.

• Клиентское шифрование (CSE) выполняется до отправки данных на сервер. Алгоритм — AES-256-CBC. Ключи генерируются из мастер-пароля через PBKDF2 с 300 000 итерациями и SHA-256. Этот уровень обеспечивает Zero Knowledge: даже при полной компрометации сервера данные остаются нечитаемыми.
• Серверное шифрование работает всегда — независимо от того, включено ли клиентское. Алгоритм — AES-256-CFB. Данные шифруются перед записью в базу данных. Серверный ключ (256 бит) хранится отдельно от БД и ротируется по расписанию.

Иерархия ключей

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

Ключ сейфа шифруется публичным RSA-ключом пользователя и хранится в зашифрованном виде. Приватный RSA-ключ зашифрован мастер-ключом, который выводится из мастер-пароля через PBKDF2. Цепочка замкнута на мастер-пароле — единственном секрете, который знает только пользователь.

Пассворк следует методологиям OWASP и требованиям ISO 27001. Компания имеет лицензии ФСТЭК на техническую защиту конфиденциальной информации (ТЗКИ) и создание средств криптографической защиты (СКЗИ), а также лицензию ФСБ на деятельность, связанную с шифровальными средствами.

Как Пассворк реализует эти принципы на практике

Пассворк построен на архитектуре Zero Knowledge с клиентским шифрованием. Система спроектирована так, что утечка данных невозможна даже при полной компрометации сервера.

• Сервер не знает мастер-пароль. Пассворк не хранит его ни в открытом виде, ни в виде хэша. Мастер-пароль никогда не покидает устройство пользователя.
• Ключ генерируется локально. При вводе мастер-пароля он не передаётся по сети. Непосредственно на устройстве — в браузере или приложении — запускается PBKDF2 с сотнями тысяч итерациями. Результат: криптографический ключ, который существует только в памяти клиента.
• Шифрование до отправки. Полученный ключ шифрует все данные сейфа по стандарту AES-256 прямо на устройстве. На сервер уходит уже зашифрованный криптоконтейнер.
• Второй уровень защиты. Серверное шифрование AES-256-CFB работает независимо и постоянно — даже если клиентское шифрование отключено. Резервные копии и дамп базы данных содержат только шифротекст.

Злоумышленник, получивший доступ к серверу или перехвативший трафик, получит набор зашифрованных байтов без какой-либо возможности восстановить исходные данные. Радужные таблицы и GPU-фермы здесь бесполезны: слабые алгоритмы вроде MD5 в этой цепочке отсутствуют, а PBKDF2 с сотнями тысяч итераций делает перебор вычислительно нецелесообразным.

Заключение

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

Но серверная архитектура закрывает только одну сторону проблемы. В корпоративной среде у вас не одна база пользователей — сотни сервисов, десятки команд, постоянная ротация сотрудников. Технически безупречное хэширование на бэкенде не поможет, если разработчик хранит пароль от продакшн-базы в мессенджере, а уволившийся администратор всё ещё знает мастер-пароль от сервера.

Здесь серверные меры должны дополняться инструментами управления на стороне клиента.

Пассворк закрывает эту часть задачи. Архитектура Zero Knowledge гарантирует, что сервер физически не располагает данными для расшифровки: мастер-пароль не покидает устройство, ключи генерируются локально, на сервер уходит только зашифрованный криптоконтейнер.

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

Часто задаваемые вопросы

Стратегия информационной безопасности: руководство для бизнеса

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

Блог ПассворкаАнастасия Лебедева

Почему бизнес выбирает расширенную версию Пассворка

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

Блог ПассворкаАнастасия Лебедева

Кейс-стади: МТС Банк и Пассворк

Как МТС Банк объединил управление паролями в единой системе с помощью Пассворка и повысил уровень безопасности.

Блог ПассворкаАнастасия Лебедева