Последствия разрешения клиентам Windows использовать NTLMv1?
Это - действительно плохая практика, отчасти как то, чтобы позволять WEP защитить Ваш WiFi, потому что у Вас есть компьютер Windows 98, который не будет работать с WPA2. Это - 2009, работы Kerberos, если Вы действительно, действительно нуждайтесь в SSO.
Я также полагаю, что интегрированная аутентификация для веб-сайтов плохая практика в целом, поскольку она часто приводит к чудным проблемам, когда у пользователей есть несколько учетных записей (мы используем отдельного пользователя / администраторские учетные записи), требует Вы слоняться без дела с зонами доверия IE и требует, чтобы Вы использовали IE или играли с настройками Firefox.
Учитывая trainwreck, что IE был и продолжает быть с 2002 или каждый раз, когда IE6 вышел, (т.е. из патча полосы ActiveX) Вы действительно хотите согласиться на платформу?
-
1Этот isn' t продукт Microsoft и it' s даже не работающий на сервере Microsoft. Что я don' t как идея пользователей, вводящих имена пользователей и пароли в веб-приложение. Угадайте который пароль they' ре, собирающееся использовать? Так you' ve сохранил пароли пользователя в домене в кэшах браузера на всем протяжении сети. Это конкретное приложение может, предположительно, сделать Kerberos, но I' ve испытал трудности с ним в прошлом. Я не знаю. – Boden 30 July 2009 в 18:34
-
2Internet Explorer будет кэшировать учетные данные также. Посмотрите на " Documents and Settings\Application Data\Microsoft\Credentials\< SID> \Credentials" каталог. You' ре, более обеспеченное просто, имеющие пользователи проходят проверку подлинности на веб-сайте, таким образом, по крайней мере, TLS защитит пароли в полете. Укрепление сохраненных паролей в браузере isn' t тривиальная вещь сделать, но it' s лучше, чем доверие дефектному протоколу. – duffbeer703 30 July 2009 в 19:14
-
3Разъяснение: Я должен был сказать " IE будет кэшировать учетные данные NTLM как well" – duffbeer703 30 July 2009 в 19:15
NTLM был заменен NTLMv2 в NT4.0 SP4. Это более чем десятилетие назад. NTLM более тверд, чем LM расколоться для паролей, и NTLMv2 намного более тверд. Существует причина значения по умолчанию Vista к NTLMv2 только. Таблицы радуги были составлены для полного пространства пароля LM, и в последний раз я слышал, что работа хорошо происходила, чтобы сделать то же для пространства NTLM. NTLMv2 еще не был сделан.
Да, существуют увеличенные угрозы безопасности путем выполнения этого. Имеют ли они значение для Вас, подлежит Вашей собственной оценке риска.
Как Adam и системный администратор заявили, это - очень плохая идея с точки зрения безопасности (не говоря уже о с точки зрения прежней версии, поскольку она была заменена в NT, 4 дня и NTLMv1 могли потенциально быть удалены из будущих версий Windows). Что относительно того, чтобы использовать Kerberos для authentication/SSO? Это более безопасно, чем даже NTLM v2, работает в сценариях двойного транзитного участка и будет поддерживаться (как внутри, так и за пределами Microsoft) для обозримого будущего.
Если бы у Вас есть что-либо чувствительное, я не сделал бы этого.
Если бы хакер осуществил сниффинг Вашего трафика NTLMv1 SMB, то они могли бы использовать что-то как Cain & Abel с Таблицами Радуги (HalfLMChall мог бы быть самым быстрым), или RainbowCrack для взламывания пароля. Если пароль является семью символами или меньше, это могло бы быть сделано через день.
NTLMv2 создает хеш с помощью других переменных в реальном времени и также использует 128-разрядное пространство пароля с MD5 (не шифрование DES на 64 бита), таким образом, это берет НАМНОГО дольше для взламывания (больше при взламывании NTLMv2 здесь).
NTLMv1 также хранит пароли локально в хешах, которые могут использоваться для аутентификации, не будучи должен знать старый пароль. Таким образом, если кто-то может владеть локальной машиной как локальный администратор, они могут извлечь хеши администратора домена или пользователя домена и получить информацию, они могут выйти из сервера, даже не зная их пароля (больше на этом здесь).
Если бы Вы действительно хотели пойти путем NTLMv1, то я удостоверился бы, что все пароли являются больше чем 14 символами и включают специальные символы.
Да, одна проблема с NTLMv1 состоит в том, что он использует DES, который в наше время считают слабым являющийся только 56-разрядным. Взламывание DES все еще трудно в этой точке, все же. Однако существует другая слабость. В NTLMv1 хеши LM/NT превращены в три различных ключа DES, и затем они используются для шифрования проблемы. Так как хеши являются 128-разрядными, и DES является только 56-разрядным, третий ключ является только 16-разрядным, с остальными заполненными нулями, помогая расколоться, разоблачающие два байта и NT и хешей LM. NTLMv2 зафиксировал это при помощи HMAC-MD5 вместо этого. У MS-CHAPv1 был тот же дефект также, и несмотря на то, что он прибыл в то же время, что и NTLMv2, MS-CHAPv2 не зафиксировал это. Интересно почему.
Править: Теперь CloudCracker имеет облачный сервис принуждения скота DES, который использует в своих интересах эту проблему в MS-CHAPv2.