FormsAuthentication: это безопасно?

Question

Использование FormsAuthentication встраивание в asp.net Очень быстро и легко создать систему входа в систему, которая создает cookie для аутентифицированных пользователей:

FormsAuthentication.SetAuthCookie(uniqueUsername, false);

Pairedс некоторым кодом в файле Web.Config :

<authentication mode="Forms">
  <forms loginUrl="Login.aspx" timeout="30" defaultUrl="Dashboard.aspx" protection="All" />
</authentication>
<authorization>
  <deny users="?" />
</authorization>

Все запросы будут возвращаться к Login.aspx до тех пор, пока пользователь не будет одобрен и файл cookie не будетсоздан с использованием вызова метода SetAuthCookie ().

Достаточно ли это безопасно?
Основное правило, которое я использую, заключается в том, что я не храню на клиенте никаких данных о том, что они 'мы не отправили меня.Итак, в прошлом я держал имя пользователя и пароль, используемые в cookie, а затем повторно аутентифицировал их при каждом запросе.

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

Мое беспокойство
Меня беспокоит то, что при использовании вызова метода SetAuthCookie () имя пользователя сохраняетсяна клиентской машине.Тогда возможно ли, чтобы кто-то сломал используемое шифрование и заменил имя пользователя, которое хранится, другим?

Я думаю, что я чрезмерно параноидален, и что тип и уровень используемого шифрования является адекватным, но подумалЯ получил бы некоторый экспертный вклад по теме.

Answer 1

Итак, в прошлом я сохранял имя пользователя и пароль, используемые в cookie, а затем повторно аутентифицировал это при каждом запросе.

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

Меня беспокоит то, что при использовании вызова метода SetAuthCookie () имя пользователяхранится на клиентском компьютере.Тогда возможно ли, чтобы кто-то нарушил используемое шифрование и заменил имя пользователя, которое хранится, другим?

Как отметил Шираз, cookie сохраняется на клиентском компьютере, только если вы создаете постоянный cookie.(Один из параметров SetAuthCookie указывает, создавать ли такой файл cookie или нет.

Даже если кто-то нарушил схему шифрования, чтобы изменить файл cookie для предоставления другого имени пользователя, он столкнется с проблемами из-за проверки подлинности.Билет также имеет цифровую подпись, что означает, что ASP.NET может определить, было ли изменено содержимое файла cookie. Чтобы создать цифровую подпись, злоумышленнику необходимо знать, какую соль использует сервер, и если пользователь может понять, что это подразумеваету него есть доступ к файловой системе вашего веб-сервера, так что теперь у вас есть большие проблемы.

Еще одна вещь, которую нужно понять, это то, что у билета аутентификации есть срок действия, который ограничивает срок действия билета.Таким образом, даже если кто-то захочет украсть куки пользователя, время, которое злоумышленнику придется использовать этот украденный билет, будет ограничено на основании значения timeout, которое вы указываете для системы аутентификации форм (по умолчанию 30 минут).

В заключение, официальная форма ASP.NETСистема аутентификации будет намного более безопасной, чем то, что сможет реализовать одинокий разработчик.Разработчики должны стремиться использовать систему проверки подлинности на основе форм, а не использовать свое собственное решение по множеству причин, включая лучшую безопасность, отсутствие необходимости изобретать велосипед, применение стандартных методов, чтобы другие разработчики, присоединившиеся к команде, не имели такого большого обучениякривая, чтобы набрать скорость и т. д.

Для получения более подробной информации о системе проверки подлинности форм и о том, как защищен билет, как работают различные настройки конфигурации <forms> и т. д., см .: Настройка проверки подлинности с помощью форм и дополнительные разделы .

Answer 2

Просто несколько случайных утверждений о вашем мыслительном процессе, но в отношении

Так что я сделал в прошлом имя пользователя и пароль, используемые в cookie, затем повторно аутентифицируйте это с каждый запрос.

@ Скотт Митчелл уже говорил об этом и обсуждал причины не делать этого из-за последствий для безопасности.

Я чувствовал, что стоило бы указать, почему это не имеет смысла (даже не принимая во внимание последствия утечки информации для безопасности). Причина, по которой вы генерируете билет для проверки подлинности с помощью форм (cookie), заключается в том, что вы разрешаете ASP.NET отмечать этот браузер пользователей этим билетом, который позволяет вам подтвердить, что это указанный пользователь, который уже прошел проверку подлинности.

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

Хорошей аналогией является то, что вы идете в бар, по пути вы проверяете свой идентификатор вышибалой, чтобы убедиться, что ваш идентификатор является законным, и что вам больше 21 года. После подтверждения вам дают браслет на запястье определенного цвета / дизайна.

С помощью браслета вы можете выйти из здания, чтобы покурить, и вернуться внутрь, обходя линию, и вам понадобится отсканировать ваш идентификатор, чтобы вы могли вернуться в этот день. Теперь, если вы идете домой, но не снимаете браслет, когда ложитесь спать (например, оставляя браузер открытым на ночь), вы возвращаетесь в бар на следующий день и пытаетесь показать браслет, чтобы обойти линию. В этот момент вы отклонены, потому что у вас есть запястье прошлой ночи, и вам говорят, чтобы вы вернулись в конец очереди и снова авторизовались.

Answer 3

Если для свойства DisplayRememberMe установлено значение false, файл cookie не будет сохранен на клиентском компьютере. Затем он будет просто сохранен в памяти.

Если вы используете HTTPS / SSL, он будет защищен на пути к клиентскому компьютеру.

Тогда остаются только теоретические возможности:

• Прервать шифрование SSL
• Украсть куки из памяти клиентского компьютера

С последующим нарушением шифрования в cookie.

Возможно, есть несколько более простых способов атаковать вашу систему.

http://msdn.microsoft.com/en-us/library/ms998310.aspx