14.4. Хранение паролей и аутентификация в ОС

Для усложнения подбора пароля и защиты от словарной атаки перед процедурой хеширования к паролю добавляется «соль» – случайная битовая строка. «Солью» (salt) называется (псевдо-)случайная битовая строка $s$, добавляемая к аргументу $m$ (паролю) функции хеширования $h(m)$ для рандомизации хеширования одинаковых сообщений.

Словарная атака заключается в том, что злоумышленник один раз заранее вычисляет таблицы хешей от наиболее вероятных сообщений, то есть составляет словарь пароль-хеш, и далее производит поиск по вычисленной таблице для взламывания исходного сообщения. Ранее словарные атаки использовались для взлома паролей $m$, которые хранились в виде обычных хешей $h(m)$. Усовершенствованной словарной атакой является метод радужных таблиц, позволяющий практически взламывать хеши длиной до 64--128 бит. Использование «соли» делает невозможной словарную атаку, так как значение функции вычисляется уже не от оригинального пароля, а от конкатенации «соли» и пароля.

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

• $s ~\|~ h(s ~\|~ m)$;
• $s ~\|~ h(m ~\|~ s)$;
• $s_1 ~\|~ h(m ~\|~ s_1 ~\|~ s_2)$.

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

В рассмотренной ранее модели построения паролей в виде слогов с элементами небольшой модификации мы получили количество паролей около $2^{70}$ для 12-символьных паролей. Данный объём вычислений уже почти достижим. Следовательно, даже «соль» не защищает пароли от взлома, если у злоумышленника есть доступ к файлу с паролями или возможность неограниченных попыток аутентификации. Поэтому файлы с паролями дополнительно защищаются, а в системы аутентификации по паролю вводят ограничения на неуспешные попытки аутентификации.

14.4.1. Хранение паролей в Unix

В ОС Unix данные пароля пользователей хранятся в специальном файле /etc/shadow, запрещённого к чтению для обычных (не привилегированных) пользователям и сервисам. Данные хранятся в виде хеша (SHA, MD5 и т. д.) или результата шифрования (DES, Blowfish и т. д.), вычисленного с «солью» $s$ длиной от 2 (для функции crypt в оригинальной ОС UNIX) до 16 (для Blowfish в OpenBSD) ASCII-символов. То, как используется «соль», зависит от используемого алгоритма. Например, в традиционном алгоритме, используемом в оригинальном UNIX, «соль» модифицирует s-блоки и p-блоки в протоколе DES.

14.4.2. Хранение паролей и аутентификация в Windows

ОС Windows, начиная с Vista, Server 2008, Windows 7, сохраняет пароли в виде NT-хеша, который вычисляется как 128-битовый хеш MD4 от пароля в Unicode кодировке. NT-хеш не использует «соль», поэтому применима словарная атака. На словарной атаке основаны программы поиска (взлома) паролей для Windows. Файл паролей называется SAM (англ. Security Account Manager) в случае локальной аутентификации. Если пароли хранятся на сетевом сервере, то они хранятся в специальном файле, доступ к которому ограничен.

В последнем протоколе аутентификации NTLMv2 [81] пользователь для входа в свой компьютер аутентифицируется либо локально на компьютере, либо удалённым сервером, если учётная запись пользователя хранится на сервере. Пользователь с именем $user$ вводит пароль в программу-клиент, которая, взаимодействуя с программой-сервером (локальной или удалённой на сервере домена $domain$), аутентифицирует пользователя для входа в систему.

1. Клиент $\rightarrow$ Сервер: запрос аутентификации.
2. Клиент $\leftarrow$ Сервер: 64-битовая псевдослучайная одноразовая метка $n_s$.
3. Вводимый пользователем пароль хешируется в $\textrm{NThash}$ без «соли». Клиент генерирует 64-битовую псевдослучайную одноразовую метку $n_c$, создаёт метку времени $ts$. Далее вычисляются 128-битовые имитовставки ${\textrm{HMAC}}$ на хеш-функции MD5 с ключами $\textrm{NT-hash}$ и $\textrm{NTOWF}$:
   $$ \textrm{NThash} = \text{MD4}(\text{Unicode}(\text{пароль})), $$
   $$ \textrm{NTOWF} = \textrm{HMAC-MD5}_{\textrm{NThash}}(user, domain), $$
   $$ \textrm{NTLMv2-response} = \textrm{HMAC-MD5}_{\textrm{NTOWF}}(n_c, n_s, ts, domain). $$
4. Клиент $\rightarrow$ Сервер: $(n_c, \textrm{NTLMv2-response})$.
5. Сервер для указанных имён пользователя и домена извлекает из базы паролей требуемый NT-hash, производит аналогичные вычисления и сравнивает значения имитовставок. Если они совпадают, аутентификация успешна.

В случае аутентификации на локальном компьютере сравниваются значения $\textrm{NTOWF}$: вычисленные от пароля пользователя и извлечённые из файла паролей SAM.

Как видно, протокол аутентификации NTLMv2 обеспечивает одностороннюю аутентификацию пользователя серверу (или своему ПК).

При удалённой аутентификации по сети последние версии ОС Windows используют протокол Kerberos (см. раздел 13.1), который обеспечивает взаимную аутентификацию клиента и сервера, и, только если аутентификация по Kerberos не поддерживается клиентом или сервером, она происходит по NTLMv2.