MVC3 и аутентификация - PullRequest
Новая
       41

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

12 голосов
/ 22 июня 2011

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

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

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

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

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

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

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

1 Ответ

18 голосов
/ 22 июня 2011

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

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

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

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

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

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

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

...