<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Информационная безопасность &#187; Пароли</title>
	<atom:link href="http://www.microfinance.uz/category/lokalnye-ataki/ataki-na-sredstva-autentifikacii/paroli/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.microfinance.uz</link>
	<description>Бухгалтерский и налоговый учёт</description>
	<lastBuildDate>Thu, 26 Jan 2012 14:59:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
		<item>
		<title>Пароли</title>
		<link>http://www.microfinance.uz/paroli/</link>
		<comments>http://www.microfinance.uz/paroli/#comments</comments>
		<pubDate>Mon, 06 Oct 2008 06:34:12 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Пароли]]></category>

		<guid isPermaLink="false">http://www.microfinance.uz/paroli/</guid>
		<description><![CDATA[Это наиболее распространенный в данное время способ аутентификации, когда система приглашает пользователя-человека ввести известную только данному пользователю (и системе) последовательность символов. Возможные атаки в данном случае основываются на уязвимости: □ способа доставки пароля от пользователя к системе; □ способа хранения пароля в системе; □ системной политики работы с паролем; □ самого пароля вследствие его некорректного [...]]]></description>
			<content:encoded><![CDATA[<p>Это наиболее распространенный в данное время способ аутентификации, когда система приглашает пользователя-человека ввести известную только данному пользователю (и системе) последовательность символов. Возможные атаки в данном случае основываются на уязвимости:<br />
□ способа доставки пароля от пользователя к системе;<span id="more-68"></span><br />
□ способа хранения пароля в системе;<br />
□ системной политики работы с паролем;<br />
□ самого пароля вследствие его некорректного выбора пользователем.<br />
Способы доставки пароля от пользователя до аутентифицирующей системы определяются протоколами доставки, которые будут рассмотрены в главах 20 и 22. На первый взгляд в разговоре о локальных атаках не имеет смысла говорить о способах доставки пароля до системы, однако на самом деле это зависит от способа аутентификации пользователя в системе. Если аутентификация пользователя происходит на той же системе, с консоли которой он работает, то, действительно, в данном случае рассмотрение способов доставки можно опустить. Если же перед работой на локальной станции пользователь должен быть аутентифицирован на отдельном сервере, то процесс доставки пароля до сервера необходимо также учитывать.<br />
Единственное, что можно добавить к рекомендациям по усилению безопасности способа доставки паролей — это своевременно отслеживать появления обновлений и заплаток. Так, после снятия в начале 2000 года правительством США ограничений на экспорт сильных криптографических средств, стало возможным использовать протокол безопасности SSL с ключом длиной 128 бит вместо 40-битного, который был до этого. Снятие такого ограничения, возможно, означает, что соответствующие органы в США теперь обладают ресурсами, позволяющими взламывать 128-битные ключи в этой криптосистеме, но тем не менее при прочих равных условиях лучше использовать более сильные ключи.<br />
Способы хранения паролей в системе зависят от самой системы и обычно не могут быть изменены, например, усилены с точки зрения безопасности. Тем не менее в ряде случаев, например, для Unix-подобных операционных систем, возможны дополнительные мероприятия по усилению защиты файла паролей (изменение прав доступа, shadowing). Для других систем, например, Windows NT, сам способ хранения паролей не может быть усилен на месте использования (только производителем с помощью соответствующих заплат). Однако необходимо учитывать дополнительные уязвимости, связанные с файлом паролей, такие как возможность его сохранения в альтернативном месте на случай аварийного восстановления. Например, если альтернативное место хранения не обеспечивает необходимого уровня защиты, файл паролей может быть скопирован злоумышленником и далее подвергнут обработке на предмет извлечения паролей пользователей.<br />
В любом случае необходимо ознакомится с документацией системы, посвященной вопросам хранения паролей, а также обязательно изучить накопленный опыт по вопросам несанкционированного извлечения паролей в данной системе.<br />
Уязвимость системной политики паролей зависит от настройки, установленной администратором. Если политика безопасности допускает неограниченное число попыток ввода некорректного пароля без блокировки имени регистрации, если нет задержки между попытками ввода, если возможен пароль размером менее 8—10 символов или вообще пустой пароль, то пароль пользователя не истекает никогда, не поддерживается история паролей — все это несомненные возможности для злоумышленника. Для снижения вероятности реализации такой атаки необходимо установить блокировку счета пользователя (хотя бы временную) после 3—5 ошибок при вводе пароля либо после ввода неверного пароля установить запаздывание 5—7 секунд; запретить вводить пароли маленького размера, установить приемлемое для пользователей время истечения пароля (в среднем 1 месяц), поддерживать историю паролей — т. е. запрещать пользователю использовать свои старые пароли. Продвинутые системы могут производить анализ паролей пользователей при вводе и отбраковывать простые, легко разгадываемые пароли.<br />
Если система ведет регистрационный журнал ввода паролей пользователями, можно использовать дополнительные возможности — расследовать часто повторяющиеся случаи ввода неверного пароля пользователем, блокировать счет, если пользователь не входил в систему более 2 недель — месяца и пр.<br />
Отдельный вопрос, который должен быть рассмотрен в данном разделе, это имитация системного приглашения к вводу пароля со стороны посторонней программы (программной закладки). Идея такой атаки состоит в том, чтобы перехватить запрос пользователя на доступ к системе. В момент начала процесса авторизации запускается альтернативная программа, созданная злоумышленником. В тот момент, когда пользователь думает, что вводит пароль в соответствующее окно запроса системы, информация на самом деле передается в окно программной закладки. После этого альтернативная программа либо выдает сообщение об ошибке пароля и передает управление настоящей системе, либо, если позволяют технические возможности, прозрачно для пользователя эмулирует ввод пароля в адрес настоящей системы. Если в системе не предусмотрены дополнительные защитные механизмы (генерирование прерывания комбинацией клавиш &lt;Ctrl&gt;+&lt;Alt&gt;+&lt;Del&gt; в Windows NT), то защита от таких атак — обучение пользователей, которые должны внимательно следить за поведением системы при вводе пароля. Изменение надписи приглашения к вводу, цвета заставки, отклонение от обычной последовательности действий или реакций — все это должно вызывать подозрение.<br />
Атака на слабость паролей — это уже притча во языцех. Известно, что примитивно выбранный пароль можно разгадать даже без использования технических средств, более сложные — с использованием известных программ-взломщиков паролей.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.microfinance.uz/paroli/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

