MVC3 и аутентификация - программирование

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

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

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

FormsAuthentication.SetAuthCookie(). В нем хранится файл cookie сеанса, который будет отображаться в браузере, и ничто не чувствительно к клиенту. Однако он может хранить только одно значение. Этот ответ stackoverflow показывает способ хранения нескольких значений здесь, но тот, кто его дает, говорит, что не использует его, хотя и не почему.
FormsAuthenticationTicket. Я не знаю, где хранится эта информация, но она позволяет использовать простой способ хранения нескольких значений. Для обеспечения безопасности в соответствии с документацией требуется вызвать Encrpty() для хранения и дешифрования() для извлечения. Это кажется расточительным, но что я знаю.
Сессия [ "SomeRef" ] = новый CustomObject(). Второй ответ в этом question объясняет, как это сделать, но комментарий к нему называет его опасным, потому что его можно украсть. Это выглядит как лучший метод для меня, потому что информация все еще хранится на сервере и может хранить несколько значений.

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

Ответ 1

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

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

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

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

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