Когда база данных утекает в сеть, первый вопрос не «как это случилось», а «что именно украли». Если пароли хранились правильно, утечка — это инцидент. Если нет — катастрофа: злоумышленник получает готовые учётные данные пользователей.
Выбор метода хранения паролей — архитектурное решение, которое принимается один раз, но последствия которого живут годами. Шифрование, хэширование и «соление» паролей решают разные задачи и имеют разные границы применимости. Путаница между ними — одна из самых распространённых причин уязвимостей на бэкенде.
Рассмотрим, чем эти методы отличаются, какие алгоритмы актуальны сегодня и как выстроить защиту учётных данных с учётом не только кода, но и человеческого фактора.
Главное
- Шифрование обратимо: компрометация сервера означает компрометацию ключа, а значит — всех паролей сразу. Для хранения паролей используют хэширование.
- Хэш необратим, но детерминирован. Одинаковый пароль всегда даёт одинаковый хэш. Без соли злоумышленник, взломавший один хэш, автоматически получает доступ ко всем аккаунтам с таким же паролем.
- Соль делает каждый хэш уникальным. Уникальная случайная строка, добавляемая к паролю перед хэшированием, нейтрализует радужные таблицы и массовые атаки. Соль хранится в БД открыто — её цель не секретность, а уникальность.
- Перец закрывает сценарий утечки базы данных. Секретная строка, хранящаяся вне БД, делает перебор невозможным даже при наличии полного дампа с хэшами и солями. Перец не заменяет соль — только дополняет её.
Шифрование и хэширование: в чём принципиальная разница
Шифрование — это обратимое математическое преобразование информации из читаемого вида в зашифрованный с помощью специального алгоритма и криптографического ключа.
Первый инстинкт при работе с паролями — зашифровать их. Логика понятна: данные скрыты, посторонний не прочитает. Но у шифрования есть фундаментальный изъян применительно к паролям.
Шифрование обратимо. Это его суть и одновременно проблема. Чтобы расшифровать данные, нужен ключ. Ключ хранится на сервере. Сервер компрометируют — ключ утекает вместе с базой. Злоумышленник получает и зашифрованные пароли, и инструмент для их расшифровки.
Даже если ключ хранится отдельно, это лишь усложняет атаку, но не исключает её. Достаточно скомпрометировать приложение в момент, когда оно расшифровывает пароль для проверки, и данные открыты. Атаки на память процесса, уязвимости в коде, инсайдерский доступ — векторов достаточно.
Есть и операционная проблема: управление ключами. Ключи нужно хранить, ротировать, защищать. При утечке ключа — перешифровывать всю базу. Это инфраструктурная нагрузка, которая не добавляет реальной защиты паролям.
Хэширование устраняет саму возможность обратного преобразования. Хэш-функция принимает пароль и возвращает строку фиксированной длины — и этот процесс односторонний. Нет ключа, нет расшифровки, нет вектора атаки через компрометацию ключа. При проверке пароля система хэширует введённое значение и сравнивает с хранимым хэшем — оригинал ей не нужен.
| Критерий | Шифрование | Хэширование |
|---|---|---|
| Обратимость | Обратимо (при наличии ключа) | Необратимо |
| Ключ | Требуется | Не требуется |
| Применение для паролей | Только в исключительных случаях | Стандартный подход |
| Что хранится в БД | Зашифрованный пароль + ключ | Хэш + соль |
OWASP формулирует это прямо: пароли должны хэшироваться, а не шифроваться — за редкими исключениями, когда приложение вынуждено передавать пароль во внешнюю систему, не поддерживающую современные методы аутентификации (OWASP Password Storage Cheat Sheet).
Как работает хэш-функция
Хэширование — это одностороннее математическое преобразование массива данных произвольного объёма в уникальную битовую строку фиксированной длины (хэш или дайджест).
Хэш-функция принимает данные произвольной длины и возвращает строку фиксированного размера — хэш. Один и тот же входной пароль всегда даёт одинаковый хэш. Изменение даже одного символа полностью меняет результат.
Свойства хэш-функции
- Детерминированность. Одинаковый вход — всегда одинаковый выход. Это позволяет проверять пароль при входе: система хэширует введённый пароль и сравнивает с хранимым хэшем.
- Необратимость. Из хэша нельзя получить исходный пароль — только перебором вариантов.
- Эффект лавины. Минимальное изменение входных данных кардинально меняет хэш. Пароль
passwordиPasswordдают совершенно разные хэши — никакой корреляции. - Устойчивость к коллизиям. Два разных входа не должны давать одинаковый хэш. MD5 и SHA-1 эту устойчивость утратили — это одна из причин их непригодности.
Но здесь кроется проблема, которую свойства хэш-функции не решают сами по себе. Детерминированность — одновременно сильная и слабая сторона: одинаковый вход всегда даёт одинаковый выход. Это значит, что два пользователя с паролем qwerty123 имеют идентичные хэши в базе данных.
Злоумышленник, получивший дамп, взламывает один хэш — и автоматически получает доступ ко всем аккаунтам с таким же паролем. А предвычисленные радужные таблицы позволяют сопоставить миллионы хэшей с известными паролями за секунды, без какого-либо перебора.
Именно эту уязвимость закрывает соль.
Что такое соль и как она защищает пароли
Соль — уникальная случайная строка, добавляемая к каждому паролю перед хэшированием. Даже если два пользователя используют одинаковый пароль, их хэши будут разными.
В отличие от пароля соль создаёт только машина. Это гарантирует, что входные данные для хэш-функции всегда будут длинными, сложными и уникальными.
Зачем нужна соль
- Нейтрализация радужных таблиц. Хакер не может использовать готовые базы предвычисленных хэшей. Поскольку соль уникальна для каждого пользователя, хакеру придется вычислять радужную таблицу заново для каждой отдельной учётной записи, что делает атаку вычислительно нецелесообразной.
- Скрытие одинаковых паролей. Соль гарантирует уникальность выходного хэша. Даже если у 100 сотрудников пароль
Password123, в базе данных будут храниться 100 совершенно разных хэш-строк. Это не позволяет злоумышленнику выявлять группы пользователей со слабыми или стандартными паролями по совпадению хэшей.
Как правильно генерировать соль
- Минимум 128 бит (16 байт) длины
- Генерировать через криптографически стойкий генератор случайных чисел (CSPRNG) —
os.urandom()в Python,random_bytes()в PHP,SecureRandomв Java - Уникальная для каждого пользователя и каждой смены пароля
Без соли два пользователя с паролем qwerty123 имеют идентичные хэши. Атакующий взламывает один — получает доступ ко всем аккаунтам с таким паролем. С солью каждый хэш уникален, и атака масштабируется линейно с числом пользователей.
Соль решает проблему массовых атак и радужных таблиц. Но у неё есть архитектурное ограничение: она хранится в базе данных рядом с хэшем. Если злоумышленник получил полный дамп БД — через SQL-инъекцию, уязвимость в резервной копии или инсайдерский доступ — у него есть всё необходимое для перебора: хэши и соли каждого пользователя. Атака становится медленнее, но не невозможной.
Для этого сценария существует отдельный механизм защиты.
Что такое перец и чем он отличается от соли
Перец — секретная строка, общая для всех паролей в системе. В отличие от соли, перец не хранится в базе данных.
Перец добавляется к паролю перед хэшированием. Если базу украдут, без перца хэши никак не взломать подбором.
Сценарий, где перец критичен: злоумышленник получил полный дамп базы данных через SQL-инъекцию. У него есть все хэши и все соли. Без перца он может начать перебор. С перцем — каждый хэш вычислен с учётом секретной строки, которой в БД нет. Атака упирается в неизвестный параметр.
Важное предупреждение: перец не заменяет соль. OWASP прямо указывает, что перец сам по себе не добавляет криптографической стойкости — только дополнительный уровень защиты при компрометации базы данных. Соль обязательна; перец — рекомендуемое дополнение.
| Критерий | Соль | Перец |
|---|---|---|
| Уникальность | Уникальна для каждого пользователя | Общая для всей системы |
| Хранение | В БД рядом с хэшем (открыто) | Вне БД (конфиг сервера, HSM) |
| Секретность | Не секретна | Секретна |
| Защита от | Радужных таблиц, массовых атак | Взлома при утечке только БД |
| Обязательность | Обязательна | Рекомендуется как дополнение |
Как Пассворк защищает пароли: архитектура шифрования
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 гарантирует, что сервер физически не располагает данными для расшифровки: мастер-пароль не покидает устройство, ключи генерируются локально, на сервер уходит только зашифрованный криптоконтейнер.
Двойное шифрование означает, что дамп базы данных не даёт злоумышленнику ничего пригодного. Централизованное управление правами, гранулярный контроль доступа к сейфам и журнал действий решают операционную проблему: кто, к чему и когда имел доступ.
Часто задаваемые вопросы
Чем хэширование отличается от шифрования применительно к паролям?
Шифрование обратимо: тот, у кого есть ключ, восстанавливает исходный пароль. Хэширование необратимо: из хэша математически невозможно получить пароль — только перебором. Для хранения паролей на бэкенде это принципиально. При компрометации сервера злоумышленник, получивший зашифрованные пароли вместе с ключом, получает всё. Злоумышленник, получивший хэши, получает материал для перебора — но не готовые учётные данные.
Что такое шифрование?
Шифрование — это математическое преобразование данных в нечитаемый вид с помощью криптографического ключа. Главное свойство шифрования — обратимость. Тот, у кого есть ключ, может расшифровать информацию обратно в обычный текст. Поэтому шифрование нельзя использовать для проверки паролей на бэкенде: если хакер украдёт базу данных вместе с ключом, он получит все пароли в открытом виде. Стандарт AES-256 — это единственный верный метод для менеджеров паролей, где ключи генерируются локально и сервер не имеет к ним доступа.
Что такое хэш?
Хэш — это результат работы односторонней математической функции, которая превращает любой объём данных в уникальную битовую строку фиксированной длины. В отличие от шифрования, хэширование необратимо. Из правильного хэша невозможно математически восстановить исходный пароль. При авторизации сервер не знает ваш пароль: он просто хэширует введённые символы и сравнивает результат с хэшем из базы.
Зачем нужна соль, если хэш и так необратим?
Хэш-функция детерминирована: одинаковый пароль всегда даёт одинаковый хэш. Без соли злоумышленник, взломавший один хэш от пароля qwerty123, автоматически компрометирует все аккаунты с таким же паролем. Кроме того, предвычисленные радужные таблицы позволяют сопоставить миллионы хэшей с известными паролями за секунды. Соль делает каждый хэш уникальным — даже если у ста сотрудников одинаковый пароль, в базе будет сто разных хэш-строк.
Чем «перец» отличается от «соли»?
Перец — это секретный криптографический ключ, который также добавляется к паролю перед хэшированием. Но, в отличие от соли, перец никогда не хранится в базе данных. Его держат изолированно: в переменных окружения, конфигурационных файлах или аппаратных модулях. Если злоумышленник найдёт SQL-инъекцию и скачает всю базу данных с хэшами и солью, он не сможет начать перебор (брутфорс), пока не взломает ещё и сервер приложения, чтобы добыть перец.
Зачем хранить соль в открытом виде рядом с хэшем?
Соль не является секретом — её цель не скрытность, а уникальность. Даже зная соль, злоумышленник не может использовать предвычисленные радужные таблицы и вынужден перебирать каждый пароль отдельно. Секретность соли не добавляет защиты, но усложняет реализацию.
Защищает ли перец от брутфорса, если злоумышленник знает алгоритм?
Перец защищает только при условии, что он не скомпрометирован. Если атакующий получил дамп БД, но не имеет доступа к конфигурации сервера или HSM — перец делает каждый хэш невзламываемым без знания секретной строки. Если же скомпрометированы и БД, и конфигурация сервера — перец не помогает. Именно поэтому его хранят в отдельной защищённой среде.
Анастасия Лебедева
Анастасия Лебедева
Анастасия Лебедева