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

Question

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

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

Есть мысли? Есть хорошие примеры?

Answer 1

Проблема с предпочтением сеансов вместо файлов cookie для «безопасности» заключается в том, что сеансы ИСПОЛЬЗУЮ файлы cookie для идентификации пользователя, поэтому любая проблема с файлами cookie присутствует в сеансах.

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

Поскольку вы используете .NET, вам придется написать свой собственный поставщик хранилища сеансов, чтобы справиться с этим, поскольку InProc не будет масштабироваться выше 1 сервера, поставщик БД - это просто плохая идея ИЗБЕГАЙТЕ БД читает здесь при масштабировании, а не добавлять больше), а у StateServer много проблем с емкостью. (В прошлом я использовал поставщика хранилища сессий memcached с некоторым успехом для борьбы с этой проблемой).

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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