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

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

FormsAuthentication.SetAuthCookie(uniqueUsername, false);

Сопряжен с некоторым кодом в файле 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() имя пользователя хранится на клиентской машине. Возможно ли, если кто-то сломает используемое шифрование и заменит имя пользователя, которое будет сохранено для другого?

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

Ответ 1

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

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

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

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

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

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

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

Более подробные подробные сведения о системе проверки подлинности форм и способах сохранения билета, способы настройки различных параметров конфигурации <forms> и т.д. см.: Конфигурация аутентификации форм и расширенные темы.

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

Прервать шифрование SSL
Украсть файл cookie из памяти клиентской машины.

Далее следует разрыв шифрования в файле cookie.

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

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