Состояние веб-аутентификации - сеанс против Cookie?

Каков наилучший способ аутентификации и отслеживания состояния аутентификации пользователей со страницы на страницу? Некоторые говорят о состоянии сеанса, некоторые говорят, что куки?

Могу ли я просто использовать переменную сеанса, которая имеет идентификатор пользователя и после аутентификации, установить пользовательский класс пользователя, который имеет информацию о пользователе. Затем, на каждой странице, проверьте, что переменная сеанса по-прежнему активна и доступ к базовым пользовательским данным из объекта User?

Любые мысли? Какие-нибудь хорошие примеры?

Ответ 1

Нет идеального способа сделать это. Если вы сохраните его в файле cookie, вы поймете, что куки могут быть украдены. Если вы храните его в сеансе, вы будете использовать flak, потому что сеансы могут быть захвачены.

Лично я склонен думать, что сеанс немного более надежный, потому что единственное, что хранится на клиенте, - это ключ сеанса. Фактические данные остаются на сервере. Если вы это сделаете, карты будут немного ближе к сундуку. Тем не менее, что только мое предпочтение и хороший хакер могли бы пройти мимо дрянной безопасности независимо.

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

Ответ 2

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

Одна вещь, которую следует учитывать при использовании сеансов, - это локальность данных. Если вы планируете масштабировать до нескольких веб-серверов в любой момент, вам нужно очень тщательно хранить большие объемы данных в объектах сеанса.

Поскольку вы используете .NET, вам в основном придется написать собственный поставщик хранилища сеансов, чтобы обработать это, так как InProc не будет масштабироваться за 1 сервер, поставщик БД - это всего лишь плохая идея (все дело в том, чтобы AVOID DB читает здесь при масштабировании, а не добавляет больше), а StateServer имеет много проблем с производительностью. (Раньше я использовал провайдера хранилища memcached с некоторым успехом для борьбы с этой проблемой).

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

Ответ 3

Я не знаю, является ли его ЛУЧШИМ способом сделать это, но нам комфортно с тем, как мы это делаем.

У нас есть пользовательский объект, который мы создаем, когда пользователь аутентифицируется, затем мы используем Session для поддержки этого объекта в приложении.

В некоторых приложениях мы объединяем его с использованием файлов cookie для непрерывного продления сеанса.

Ответ 4

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

Ответ 5

Сессии - это файлы cookie...