Идентификатор сеанса входа с хэшем

Question

Я прочитал, что обычным способом обработки сеансов входа в систему является хранение длинной случайной строки на стороне сервера и установка cookie с этой строкой в ​​качестве значения.

По каким причинам не следует пытаться устранить нагрузку на сервер другим способом. Метод, который меня больше всего беспокоит, - это сохранение файла cookie, содержащего информацию о вошедшем в систему пользователе (и сеансе и т. Д.), И обеспечение подлинности файла cookie путем его подписания вместо сохранения данных, специфичных для файла cookie, на стороне сервера.

Answer 1

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

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

Answer 2

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

Однако, если все сделано правильно, это может не снизить нагрузку на сервер. Хотя вам больше не нужно искать (некоторую) информацию о сеансе, вам необходимо выполнять криптографические операции с каждым запросом для проверки cookie. (Это может быть очень дорого для процессора.)

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

Answer 3

Предполагается, что вы отслеживаете пользователя, связывая его с идентификатором сеанса после входа в систему:

Если вы храните все состояния на стороне клиента в подписанном файле cookie (даже если это, например, только их идентификатор входа в систему), вы рискуете, что пользователи будут действовать как другие пользователи, если ваши ключи подписи будут скомпрометированы. Вы можете уменьшить это до некоторой степени, используя отдельный ключ подписи для каждого пользователя, но теперь вам нужно использовать cookie-файл, чтобы отслеживать, какой ключ подписи использует пользователь. Вы также можете попробовать использовать временную схему для подписи ключей (например, поворачивать их каждые 5 минут), но теперь вы размещаете загрузку подписи на своем сервере, чтобы повторно генерировать подписи cookie каждые 5 минут для всех сеансов.

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