Механизмы управления паролями в IE и Firefox.
Статья в двух частях.

Часть первая

1. Введение
В данной статье мы попытаемся проанализировать механизмы безопасности, риски, атаки и методы защиты двух самых распространенных систем управления паролями для Web браузеров Internet Explorer и Firefox. В данной статье рассматриваются браузеры IE6 и 7 и Firefox 1.5 и 2.0. Внимание будет уделено следующим областям:
Механизмы хранения паролей: Средства безопасного хранения имен пользователей и паролей на локальной файловой системе с помощью шифрования данных (часть первая).
Атаки на менеджеры паролей: Методы компрометации или обхода средств защиты (частично первая часть, продолжение во второй части).
Некорректное восприятие безопасности: Использование менеджеров паролей пользователями без учета факторов риска (вторая часть)
Удобство использования: Функционал, расширяющий или уменьшающий использование функционала безопасности (вторая часть)
Контрмеры: Действия, направленные на уменьшения риска для пользователей и корпораций.

Internet Explorer и Firefox вместе занимают 95% рынка браузеров. AutoComplete и Password manager являются средствами хранения имен пользователей, паролей, ссылок в браузерах Internet Explorer и Firefox соответственно.
У каждого браузера есть функционал, который помогает пользователю запоминать различные имена и пароли для аутентификации на Web сайтах. Например, при посещении сайта http://www.gmail.com оба браузера спросят, не желает ли пользователь сохранить логин и пароль. При следующем посещении сайта данные будут заполнены в форму автоматически.

2. Причина использования менеджеров паролей.
Необходимость использования менеджеров паролей связана непосредственно со сложностью запоминания многочисленных логинов и паролей для различных Web сайтов. Естественно, менеджеры паролей могут увеличить уровень безопасности, поскольку они позволяют использовать большое количество различных идентификаторов и паролей. Таким образом пользователь может сгенерировать много имен пользователей и, таким образом, усложнить процесс угадывания для атакующего.
Ключевым моментом здесь является то, что пользователь должен доверять приложению выполнение его роли (безопасное хранение, обработка и перенаправление данных авторизованному узлу). Менеджеры паролей не являются панацеей, хотя они усиливают безопасность и повышают планку для атакующего путем использования интерфейса пользователя для обработки окружений, требующих аутентификацию.
Пользователи и компании должны быть уверены в том, что системы управления паролями корректно внедрены и корректно используются с учетом возможных факторов риска.
Использование одинаковых логинов и паролей на различных Web сайтах увеличивает вероятность компрометации, поскольку атакующему будет необходимо узнать только имя пользователя и пароль для получения доступа ко всем ресурсам пользователя.

3. Механизмы хранения паролей
Ниже описаны места и механизмы хранения паролей. Эти данные используются для изучения векторов атак, рассмотренных в 4 секции (первая и вторая части данной статьи).
3.1 Место хранения
3.1.1 Internet Explorer 6 и 7
В Internet Explorer (версии с 4 по 6) AutoComplete хранит данные web форм в следующих ветках реестра:
Зашифрованные имена пользователей и пароли:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\<....>
В Internet Explorer 7 AutoComplete хранит также данные в реестре, но немного в других ключах:
Зашифрованные имена пользователей и пароли:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\<....>
Данные создаются в реестре, только после того, как пользователь сохранит свои данные (логин и пароль) для Web сайта. Акроним SPW является сокращением от SavedPassWords.
3.1.2 Firefox 1.5 и 2.0
В Firefox ссылки, имена пользователей и пароли хранятся в файле signons.txt:
Зашифрованные имена пользователей и пароли в Windows хранятся в:
%userprofile%\Application Data\Mozilla\Firefox Profiles\xxxxxxxx.default\<....>.txt
Где %userprofile% - переменная окружения в Windows,в которой хранится путь к домашней директории пользователя.
Зашифрованные имена пользователей и пароли на Linux системе хранятся в:
~/.mozilla/firefox/xxxxxxxx.default/<....>.txt
Где xxxxxxxx – генерируется случайным образом при установке Firefox. Файл <.....>.txt создается первый раз при сохранении данных для Web сайта. Последующие логины и пароли для различных сайтов добавляются в этот файл. Для менеджера паролей не имеет значения, доступен сайт по HTTP или HTTPS. Ссылки не шифруются, поскольку они используются как ключи для поиска данных. Когда менеджеру паролей браузера необходимо автоматически заполнить web форму данными для определенного сайта, менеджер ищет соответствующий URL в файле <.....>.txt, если URL найден, происходит автоматическое заполнение данных.
3.2 Хранилище и механизмы доступа
3.2.1 Internet Explorer 6 и 7
Структура хранилища: Реестр
Формат данных: Двоичный, хранится в виде пары шестнадцатеричных значений в типе данных REG_BINARY
Шифрование: TripleDES
Доступ: Protected Storage API (для IE 4-6); Data Protection API (для IE 7)
Требования к доступу: Авторизованный пользователь
Временное хранилище: Симметричные ключи, обнуляемые в памяти после использования.
Internet Explorer версии 4-6 используют Protected Storage System Provider (PStore) для хранении и доступа к важной информации пользователя, включая имена пользователя и пароли, введенные в Web формы в IE. PStore, согласно MSDN, является API для безопасного хранения данных. Согласно недавней публикации Microsoft Press:
«… служба Protected Storage, не считается более безопасным методом хранения данных. Одним из существенных Windows приложений, которое все еще используют PStore, является Microsoft Internet Explorer, которые хранит данные Auto-Complete, включая имена и пароли пользователей для авторизации на web сайта».
Данные PStore шифруются с помощью TripleDES и хранятся в двоичном формате. Незашифрованные данные не могут быть доступны непосредственно через реестр. Хотя безопасность данных и доступ к ним логически завязан на данных учетной записи пользователя в Windows. Как только пользователь войдет в систему, любое приложение, запущенное в контексте пользователя, сможет получить доступ к незашифрованным PStore данным, используя корректные функции API. Хотя, различные учетные записи пользователей в Windows не могут заполучить PStore данные друг друга.
PStore используется не только в Microsoft Internet Explorer, он также используется в различных приложениях Microsoft, таких как Outlook и MSN Explorer. Эти приложения также уязвимы. Известно множество Spyware приложений, которые использовали легко программируемые API для получения неавторизованного доступа к данным.
Internet Explorer 7 использует Data Protection Application Programming Interface (DPAPI), но все же, данные все еще могут быть доступны через API вызовы внешний приложений. Криптографическая защита AutoComplete в Internet Explorer 7 изображена ниже:
EK - Encryption Key
RK - Record Key
CRC - Cyclical Redundancy Check
Hash - Secure Hash Algorithm (SHA)
Хранение данных:
EK: URL
RK: Hash(EncryptionKey)
C: CRC(Record Key)
V: {data}EK
Хранилище (C, V) индексируется RK в реестре, удаляется EK
Получение данных:
EK: URL
RK: Hash(EK)
Происходит поиск RK в реестре, если обнаруживается сходство с V, содержащем зашифрованные данные
data: {V}EK
URL требуется для получения данных (data), поскольку он используется для создания ключа шифрования (EK).
3.2.1.1 Основы организации доступа в Internet Explorer
AutoComplete работает в IE с той предпосылкой, что учетная запись пользователя в Windows имеет полный логический доступ к базе данных паролей. По этому, если неавторизованный пользователь получает логический доступ к компьютеру, и пользователь вошел под своей учетной записью, или эта учетная запись не защищена паролем, атакующий сможет получить привилегии учетной записи и неправомерно воспользоваться паролями. Логический доступ может быть получен с помощью физического присутствия (сесть за компьютер) или удаленно с помощью клиента удаленного управления компьютером (VNC, Remote Desktop и т.д.)
По этому, если нет ограничений для физического доступа к компьютеру (отдельные комнаты с замками, защищенный паролем скринсейвер) кто угодно может воспользоваться менеджером паролей для получения доступа к защищенному паролем Web сайту. Больше всего разочаровывает, что злоумышленник может заполучить доступ таким образом к почтовому ящику или банковскому счету пользователя.
3.2.2 Firefox 0/7-1.5 и 2.0
Структура хранилища: Текстовый файл (<....>.txt)
Формат данных: ASCII, используя Base64 кодирование (кроме URL и полей)
URL (обычный текст, например www.gmail.com)
Field name (обычный текст, например username, email, userid и т.д..)
Зашифрованное и Base64 кодированное значение вышеописанной информации
Field name (например, password, pass,и т.д..)
Зашифрованное и Base64 кодированное значение вышеописанной информации
...и т.д.... (Может быть много данных для одного URL)
.
(Каждая запись заканчивается точкой)
Шифрование: TripleDES (CBC mode)
Доступ: Network Security Services (NSS) API
Требования к доступу: Авторизованный пользователь и Master Password (если установлен)
Дополнительные файлы: Сертификаты сохранены как certN.db, база данных частных ключей как keyN.db и Security Modules сохранены как secmod.db. Напомним, что место расположения файлов было описано в секции 3.1.
Firefox использует Network Security Services API для проведения криптографических операций. Поскольку это относится к менеджеру паролей, Firefox использует Public Key Cryptography Standard (PKCS) #11, который определяет API для аппаратных и программных модулей сторонних производителей. Также используется PKCS#5 для шифрования паролей. У Firefox также есть опция для использования альтернативного модуля для хранения паролей, совместимого со стандартом Federal Information Processing Standard (FIPS) 140-1. Master Password используется совместно с salt (находится в файле keyN.db) для получения Master Key. Затем Master Key используется для дешифрования имен пользователей, паролей, сохраненных в менеджере паролей.
NSS API имеет несколько функций, которые позволяют Firefox или подобным приложениям получить доступ к базе данных паролей. Установка пароля обрабатывается (PK11_SetPasswordFunc), декодируя Base64 данные (NSSBase64_DecodeBuffer) и дешифруя (PK11SDR_Decrypt), что позволяет соответствующим приложениям получить доступ к именам пользователей и соответствующим паролям. Безопасность всей системы зависит от криптографической стойкости Master Password (созданного пользователем) и доступности файла key3.db (который содержит salt), хранимого в пользовательском профиле.
Модуль безопасности FIPS 140-1 может быть включен следующим образом:
Firefox 1.5 на Windows:
Tools -> Options -> Advanced -> Security Devices -> NSS Internal FIPS PKCS #11
Firefox 2.0 на Windows:
Tools -> Options -> Advanced -> Encryption -> Security Devices -> NSS Internal FIPS PKCS #11

4. Атаки на менеджеры паролей
В этой секции мы рассмотрим несколько атак на менеджеры пролей. В этой части статьи мы обсудим только 2 атаки.
Для нахождения всех возможностей испытаний на проникновение мы воспользуемся обычной техникой представления дерева атаки. Целью дерева атаки, показанного на рис. 1, является полная компрометация базы паролей.

Рис. 1 Дерево атаки на Firefox Password Manager

Доступ к базе данных позволяет атакующему заполучить все ссылки, имена пользователей и пароли, используемые для аутентификации на сайтах. Использование скомпрометированного менеджера паролей может позволить злоумышленнику получить доступ к чему угодно – от email до страховки целевого пользователя, банковских счетов или даже корпоративным внутренним данным. Дополнительная цель (не указанная в дереве) – получить доступ к определенному Web сайту. Часто значительно проще съесть кусок пирога (один логин) чем весь (полная компрометация).
Система управления паролями состоит из приложения и элементов пользователя. Для компрометации базы данных пролей или определенного логина следует атаковать самый слабый элемент в системе. В данном случае слабым звеном является пользователь, не рассматривая криптографические атаки или реализации ПО. Атаки основываются на взаимодействии пользователя и менеджера паролей, или менеджера паролей и Web браузера.
4.1 Независимые JavaScript атаки
В этой секции будут рассмотрены 2 JavaScript атаки: стандартная атаки, и с использованием технологии Ajax.
4.1.1 Стандартная JavaScript атака
Предположение: Атакующий имеет логический доступ к пользовательскому интерфейсу
Результат атаки: Атакующий может зайти на сайт, для которого был ранее сохранен логин и 1) получить доступ, 2) использовать JavaScript для получения имени пользователя и пароля.
Сопутствующее повреждение: Использование расшифрованных паролей для доступа к менеджеру паролей или любого другого приложения или Web сайта, использующего идентичный пароль.
С помощью JavaScript и DOM можно получить доступ к сохраненному паролю. Когда пользователь посещает сайт, для которого сохранены личные данные, пароль обычно скрыт за звездочками (*).
Атакующий может либо использовать JavaScript, встроенный в HTML страницу, либо выполнить сценарий после загрузки страницы, что позволит злоумышленнику получить имя пользователя и пароль.

Рис. 2 JavaScript Document Object Model (переходящая в объект пароль)

JavaScript легко доступен online. Он может быть вставлен в HTML, или запущен как букмарклет. Букмарклет – маленькая JavaScript программа, которая может быть сохранена как URL и запущена локально на Web странице после ее загрузки.
Используя программную логику, атакующий проходит по всем парольным элементам (как показано на рис. 2) модели DOM и получает доступ к значениям соответствующих элементов. Любой человек или приложение, использующее Web клиент (IE или Firefox), может нажать на ссылку и скомпрометировать пароль.
4.1.2 Сбор паролей Ajax
Предположение: Атакующий имеет доступ к Web прокси, который является прозрачным, или сконфигурирован для Web клиента.
Результат атаки: Атакующий способен вставить, удалить или изменить содержимое Web страницы, включая JavaScript, что позволяет собирать имена пользователей и пароли с любого сайта, использующего HTTP соединение.
Сопутствующее повреждение: Потенциально один и тот же логин и пароль может использоваться для доступа к компьютеру и/или других приложений и Web сайтов.
В сценарии, изображенном на Рис.4, пользователь открывает Web браузер и желает получить доступ к банковским данным на удаленном сервере. Пользователь запрашивает главную страницу своего провайдера (например, American Express). Сервер компании отвечает, но данные в ответе модифицируются при прохождении через прокси сервер. Прокси сервера обычно используются для сокрытия IP адреса пользователя, фильтрации содержимого и т.д.; они устанавливаются между клиентом и сервером и, как правило, с четкой целью.

Рис. 3 Сбор паролей Ajax

Если атакующий контролирует прокси, он может внедрять JavaScript, который отсылает имя пользователя и пароль через асинхронный запрос серверу (XMLHttpRequest). Имя пользователя и пароль могут быть получены с помощью сценария, упомянутого выше (менеджер паролей автоматически заполняет поля формы), или с помощью таймингового механизма, который ожидает определенный период времени (например 5 секунд), позволяя пользователю ввести данные, и затем запускается код JavaScript, который отсылает данные атакующему. Иллюстрация на Рис. 4 показывает, как браузер получает XML файл, содержащий данные для входа (bobpassword). Сервер проигнорирует запрос, поскольку он некорректен, но атакующий уже получил необходимые для него данные.
Важно дифференцировать процесс, который аутентифицирует пользователя на сервере и отдает злонамеренный код, который только отправляет имя пользователя и пароль атакующему. На некоторых сайтах имя пользователя и пароль вводятся до создания SSL подключения. Ключевым в этой атаку является то, что если SSL соединение было установлено до ввода личных данных, прокси сервер не может просмотреть зашифрованный трафик. Тем не менее, некоторые известные сайты, использующие SSL шифрование (Yahoo, AMEX и другие) создают SSL подключение только после загрузки страницы для ввода личных данных. Они уязвимы для этого типа атаки. Варианты этой атаки будут развиваться и скоро возникнет несколько векторов атаки.
Давайте сравним различный функционал безопасности менеджеров паролей в двух самых популярных браузерах:

Функционал	Internet Explorer 7	Firefox 2.0
Хранилище имен пользователей, паролей и ссылок	Да	Да
Доступ к паролю с помощью JavaScript	Да	Да
Доступ к паролю с помощью другого ПО	Да	Да
Защита паролем (не привязанным к учетной записи системного пользователя)		Да
Запрос пароля перед началом сессии для использования сохраненных паролей для сайтов		Да
Легко экспортируемые имена пользователей и пароли		Да
Шифрование данных	Да	Да
Кодирование данных		Да
Опция менеджера паролей для отображения пароля в открытом виде		Да

Возникает спорный вопрос о том, является ли возможность просмотра паролей в открытом виде функционалом браузера или его уязвимостью, хотя иногда этот метод единственно возможный для восстановлений забытого пароля к Web сайту.

Заключение к первой части
В первой части этой статьи была сделана попытка описать механизмы хранения паролей в Internet Explorer и Firefox, и, затем, были продемонстрированы две JavaScript атаки на браузеры.

Часть вторая

4.2. Уязвимость в реализации менеджера паролей Firefox 2.0. (реверсивный межсайтовый скриптинг).
В версии менеджера паролей Firefox 2.0 от ноября 2006 года содержится уязвимость, которая позволяет, при нажатии специально сформированной ссылки, передать личные данные пользователя текущего сайта на произвольный URL. Уязвимость, далее RCSR (Reverse Cross Site Request), состоит в том, что браузер не контролирует URL, на который отправляются личные данные пользователя через Web формы. Для успешного проведения атаки пользователю необходимо ранее посетить сайт и сохранить свои личные данные в менеджере паролей. Эта тактика кражи информации была осуществлена на MySpace.com и обнаружена CIS. Наиболее уязвимы сайты общественной сети, которые позволяют пользователям размещать личные данные в чистом HTML формате.
RCSR мощнее чем атака описанная в пункте 4.1 (части I данной статьи), поскольку XMLHttpRequest не пропускает запросы за пределы текущего домена. К тому же ссылка (действие, позволяющее отправку данных формы) может появиться в форме вложенного видео, вебкаста или возможно игры, что делает ее более скрытой.
4.3 Раскрытие паролей в Internet Explorer.
4.3.1. Восстановление паролей.
Многие компании владеют коммерческими программами, позволяющими восстанавливать пароли из AutoComplete в IE.
ElcomSoft производит программу Advanced Internet Explorer Password Recovery (AIEPR). Как указано на их сайте она может восстановить любую информацию в AutoCpmplete любой версии IE от 3 до 6 при условии, что пользователь находится в системе. Свободно распространяемые приложения, такие как PassView для версии 7 IE, также доступны.
(Здесь стоит отметить, что большинство программ такого рода добавлены в базы антивирусов и антишпионов, и детектируются как Spyware или Riskware. Проверьте, Вы установили в своем антивирусе галочку в пункте "на отлов недовирусов").
4.3.2. Злонамеренное ПО.
Internet Explorer обычно является основной целью для установки злонамеренных программ, действия которых направлены против AutoComplete. Эти программы получают конфиденциальную информацию и затем отсылают ее атакующему. BackDoor-AXJ является троянской программой, которая сохраняет информацию AutoCoplete и других программ на машине подверженной атаке, и затем отсылает ее обратно злоумышленнику. Srv.SSA-KeyLogger является таким бекдором, который скрыто устанавливается в Internet Explorer и действует как килоггер. Он, такжe, обращается к AutoComplete ворует данные из защищенного хранилища и отсылает их методом HTTP GET.
4.4 Раскрытие паролей в Firefox
4.4.1. Легко доступные пароли в открытом виде.
Для пользователей, которые незнакомы с менеджером паролей Firefox, любой пользователь, находящийся в системе через физический доступ к компьютеру может просмотреть текстовые пароли следующим образом:
На Windows XP:
Firefox 1.5
Tools/ Options/ Privacy/ Passwords/ View Saved Passwords/ View Passwords/ Show Passwords
Firefox 2.0.
Tools/ Options/ Security/ Show Passwords/ Show Passwords
4.4.2. Атаки на основной пароль
В недавнем времени были разработаны инструменты для проведения атак на пароли в основной пароль в Firefox. В данное время выполнимы следующие атаки: Атаки грубой силы, Атаки по словарю и Гибридные атаки.
Были разработаны инструменты, написанные на С с возможность написания сценариев. В результате разработки этих инструментов конфиденциальность базы паролей стала полностью зависимой от способности мастера паролей противостоять атакам. Излишним будет сказать, что плохо выбранный пароль (слова, состоящие из строчных букв) может быть взломан в микросекунды. Более того, отсутствие пароля мгновенно раскроет базу паролей. Это равно открытию в Firefox меню Options/ Show Passwords.
4.4.3. Множественные записи имен пользователей/ паролей для URL.
В Firefox есть интересная функция, разрешающая внесение множественных аутентификационных записей для одного и того же Web сайта. Например, два выдуманных персонажа Боб и Эллис используют тот же менеджер паролей в Firefox под одной и той же учетной записью вWindows XP, но имеют разные банковские счета на одном и том же Web сайте (www.pnbank.com). Менеджер паролей разрешит использование множественных пар имен пользователей и паролей. Менеджер паролей сможет различить когда использовать каждый счет основываясь на имени пользователя и автоматически заполнит поле для пароля. Эта функция дает возможность просмотреть личные данные другого человека, например следующие:
URL
bob
k9*763s
alice
n63ld23f
По правилам безопасности два человека не должны использовать одну и ту же учетную запись на одном компьютере; однако этот сценарий все же является риском для безопасности, поскольку не все компании следуют лучшим путем. К тому же существует схожий риск, если пара имен пользователей/ паролей случайно вводятся некорректно на определенном сайте (например, ошибочное введение двух логинов для разных банковских сайтов). Эта информация будет сохранена (даже если она не используется), и может быть скомпрометирована через некоторое время в будущем, при этом владелец информации не будет об этом знать.
4.4.4 Атаки на отказ в обслуживании.
Любой пользователь или программа с правом доступа к локальному профилю пользователя на файловой системе может потенциально атаковать целостность и доступность менеджера паролей. Если удалить или модифицировать необходимые файлы (keyN. db, certN.db, secmod.db, signons.db иsignons.txt) в результате нельзя будет восстановить никакие имена пользователей или пароли. Наиболее важные из этих файлов - keyN.db и signons.txt, в которых хранятся частные ключи и зашифрованные данные соответственно.
Таким образом, если эти файлы удалены или модифицированы и менеджер паролей более не доступен, все же будет возможно восстановить базу данных паролей, скопировав файлы обратно в директорию профиля Firefox.

5. Ложное чувство безопасности.
Когда пользователи наивно используют системы менеджеров паролей в Web браузерах они недостаточно проинформированы, и ни полностью осознают связанные с этим риски. Опасность этого состоит в неосторожности, с которой сохраняются имена пользователей и пароли для доступа к обыкновенным новостным сайтам или же чему-то более важному, как финансовая информация на online бирже. Пользователи ожидают, что браузер, возможно, совместно с операционной системой, защитит их данные. В реальности же опасность полной компрометации будет реализована проще, чем ожидают того пользователи. Web браузеры, как приложения, особенно опасны, поскольку установлены на большинстве компьютерных систем, которыми пользуются все, и хранят все имена пользователей и пароли, которые вводит пользователь. Все эти факторы делают Web браузеры соблазнительной целью для злоумышленников.

6. Удобство использования.
Возможности по удобству использования менеджера паролей в Internet Explorer и Firefox приведены ниже в таблице 2. Некоторые ключевые различия включают возможность просмотра паролей в открытом виде в Firefox но не в Internet Explorer.Это можно рассматривать и как риск и как дополнительный функционал, зависимо от стойкости основного пароля. К тому же Firefox имеет очень полезную функцию, которая позволяет выборочно исключать имена пользователей и пароли для некоторых сайтов (речь идет об особо важных личных данных для некоторых сайтов, которые нельзя подвергать риску разглашения). В AutoComplete такой выбор можно сделать лишь единожды и его можно изменить лишь путем редактирования реестра. Однако AutoComplete имеет преимущество перед менеджером паролей Firefox, поскольку пользователь может выбрать или сохранить URL, имя пользователя или пароль и не обязан сохранять все три значения, как в Firefox.

Функционал	Internet Explorer7	Firefox 2.0
Подсказка для сохранения паролей	Да	Да
Способность легко менять опцию “saved” на “not saved”для Web сайта		Да
Способность НЕ сохранять любую информацию в формах	Да	Да
Возможность быстрого доступа к текстовым паролям		Да
Возможность выбора сохранять URL, имена пользователей, или пароли	Да

7. Стратегии защиты.
7.1.1 Отказ от использования
Один из методов предотвращения компрометации пароля – отказ от использования менеджера паролей в IE или Firefox. Однако этот метод может способствовать использованию одного и того же пароля для нескольких сайтов, что, в итоге, понижает уровень безопасности. Таким образом отказ от использования менеджеров паролей должен сопровождаться возможными альтернативными методами. Также существует возможность случайного сохранения пароля при обычном просмотре Web страницы в Интернет.
7.1.2 Отключение менеджера паролей
Этот метод запрещает возможность сохранения имен пользователей и паролей и может рассматриваться как отказ от использования. Эта стратегия отлична от подхода, который будет подробно описан в пункте 7.2.
7.1.3. Альтернативные “проверенные” менеджеры паролей.
Один из обычных способов хранения паролей пользователей в централизованном приложении, называемом Password Safe.
Созданная Брюсом Шнайером (Bruce Schneier), open-source утилита для windows теперь является популярным методом сохранения и доступа паролей. Пароли кодируются алгоритмом Schneier's Blowfish и защищаются с помощью Safe Combination.(основной пароль).
Любое новое приложение должно использоваться с сомнением и осторожностью. Однако, программа, единственной целью которой является сохранение важной информации, имеет более узкий фокус чем любой Web браузер с функцией хранения паролей. Узкий фокус этого менеджера паролей и факт его создания известным криптографом являются причинами для его оценочного использования в будущем. Сравнительным недостатком является удобство и простота использования и в AutoComplete и в Password Manager; поскольку у пользователя нет нужды переключаться между приложениями чтобы получить доступ к именам пользователей и паролям.
7.1.4 Сложность пароля.
Как было упомянуто в предыдущих пунктах, стойкость основного пароля может предотвратить некоторые атаки.
Как было указано ранее, Internet Explorer не позволяет вам выбирать основной пароль для AutoComplete; безопасность информации сохраненной в AutoComplete непосредственно связана с паролем к учетной записи пользователя в Windows. Выбор более сильного пароля к Windows обеспечит минимальной дополнительной защитой. Однако для тех, кто использует программу RainbowCrack, пароли под Windows будут открыты в считанные минуты. Создание более сложного пароля в менеджере паролей для Firefox может существенно уменьшить риск компрометации. Хороший пароль имеющий длину более восьми, с выборочными символами и хорошая смесь алфавитно- циферных символов может существенно увеличить защиту. Атаки по взлому паролей возможны на менеджер паролей в Firefox, но пользователи, работающие с большей осторожностью, могут избежать возможности стать их жертвами. В любом случае, пользователи Firefox получают дополнительную защиту, используя пароль, в сравнении с их коллегами в Windows.
7.2 Посредничество веб разработчика.
В рамках веб разработки коммерческие сайты и финансовые учреждения могут предоставить своим пользователям некоторые меры для безопасности паролей. Как Internet Explorer так и Firefox имеют возможность предотвратить сохранение пароля если атрибуты тега <INPUT> в HTML настроены соответственным образом. Пример, приведенный ниже, взят с сайта MSDN и показывает, насколько легко ввести это изменение на любой другой Web сайт. Используя этот метод, учреждения, желающие избежать риска могут предотвратить сохранение паролей пользователями как в IE так и в Firefox.
Это текстовое значение будет сохранено:

			<INPUT TYPE="text"  NAME="password" AUTOCOMPLETE="ON">

Это текстовое значение не будет сохранено:

			<INPUT TYPE="text"  NAME="password" AUTOCOMPLETE="OFF">

Если каждый вебсайт будет действовать следующим образом в результате любая польза от использования менеджеров паролей в браузерах будет утеряна.Таким образом, этот метод каждой организации следует изучить индивидуально, дабы определить (является ли он подходящим решением) его пригодность. Использование этого метода не гарантирует безопасность клиента, как было отмечено в пункте 4.1. HTML и JavaScript можно модифицировать на уровне клиента, переключив “OFF” на “ON”.
7.3. Посредничество Windows в корпоративной политике безопасности.
В целях безопасности корпорации, возможно отключить функцию AutoComplete в Internet Explorer. Используя объекты групповой политики можно легко управлять большим количеством компьютерных систем, контролируя пользователей и настройки компьютера с помощью единой политики. Возможно отключить AutoComplete для целой организации или корпорации используя Windows 2003 в среде Active Directory.

8. Заключение.
Риск проникновения и компрометации механизмов хранения паролей таких Web браузеров как Internet Explorer и Firefox требуют дальнейшего изучения. Любая система контролирующая ключи к царству или же многим царствам должна далее тщательно рассматриваться. Пользователям нужно осознавать риски и пользу от использования систем управления паролями. Существующие методы противодействия, такие как отказ от использования, отключение, альтернативное хранилище и сложность пароля являются лишь временными решениями. Пользователи ожидают, что политика безопасность будет прозрачной, удобной в использовании и безопасной. Следующее поколение систем управления паролями должно учесть все эти аспекты в своих решениях.

Подведем итоги этого обширного обзора еще раз и в кратце. После получения этой информации голова идет кругом - определенно есть над чем задуматься, после выхода IE7 большинство специалистов по IT-безопасности сошлись во мнении, что новый браузер защищен довольно надежно, да, были недочеты и эти недочеты существенны, но фактор появления новой технологии уже сам по себе несет новые подходы к обеспечению безопасности. Но... Что можно посоветовать рядовому пользователю на "каждый день"? 1) Отключить запоминание паролей; 2) Пользователям Proxy стоит задуматься о своей безопасности, как мы увидили, Proxy тоже имеют немоло таких минусов, о которых большинство и не догадывается; 3) Использовать специализированные программы для хранения паролей. Если таковых нет, то можно просто создать архив и поместить в него txt-файл с паролями, опять-таки защитив паролем (но один пароль запомнить все-же легче!). Да и сами пароли генерировать специальными программами.