MVC3 и аутентификация

Хорошо, я новичок в веб-разработке, поэтому могу неправильно понять некоторые из этих терминов. Заранее прошу прощения.

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

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

  1. FormsAuthentication.SetAuthCookie (). В нем хранится файл cookie сеанса, срок действия которого истекает в браузере, и на клиенте нет ничего важного. Однако он может хранить только одно значение. В этом ответе stackoverflow показан метод хранения здесь нескольких значений, но парень, который дает указание не использовать его, но не объясняет почему.

  2. FormsAuthenticationTicket. Я не знаю, где хранится эта информация, но она позволяет использовать простой метод хранения нескольких значений. Для его защиты, согласно документации, требуется вызов Encrpty () для сохранения и decrypt () для получения. Это кажется расточительным, но что я знаю.

  3. Сессия ["SomeRef"] = новый CustomObject (). Второй ответ в этом вопросе объясняет, как это сделать, но в комментарии к нему это называется опасным, поскольку его можно украсть. Мне это кажется лучшим методом, потому что информация по-прежнему хранится на сервере и может хранить несколько значений.

Я не могу найти никаких сравнений для этих методов или хороших объяснений "передового" способа хранения нескольких фрагментов информации после аутентификации пользователя. Информация - это просто имя пользователя и его userId.


authentication session-cookies asp.net-mvc-3
person Kyeotic    schedule 22.06.2011    source источник
comment
Кстати, вам не нужно хранить идентификатор пользователя, если имя пользователя уникально. Просто добавьте уникальный индекс в этот столбец базы данных, и поиск будет происходить так же быстро, как если бы вы использовали идентификатор.   -  person BC.    schedule 22.06.2011
comment
Да, но мне нужно имя для различных видов использования дисплея и идентификатор для использования при записи обновленной информации о пользователе во время редактирования.   -  person Kyeotic    schedule 22.06.2011
comment
этот вопрос заслуживает большего количества голосов, так что; +1   -  person Phil    schedule 26.07.2011

Ответы (1)


arrow_upward
18
arrow_downward

Вот некоторые дополнительные пояснения, которые помогут вам принять решение.

  1. SetAuthCookie может быть реализован таким образом, чтобы хранить несколько значений. На практике, однако, обычно невозможно сохранить достаточно, чтобы избежать поиска в базе данных. Лучше всего сохранить имя пользователя (уникальный идентификатор) и загружать дополнительную информацию во время запроса. Как подсказывает ваш вопрос, вы не должны хранить на нем конфиденциальную информацию. Вы должны предполагать, что вся информация, отправляемая в файле cookie, может быть расшифрована и прочитана, и вы должны принять меры предосторожности, чтобы эта информация не могла быть использована злонамеренно. Все файлы cookie сеанса можно украсть, и я сейчас объясню почему.

  2. FormsAuthenticationTicket - это тот же API, что и SetAuthCookie, но на более низком уровне в Framework. С SetAuthCookie в любом случае должны выполняться Encrypt () и Decrypt () (это конфигурация по умолчанию). Это не расточительно, но вместо этого используйте метод 1, потому что это проще.

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

Все три метода считаются опасными по той же причине, по которой опасны все системы аутентификации на основе файлов cookie: потому что значение файла cookie можно прослушать по беспроводной сети и повторно использовать для захвата сеанса. Это известно как sidejacking, и это также применимо к сценариям 1 и 2. Способ предотвратить это - реализовать HTTPS. Затем передача файлов cookie (и все остальное) зашифровывается на сетевом уровне и не может быть украдена.

TL; DR; Используйте SetAuthCookie и HTTPS

ПРИМЕЧАНИЕ: этот ответ несколько раз редактировался для ясности.

person BC.    schedule 22.06.2011