![]() |
![]() |
|
![]() |
Обсуждение ОС Вопросы, поиск, предложения |
![]() |
Десять мифов о паролях в Windows
|
Опции темы | Опции просмотра |
![]() |
#1 | |||||||||||||
Злое коТэ
![]() ![]() ![]() ![]()
|
Несмотря на все достижения в технологиях безопасности, один аспект остается неизменным: пароли все еще играют центральную роль в безопасности системы.
Проблема заключается в том, что они слишком часто могут служить простейшим механизмом для взлома. Несмотря на то, что существуют технологии и политики для того, чтобы сделать пароли более устойчивыми, до сих пор приходиться бороться с человеческим фактором. Ни для кого не является секретом, что пользователи часто в качестве паролей используют имена друзей, клички животных и т.д. Главная задача заключается в том, чтобы пользователи составляли надежные пароли. Однако, не всегда ясно, как достичь этого. Проблема состоит в том, что наши действия слишком предсказуемы. Например, в списке совершенно случайных слов, придуманных обычным человеком, непременно проявится некоторая общая закономерность. Выбор надежных паролей требует соответствующего обучения. Эти знания системные администраторы и должны распространить на конечных пользователей. Возможно, данная статья поможет вам разобраться в использовании паролей в Windows XP (всего семейства этой ОС) ... итак: Миф №1: хэши паролей достаточно надежны при использовании NTLMv2 Многие читатели хорошо знакомы со слабостью хэшей паролей LanManager (LM), что сделало столь популярным L0phtcrack. NTLM делает хэши несколько устойчивее, так как используется более длинный хэш и различаются символы в верхнем и нижнем регистрах. NTLMv2 является более совершенным, при этом вычисляется 128-битный ключ, и используются отдельные ключи для целостности и конфиденциальности. Кроме того, он использует алгоритм HMAC-MD5 для более высокой целостности. Однако Windows 2000 по-прежнему часто пересылает LM и NTLM хэши по сети, а NTLMv2 уязвим к атакам при передаче (также известным как replay). И, поскольку хэши паролей LM и NTLM по-прежнему хранятся в реестре, вы уязвимы и к атакам на SAM. Должно еще пройти какое-то время до тех пор, когда мы, наконец, освободимся от ограничений LanManager. А до тех пор не стоит надеяться, что хэши ваших паролей надежны. Миф №2. Dj#wP3M$c – наилучший пароль Общепринят миф, что полностью случайные пароли, полученные с помощью генератора паролей – наилучшие. Это не совсем так. Хотя они и могут быть действительно устойчивыми, такие пароли обычно сложны для запоминания, медленно набираемы и иногда уязвимы к атакам на алгоритм генерации паролей. Легко создать пароли, которые будут устойчивы к взлому, но труднее создать такие пароли запоминаемыми. Для этого существует несколько простых приемов. Например, рассмотрим пароль "[Ссылки могут видеть только зарегистрированные пользователи. ]". Этот пароль использует буквы в верхнем и нижнем регистрах, две цифры и два символа. Длина пароля 20 символов, но он может быть запомнен с минимумом усилий, возможно, вы его уже непроизвольно запомнили. Более того, этот пароль очень быстро набирается. В части "Makeit20" чередуются на клавиатуре клавиши левой и правой руки, что увеличивает скорость набора, сокращает количество опечаток и уменьшает шанс того, что кто-либо сможет подсмотреть ваш пароль, наблюдая за движениями ваших пальцев (давно созданы списки английских слов, чередующих клавиши под правую и левую руку, которые удобно использовать, как часть своего пароля. К примеру, список из восьми тысяч таких слов можно найти на [Ссылки могут видеть только зарегистрированные пользователи. ]) Лучшая техника для создания сложных, но легко запоминаемых паролей – использование структур, которые мы привыкли запоминать. Такие структуры также делают простым включение знаков препинания в пароль, как в примере адреса e-mail, использованном выше. Другие структуры, которые легки для запоминания – это телефонные номера, адреса, имена, пути к файлам, и т.д. Обратите внимание на некоторые элементы, которые позволяют нам упростить запоминание. Например, включение шаблонов, повторений, рифм, юмора и даже грубых (в том числе и матерных) слов создает пароли, которые мы никогда не забудем. Миф №3. 14 символов – оптимальная длина пароля В LM хэши паролей разделены на два 7-символьных хэша. Это фактически делает пароли более уязвимыми, поскольку атака грубой силы (brute-force) может быть применена к каждой половине пароля одновременно. То есть, пароли длиной 9 символов разделены на один 7-символьный хэш и один 2-символьный. Очевидно, что взлом 2-символьного хэша не займет много времени, а 7-символьная часть обычно взламывается за несколько часов. Часто короткая часть может существенно облегчить взлом длинного фрагмента. Из-за этого, многие профессионалы безопасности определили оптимальную длину пароля в 7 или 14 символов, соответствующую двум 7-символьным хэшам. NTLM несколько улучшил ситуацию за счет использования всех 14 символов для сохранения хэшей паролей. Хотя это действительно и облегчает жизнь, но диалоговое окно NT ограничивает пароль максимумом в 14 символов; таким образом, определяя пароли длиной ровно в 14 символов оптимальными для безопасности. Но все иначе в более новых версиях Windows. Пароли в Windows 2000 и XP могут иметь длину до 127 символов, таким образом, 14 символов уже не будет ограничением. Более того, одно маленькое обстоятельство, открытое Urity на SecurityFriday.com, состоит в том, что если длина пароля 15 символов или более, Windows даже не сохраняет корректно LanMan хэши. Если ваш пароль состоит из 15 или более символов, Windows сохраняет константу AAD3B435B51404EEAAD3B435B51404EE в качестве LM хэша, что эквивалентно нулевому паролю. А так как ваш пароль, очевидно, не нулевой, попытки взломать этот хэш ни к чему не приведут. Принимая это во внимание, использование паролей более 14 символов могло бы быть хорошим советом. Но если вы захотите сделать обязательным использование таких длинных паролей, используя политику групп или шаблоны безопасности, то столкнетесь с затруднением – ничто не даст вам возможность установить минимальную длину пароля более 14 символов. Миф №4. J0hn99 – Хороший пароль Хотя пароль "J0hn99" проходит по требованиям сложности Windows, он не столь сложен, как кажется на первый взгляд. Многие программы-взламыватели паролей перебирают миллионы вариантов слов в секунду. Замена буквы “o” на цифру “0” и добавление пары цифр – ерунда для таких программ. Некоторые программы-взламыватели даже проверяют наборы методов, которые обычно используют пользователи, что позволяет им подбирать даже довольно длинные и, на первый взгляд, удачные пароли. Лучший подход – быть менее предсказуемым. Вместо того чтобы заменять “o” на “0”, попробуйте заменить “o” на два символа “()”, как в “j()hn”. И, конечно, удлиняя пароль, вы увеличиваете его устойчивость. Миф №5. Любой пароль рано или поздно может быть взломан. Хотя любой пароль может быть вскрыт несколькими способами (например, через «клавиатурный шпион» или с помощью социотехники), тем не менее, существуют способы создания паролей, которые не могут быть взломаны за приемлемое время. Если пароль достаточно длинный, его взлом займет так много времени, или потребует так много вычислительной мощности, что это, по существу, то же самое, что если бы он был невзламываемым (по крайней мере, для большинства хакеров). Конечно, в конце концов, любой пароль может быть взломан, но это событие может произойти и не в течение нашей жизни, и даже не во время жизни наших правнуков. Таким образом, если, конечно не государственные структуры пытаются вычислить ваш пароль, то его шансы могут быть очень даже высоки. Хотя, возможно, достижения компьютерной технологии могут однажды сделать этот миф реальностью. Миф №6. Пароли нужно менять каждые 30 дней. Несмотря на то, что это - хороший совет для некоторых паролей с высокой степенью риска, он не подходит средним пользователям. Требование частой смены пароля зачастую заставляет пользователей создавать предсказуемые модели в своих паролях или использовать другие способы, которые реально значительно снижают их эффективность. Обывателю не нравится постоянно придумывать и запоминать новые пароли каждые 30 дней. Вместо того, чтобы ограничивать возраст пароля, лучше сосредоточиться на более устойчивых паролях и большей компетентности пользователей. Приемлемое время для среднего пользователя – от 90 до 120 дней. Если вы дадите пользователям больше времени, вам будет проще убедить их использовать более сложные пароли. Миф №7. Никогда не следует записывать свой пароль Хотя это и хороший совет, иногда просто необходимо записывать свои пароли. Пользователи чувствуют себя гораздо комфортнее при создании сложных паролей, если они уверены, что смогут его прочитать в надежном месте, если вдруг забудут. Однако важно обучить пользователей, как правильно записывать пароли. Наклейка на мониторе – это, бесспорно, глупо, но хранение пароля в сейфе или даже запирающемся ящике может быть достаточным. И не пренебрегайте безопасностью, когда приходит время выбрасывать бумагу со старым паролем: помните, многие крупные взломы произошли именно из-за того, что хакеры не поленились просматривать мусор организации в поисках записанных паролей. Может возникнуть идея позволить пользователям хранить свои пароли в программных утилитах для хранения паролей. Эти утилиты позволяют пользователю сохранять множество паролей в одном месте, закрытом главным мастер-паролем. Но если кто-то узнает мастер-пароль, то получит доступ к полному списку всех паролей. Поэтому, прежде чем позволить пользователям сохранять пароли в таком месте, рассмотрите следующие опасности: во-первых, этот метод программный, и, следовательно, уязвим для атаки, во-вторых, поскольку тут все держится на одном мастер-пароле, он может стать тем единственным пунктом для глобального провала всех паролей всех пользователей. Лучшая методика – совместить технологию, физическую безопасность и политику компании. Кроме того, пароли бывает просто необходимо документировать. Нет ничего необычного в ситуации, когда системный администратор заболел или уволился. А в ряде организаций – это единственный человек, который знал все пароли, в том числе и пароль сервера. Так что иногда приходится даже одобрять записывание паролей, но только в случае, когда это действительно необходимо и продумано. Миф №8. Пароль не может содержать пробелов Несмотря на то, что большинство пользователей этим не пользуется, Windows XP позволяет использование пробелов в паролях. Фактически, если вы можете видеть такой символ в Windows, то вы можете использовать его и в пароле. Следовательно, пробел – совершенно правомерный символ для пароля. Однако, поскольку некоторые приложения обрезают пробелы, лучше не начинать и не заканчивать пароль пробелом. Пробелы облегчают пользователям создание более сложных паролей. Поскольку пробел может использоваться между словами, то его использование может дать пользователям реальную возможность использовать длинные пароли из нескольких слов. Вообще, с пробелом очень интересная ситуация, он не попадает ни под одну категорию требований сложности пароля Windows. Это и не цифра, и не буква, и даже не считается символом. Таким образом, если вы желаете сделать ваш пароль более сложным, то пробел ничем не хуже любого символа и в большинстве случаев не снижает сложность паролей. Но хотелось бы сказать про один существенный недостаток, связанный с использованием пробела – его клавиша издает при нажатии уникальный звук, который ни с чем не спутать. Совсем несложно услышать, если кто-то использует пробел в своем пароле. В общем, используйте пробелы, но не злоупотребляйте ими. Миф №9. Всегда используйте Passfilt.dll Passfilt.dll – библиотека, вынуждающая пользователей использовать устойчивые пароли. В Windows это осуществляется с помощью политики “Пароль должен удовлетворять требованиям сложности”. Хотя зачастую это хорошая политика, некоторые пользователи могут огорчиться, когда их пароли отвергаются как недостаточно сложные. Даже опытным администраторам иногда приходится вводить несколько паролей, пока один из них не пройдет требования сложности. Огорченные пользователи, безусловно, не станут выражать поддержку в адрес вашей политики паролей. Если вы видите, что пользователям не нравятся требования сложности, пожалуй, лучшим выходом будет требование длинных паролей вместо этой политики. Если вы подсчитаете, вы увидите, что 9-символьный пароль, состоящий из букв в нижнем регистре, приблизительно такой же по сложности, как 7-символьный пароль, в котором используются буквы как нижнего, так и верхнего регистра и цифры. Единственная разница в том, как программы для взламывания паролей обрабатывает различные подмножества символов; некоторые взламыватели грубой силы перебирают все комбинации букв в нижнем регистре перед тем, как использовать цифры и другие символы. Другой вариант – взять Platform SDK sample в директории \samples\winbase\Security\WinNT\PwdFilt\ и изменить его так, чтобы он был более снисходителен в выборе пароля. Также можно обучить пользователей тому, как можно усложнить пароли и подсказать им несколько идей для этого. Миф №10. Используйте ALT+255 для наиболее устойчивого пароля Рассмотрим использование символов с большим ASCII-кодом для окончательного усложнения пароля. Эти символы не могут быть естественным образом набраны на клавиатуре, но вводятся удержанием кнопки ALT и набором ASCII-кода на цифровой клавиатуре. Например, последовательность ALT-0255 создает символ . Несмотря на то, что в некоторых ситуациях это полезно, следует также рассмотреть недостатки. Во-первых, удержание кнопки ALT и набор на цифровой клавиатуре могут быть легко замечены посторонними. Во-вторых, создание такого символа требует пять нажатий клавиш, что нужно запомнить и впоследствии вводить каждый раз при наборе пароля. Возможно, имело бы смысл создание пароля на пять символов длиннее, что сделало бы ваш пароль гораздо устойчивее при том же самом количестве нажатий клавиш. Например, 5-символьный пароль, созданный из символов с большим ASCII-кодом потребует 25 нажатий клавиш. Учитывая 255 возможных кодов для каждого символа и всего пять символов, получаем общее количество комбинаций 255^5 (или 1,078,203,909,375). Однако, 25-символьный пароль, созданный только из букв нижнего регистра имеет 26^25 (или 236,773,830,007,968,000,000,000,000,000,000,000) возможных комбинаций. Очевидно, лучше создавать более длинные пароли. Другой момент, о котором стоит подумать - клавиатуры некоторых портативных компьютеров затрудняют ввод с цифровой клавиатуры и некоторые утилиты командной строки не поддерживают символы с большим ASCII-кодом. Например, вы можете использовать символ ALT+0127 в Windows, но не сможете набрать его в командной строке. И наоборот, коды некоторых символов, таких как Tabs (ALT+0009), LineFeeds (ALT+0010), и ESC (ALT+0027) могут быть использованы при наборе из командной строки, но не могут быть использованы в диалоговых окнах Windows (что может оказаться желательным побочным эффектом в некоторых редких случаях). Тем не менее, есть несколько случаев, когда полезно использование расширенных символьных кодов. Если у вас есть эккаунты сервиса или локального администратора, которые редко используются, иногда использование расширенных символов заслуживает несколько лишних нажатий клавиш. Поскольку мало взламывателей паролей настроены на обработку расширенных символов, этого может быть вполне достаточно, чтобы сделать пароль крайне сложным для взлома. Но в этом случае не останавливайтесь на большом ASCII-коде: существует малоизвестный факт, состоящий в том, что в действительности вы можете воспользоваться полным набором Unicode символов, который составляет 65,535 возможных символов. Тем не менее, такой символ, как ALT+65206 не столь устойчив, как эквивалентное количество нажатие клавиш с использованием обычных символов. И, наконец, обратим внимание на использование неразрывного пробела (ALT+0160) в наборе расширенных символов. Этот символ отображается как обычный пробел и зачастую может обмануть тех, кто каким-то образом увидел ваш пароль. К примеру, скажем, что взломщик смог установить логгер клавиатуры в вашу систему. Если вы используете неразрывный пробел в пароле, в лог-файле он будет выглядеть, как обычный пробел. И если взломщик не знает о неразрывном пробеле и не увидит действительный ASCII-код, то его пароль, на который он так надеялся, не даст ему ничего. А ведь многие люди просто не знают о существовании этого символа, хотя, похоже, после прочтения этой статьи уже будут знать. Заключение Кто-то может не согласиться с некоторыми представленными моментами, но они и не претендуют на роль конечной неоспоримой истины. Не в этом была цель написания этой статьи. Миф – это наполовину правда. Многие мифы, которые здесь критикуются, когда-то были прекрасными советами, или даже все еще являются таковыми в специфических случаях. Но для многих эти советы стали набором жестких, непреложных правил, которые необходимо применять всегда. Но любые советы про пароли, включая и приводимые в этой статье – не более, чем просто советы. Вы сами должны решить, какие правила вам подходят, а какие нет. Пожалуй, наибольший и самый ошибочный миф из всех и состоит в том, что существуют единые жесткие правила в отношении паролей. Иногда John99 – это хороший пароль, а иногда пароли приходится менять гораздо чаще, чем один раз в месяц. Некоторые пароли, к примеру, администраторские, нуждаются в гораздо большей защите, чем другие - пользовательские. Чтобы создать политику паролей, которая защитит вас наилучшим образом, следует взять все свои знания и добавить к ним то, что вы нашли полезным из здесь написанного. Хороший пароль – это больше, чем просто сложный пароль. Хороший пароль – это тот, который крайне трудно угадать или подобрать, но очень легко запомнить. Он должен быть длинным и состоять из букв, цифр и символов, но в то же время должен легко и безошибочно набираться. Он должен содержать случайные элементы, которые может предоставить только компьютер, и в тоже время оставаться родственным тому, что может создать человек. Но наилучший из всех паролей – тот, который пользователь выбирает, основываясь на научном понимании системы создания паролей. И наилучшая политика паролей – та, что помогает пользователям в создании таких паролей.
__________________
Я смотрю на мир голубыми глазами через розовые очки и мне - все фиолетово... |
|||||||||||||
![]() |
![]() |
![]() |
|
|
![]() |
||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Альтернативы блокноту Windows | Каркуша | Редакторы | 0 | 23.12.2009 23:31 |
Windows Vista SP2 X86.Project (RED) v.2.1 | Chief | Windows Vista | 0 | 26.09.2009 12:48 |
Fix for Windows 7 v3.9 | Chief | Windows 7 | 0 | 12.09.2009 12:27 |
Windows 7 Manager | Guard | Windows 7 | 0 | 07.09.2009 13:38 |
Активация Windows All | Chief | Все для OS Windows | 0 | 05.09.2009 23:29 |