<?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/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>
		<item>
		<title>Токены</title>
		<link>http://www.microfinance.uz/tokeny/</link>
		<comments>http://www.microfinance.uz/tokeny/#comments</comments>
		<pubDate>Mon, 06 Oct 2008 06:33:10 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Токены]]></category>

		<guid isPermaLink="false">http://www.microfinance.uz/tokeny/</guid>
		<description><![CDATA[Токен (англ. token) — это устройство, хранящее некий уникальный параметр, на основе которого выдается корректный ответ на запрос системы об аутентификации. Различают следующие варианты использования токена. □ На запрос системы токен предъявляет ей хранимое секретное значение. Это не самый надежный случай, так как, перехватив это значение один раз, злоумышленник может имитировать ответ токена. □ Токен [...]]]></description>
			<content:encoded><![CDATA[<p>Токен (англ. token) — это устройство, хранящее некий уникальный параметр, на основе которого выдается корректный ответ на запрос системы об аутентификации.<br />
Различают следующие варианты использования токена.<br />
□ На запрос системы токен предъявляет ей хранимое секретное значение. Это не самый надежный случай, так как, перехватив это значение один раз, злоумышленник может имитировать ответ токена.<span id="more-67"></span><br />
□ Токен и система имеют общую, синхронизированную систему генерации одноразовых паролей. На запрос системы токен выдает пароль, действительный для данного промежутка времени. Синхронизированная система генерирует в это время свой вариант пароля, который и сравнивает с полученным.<br />
□ Токен зарегистрирован в системе, и система знает его секретное значение (либо открытый ключ для варианта асимметричной криптографии — более подробно об этом рассказывается в главе 18). Получив в запросе некую случайную величину, сгенерированную системой для данного сеанса аутентификации, токен преобразует ее, используя свой секретный параметр. Таким образом, с одной стороны, информация, предоставляемая для аутентификации (как запрос, так и ответ), каждый раз различна и ее перехват ничего не дает злоумышленнику. С другой стороны, система, зная случайное значение и секретный параметр токена, генерирует свой вариант ожидаемого ответа токена и на основе этого сравнения принимает решение об авторизации. По сравнению с предыдущим методом данный алгоритм стоек к рассинхронизации системы и токена. При случайных или умышленных попытках некорректной авторизации либо даже простейшем сбое питания в методе с синхронной системой счетчики одноразовых паролей могут рассинхронизироваться. Это потребует вмешательства в работу системы специалистов с дополнительными полномочиями.<br />
Варианты применения токена совместно с паролем или ПИНом пользователя следующие:<br />
□ ПИН служит паролем доступа к самому токену: без введения ПИН токен не действует;<br />
□ токен генерирует аутентификационный ответ на основе своего секретного параметра и ПИН пользователя, т. е. корректность и секретного параметра и ПИНа анализируются системой.<br />
□ ПИН пользователя совместно с параметром токена и случайной величиной системы, или с синхронизированным параметром служат основой для выработки одноразового пароля, который затем сообщается пользователю. Пользователь далее работает с этим паролем, как с обычным, но только в ограниченный промежуток времени.<br />
Надежность подобных систем зависит от реализации работы токена и системы. Например, если между системой и устройством считывания данных,<br />
подготовленных токеном, может размещаться средство перехвата информации, и при этом срок жизни пароля из ответа токена достаточно долгий, то, естественно, он может быть использован злоумышленником.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.microfinance.uz/tokeny/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Биометрические средства аутентификации</title>
		<link>http://www.microfinance.uz/biometricheskie-sredstva-autentifikacii/</link>
		<comments>http://www.microfinance.uz/biometricheskie-sredstva-autentifikacii/#comments</comments>
		<pubDate>Mon, 06 Oct 2008 06:32:23 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Биометрические средства аутентификации]]></category>

		<guid isPermaLink="false">http://www.microfinance.uz/biometricheskie-sredstva-autentifikacii/</guid>
		<description><![CDATA[Говоря об этом классе средств, необходимо учитывать их точность работы и анализировать в комплексе со следующими характеристиками. □ Уровень ошибочного отказа — процент случаев, когда корректный предъявленный аутентификатор отвергнут из-за особенностей процесса обработки. □ Уровень ошибочного подтверждения — процент случаев, когда некорректно предъявленный аутентификатор принят из-за особенностей процесса обработки. □ Скорость обработки аутентификатора — анализ [...]]]></description>
			<content:encoded><![CDATA[<p>Говоря об этом классе средств, необходимо учитывать их точность работы и анализировать в комплексе со следующими характеристиками.<br />
□ Уровень ошибочного отказа — процент случаев, когда корректный предъявленный аутентификатор отвергнут из-за особенностей процесса обработки.<br />
□ Уровень ошибочного подтверждения — процент случаев, когда некорректно предъявленный аутентификатор принят из-за особенностей процесса обработки.<br />
□ Скорость обработки аутентификатора — анализ считанного изображения может занять долгое время на низкоскоростной технике.<span id="more-66"></span><br />
□ Устойчивость к подмене. Из видеофильмов (надеемся, никому из читателей не пришлось столкнуться с этим на практике) известны случаи с отрезанием пальцев и других частей тела авторизованных пользователей злоумышленниками для предъявления их аутентифицирующим устройствам. Кроме того, для отпечатка пальца, например, может быть создана резиновая копия.<br />
□ Требования к хранению данных — хранение аутентификационных данных в виде многопараметрического вектора или подробного изображения может потребовать значительных ресурсов.<br />
□ Прочие условия. Использование многими пользователями одного устройства с прикосновением к нему может быть неприемлемо для людей с иными культурными традициями или с физиологическими/психическими отклонениями.<br />
Наиболее известными методами биометрической аутентификации являются: отпечаток пальца или ладони, геометрия ладони (длина, ширина, вес), параметры голоса, анализ сетчатки или радужной оболочки глаза, динамика подписи, геометрия и рисунок теплового излучения лица.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.microfinance.uz/biometricheskie-sredstva-autentifikacii/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Атаки на средства аутентификации</title>
		<link>http://www.microfinance.uz/ataki-na-sredstva-autentifikacii/</link>
		<comments>http://www.microfinance.uz/ataki-na-sredstva-autentifikacii/#comments</comments>
		<pubDate>Mon, 06 Oct 2008 06:31:59 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Атаки на средства аутентификации]]></category>

		<guid isPermaLink="false">http://www.microfinance.uz/ataki-na-sredstva-autentifikacii/</guid>
		<description><![CDATA[Управление передано операционной системе. Своевременным требованием к возможности продолжения пользователем работы является его идентификация и аутентификация (то есть сотрудник должен представиться системе и подтвердить, что действительно тот, кем представился). Обычно не бывает идентификации без аутентификации, поэтому далее будем говорить только о последней процедуре. Ряд вариантов аутентификации может быть отнесен на более ранний этап загрузки компьютера, [...]]]></description>
			<content:encoded><![CDATA[<p>Управление передано операционной системе. Своевременным требованием к возможности продолжения пользователем работы является его идентификация и аутентификация (то есть сотрудник должен представиться системе и подтвердить, что действительно тот, кем представился). Обычно не бывает идентификации без аутентификации, поэтому далее будем говорить только о последней процедуре. Ряд вариантов аутентификации может быть отнесен на более ранний этап загрузки компьютера, до активации операционной системы. В разделе они приведены для единообразия классификации.<span id="more-65"></span><br />
Обычно аутентификация основывается на одном из следующих параметров или их комбинации:<br />
□ что-то, что пользователь знает (пароль);<br />
□ что-то, что пользователь имеет (токен);<br />
□ что-то, чем пользователь является (биометрические параметры).<br />
Самым распространенным является в настоящее время первый вариант, достаточно надежным считается комбинация первого со вторым (предъявление токена и ввод пароля), возможно, с развитием технологий в конечном итоге использоваться будет третий, как наиболее удобный для пользователя.<br />
Рассмотрим их от более сложного и менее распространенного к более простому и чаще используемому.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.microfinance.uz/ataki-na-sredstva-autentifikacii/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

