Синхронизация хэша паролей

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

История и предпосылки

Потребность в синхронизации хэшей возникла с развитием корпоративных информационных систем и появлением распределённых сред, где один пользователь имеет учётные записи на нескольких серверах (например, в домене Windows или в кластере веб-приложений). Ранние решения (1980-е — начало 1990-х годов) предполагали либо хранение паролей в открытом виде на центральном сервере, либо использование протоколов аутентификации, не требующих синхронизации (например, Kerberos, где пароль не передаётся, а используется для получения билетов). Однако с ростом числа сервисов и необходимостью поддержки устаревших протоколов (NTLM, LAN Manager) возникла задача синхронизации хэшей между контроллерами домена.

В 1993 году Microsoft внедрила в Windows NT механизм репликации хэшей паролей (SAM — Security Account Manager) между контроллерами домена. Позднее, с появлением Active Directory (1999), синхронизация стала частью протокола репликации каталога. В Linux-средах аналогичные задачи решались через NIS (Network Information Service, 1985) и позднее через LDAP с синхронизацией хэшей (OpenLDAP, 1990-е).

Технические аспекты

Хэширование паролей

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

• NTLM-хэш (Windows): MD4 (16 байт). Уязвим к радужным таблицам, но широко распространён.
• SHA-512 (Linux, /etc/shadow): 512-битный хэш с солью.
• bcrypt, scrypt, Argon2: современные функции с адаптивной сложностью, устойчивые к атакам перебором.
• PBKDF2: функция, используемая в некоторых системах (например, в Apple iCloud Keychain).

При синхронизации обычно передаётся не сам хэш, а его криптографическая копия, защищённая канальным шифрованием (TLS, IPSec). В некоторых реализациях (например, в Active Directory) хэш дополнительно шифруется с использованием ключа сессии перед передачей.

Протоколы синхронизации

• Active Directory Replication: использует протокол DRSUAPI (Directory Replication Service API) поверх RPC. Хэши паролей передаются как часть атрибута unicodePwd в формате, зашифрованном ключом сессии Kerberos. Репликация происходит между контроллерами домена по расписанию (по умолчанию каждые 15 секунд).
• LDAP (Lightweight Directory Access Protocol): при синхронизации через LDAP-сервер (например, OpenLDAP) хэш пароля хранится в атрибуте userPassword. Репликация может быть настроена через Syncrepl (синхронная репликация) или Delta-syncrepl (инкрементальная). Хэш передаётся в открытом виде внутри LDAP-сообщения, поэтому обязательно использование TLS.
• NIS (Network Information System): устаревший протокол, где хэши паролей хранятся в файлах passwd и shadow на мастер-сервере и распространяются на клиенты через RPC без шифрования. Сейчас считается небезопасным.
• FreeIPA/Red Hat Identity Management: использует LDAP и Kerberos, синхронизация хэшей происходит через репликацию каталога 389 Directory Server.
• Azure AD Connect (Microsoft): синхронизация хэшей паролей между локальной Active Directory и облачным Azure Active Directory (ныне Microsoft Entra ID). Хэш пароля (SHA-256 от NTLM-хэша) передаётся по HTTPS с использованием сертификатов. Дополнительно применяется соль и итеративное хэширование для защиты от перебора.

Механизмы синхронизации

1. Полная синхронизация: передача всех хэшей паролей из источника в целевую систему. Выполняется при первоначальной настройке или после сбоя.
2. Инкрементальная синхронизация: передача только изменений (новые пароли, сбросы, блокировки). Реализуется через журналы изменений (Change Log) или механизмы отслеживания версий (USN — Update Sequence Number в Active Directory).
3. Синхронизация по запросу (on-demand): хэш передаётся только при попытке аутентификации пользователя на целевом сервере. Используется в некоторых реализациях SSO (например, в связке с Kerberos).

Применение

Корпоративные сети

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

Облачные сервисы и гибридные среды

Сервисы, такие как Microsoft Entra ID (ранее Azure AD), поддерживают синхронизацию хэшей паролей из локальной Active Directory. Это позволяет пользователям использовать те же пароли для доступа к облачным приложениям (Office 365, Dynamics 365, Azure) без необходимости создания отдельных учётных записей. Механизм синхронизации хэшей паролей (PHS — Password Hash Synchronization) является одним из трёх методов аутентификации в гибридных сценариях (наряду с Pass-through Authentication и Federation Services).

Системы управления идентификацией (IAM)

Продукты класса IAM (например, Okta, Ping Identity, One Identity) могут синхронизировать хэши паролей между различными каталогами (LDAP, Active Directory, базы данных приложений) для обеспечения единого входа. В таких системах синхронизация часто дополняется политиками паролей (сложность, срок действия, история).

Риски и уязвимости

Перехват и компрометация

Если канал синхронизации не зашифрован (например, при использовании NIS или LDAP без TLS), злоумышленник может перехватить хэши паролей. Даже при шифровании возможны атаки типа «человек посередине» (MITM) при неправильной настройке сертификатов. Перехваченные хэши могут быть использованы для атак перебором (офлайн-атаки) или для пассивного анализа (например, определение слабых паролей).

Распространение уязвимых хэшей

Если в одном сегменте сети используется слабая хэш-функция (например, LM-хэш, который легко ломается), синхронизация может распространить этот уязвимый хэш на другие системы, где он будет храниться и потенциально использоваться для аутентификации. В современных реализациях (Active Directory, начиная с Windows Vista/2008) LM-хэши отключены по умолчанию, но могут быть включены для обратной совместимости.

Атаки на репликацию

Злоумышленник, получивший доступ к контроллеру домена (или к репликационному трафику), может модифицировать хэши паролей при синхронизации (атака «золотой билет» в контексте Kerberos) или внедрить подставные хэши для создания бэкдоров. Для защиты используются цифровые подписи и проверка целостности (например, в Active Directory — подпись репликационных пакетов ключом сессии).

Проблемы с обратной совместимостью

При синхронизации между системами с разными хэш-функциями (например, NTLM и SHA-512) может потребоваться преобразование, которое снижает криптостойкость. Например, при синхронизации из Active Directory (NTLM) в Linux-систему (SHA-512) невозможно получить исходный пароль, но можно передать NTLM-хэш, который затем будет использоваться для проверки пароля через специальный модуль PAM (Pluggable Authentication Module). Это создаёт риск: NTLM-хэш, будучи более слабым, становится точкой атаки.

Альтернативы синхронизации хэшей

В некоторых архитектурах синхронизация хэшей не применяется, а используются другие методы:

• Kerberos: центральный сервер ключей (KDC) хранит пароль пользователя и выдаёт билеты, не передавая хэш другим системам. Синхронизация хэшей не требуется, так как аутентификация происходит через KDC.
• Федеративная аутентификация (SAML, OAuth, OpenID Connect): пользователь аутентифицируется на Identity Provider (IdP), который выдаёт токен, а целевые сервисы (Service Providers) принимают этот токен, не имея доступа к хэшу пароля.
• Pass-through Authentication (PTA): пароль пользователя проверяется непосредственно на локальном контроллере домена (или в облачном прокси) без сохранения хэша в облаке. Используется, например, в Microsoft Entra ID как альтернатива синхронизации хэшей.

Регулирование в Российской Федерации

В соответствии с законодательством РФ (Федеральный закон № 152-ФЗ «О персональных данных», Приказ ФСТЭК России № 21), при синхронизации хэшей паролей, содержащих персональные данные, требуется обеспечение криптографической защиты канала связи (ГОСТ 28147-89, ГОСТ Р 34.11-2012) и сертифицированных средств защиты информации. Использование иностранных криптоалгоритмов (SHA, MD4) в государственных информационных системах допускается только при наличии сертификата ФСБ России или при условии применения дополнительных мер защиты (например, туннелирование через VPN с российскими криптостандартами). Организации, признанные в РФ нежелательными (например, Meta Platforms, Inc. — признана экстремистской и запрещена в РФ), не могут выступать в качестве поставщиков решений для синхронизации хэшей в государственных и муниципальных учреждениях.

Источники

1. Microsoft Docs: «How password hash synchronization works in Azure AD Connect» (2021).
2. RFC 4511: Lightweight Directory Access Protocol (LDAP) — The Protocol (2006).
3. RFC 2307: An Approach for Using LDAP as a Network Information Service (1998).
4. K. Fu, E. Sit, K. Smith, N. Feamster: «The Dos and Don'ts of Client Authentication on the Web» (USENIX Security, 2001).
5. J. Kistler, M. Satyanarayanan: «Disconnected Operation in the Coda File System» (ACM Transactions on Computer Systems, 1992) — общие принципы репликации.
6. Федеральный закон № 152-ФЗ «О персональных данных» (2006, с изм. 2023).
7. Приказ ФСТЭК России № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных» (2013).