2. Две «половины» пароля хэшируются независимо друг от друга. Таким образом, обе 7-символьные части пароля могут подбираться перебором независимо друг от друга, и пароли длиной более семи символов не сильнее паролей длиной в семь символов. Следовательно, для гарантированного нахождения пароля необходимо перебрать вместо 940 + 941 + … + 9414 = 4 х 1027 всего лишь 680 + 681 + … + 687 = 7 х 1012 = 243 комбинации (то есть почти в 1015 раз меньше).
...
По логике вещей эту сумму надо было умножить на два, так как необходимо перебирать две половинки хэша. Но нетрудно оптимизировать атаку так, чтобы перебрались все пароли только по одному разу, сравнивая поочередно их хэш-значение с каждой половинкой, что сократит время перебора почти в два раза.
Кроме того, пароли, длина которых не превышает семи символов, очень легко распознать, поскольку вторая половина хэша будет одним и тем же значением AAD3B435B51404EE, получаемым при шифровании фиксированной константы с помощью ключа из семи нулей.
3. Скорость перебора паролей в 15 раз больше, чем в UNIX, и достигает 190 000 паролей/с на Pentium 166.
4. Нет элемента случайности (привязки (salt), как это сделано в crypt()) – два пользователя с одинаковыми паролями всегда будут иметь одинаковые значения хэш-функции. Таким образом, можно заранее составить словарь хэшированных паролей и осуществлять поиск неизвестного пароля. Это позволит увеличить скорость перебора на несколько порядков.
Итак, хэш-функция, разработанная на базе того же самого алгоритма DES, но на 10–15 лет позже функции crypt(), оказывается хуже последней по всем параметрам, а именно:
• по мощности перебора для гарантированного подбора пароля – почти в 1 000 раз;
• по скорости перебора – почти в 15 раз;
• по отсутствию случайности, что приводит к уменьшению требуемой памяти для хэширования каждого пароля, – в 4 096 раз.
Не удивительно, что фирме Microsoft пришлось разрабатывать более криптостойкую функцию (точнее, не изобретать велосипед, который мог оказаться с квадратными колесами, а воспользоваться готовым образцом).
Хэш Windows NT вычисляется следующим образом.
1. Пароль длиной до 128 символов преобразуется в строку в кодировке Unicode, при этом сохраняются разные регистры.
2. Эта строка хэшируется с помощью MD4, что дает в результате 16-байтовое значение хэш-функции.
Хэш Windows NT обладает преимуществом по сравнению с функцией хэша Lan Manager – различаются регистры, пароли могут быть длиннее 14 символов, для хэширования используется весь пароль в целом, а не его части, хотя по-прежнему отсутствует элемент индивидуальности. Таким образом, люди, имеющие одинаковые пароли, всегда будут иметь одинаковые хэш-значения.
Удаленная аутентификация
Механизм удаленной регистрации на сервере (надо отдать должное разработчикам Windows NT) более надежен тем, что ни пароль пользователя, ни его хэш не передаются по сети в открытом виде (по крайней мере, в последних диалектах SMB). Впрочем, это не оригинальная находка Microsoft, а стандартный механизм большинства систем клиент – сервер, если связь между ними осуществляется по небезопасным каналам.
Функционирует механизм удаленной аутентификации, называемый «запрос-отклик», таким образом:
1. Клиент выдает команду на подключение к серверу.
2. Сервер либо возвращает пакет, в котором присутствует флаг, требующий от клиента передавать пароль в открытом виде (то есть сервер не поддерживает последние диалекты SMB), либо возвращает 8-байтовый случайный запрос (chаllenge). Далее рассматривается только последний вариант.
3. Клиент вычисляет LM-хэш введенного пароля, добавляет к нему пять нулей, получая таким образом 21-байтовую строку. Далее он делит ее на три 7-байтовых части, каждая из которых используется как отдельный ключ в алгоритме DES, – на этих ключах независимо три раза зашифровывается полученный запрос, что приводит к появлению 24-разрядного шифрованного значения. Поскольку клиент не знает, значения каких хэш-функций определены для данного пользователя в базе данных SAM на сервере, то он поступает аналогично и с хэш-функцией Windows NT. Таким образом, длина отклика клиента достигает 48 байт.
4. Сервер ищет то значение хэш-функции в своей базе данных SAM, которое присуще данному пользователю, аналогично шифрует запрос с его помощью и сравнивает с нужной половиной полученного отклика. Если значения совпадают, аутентификация считается состоявшейся.
Из сказанного можно сделать следующие выводы:
Читать дальше