Подписанные файлы cookie сеанса. Хорошая идея?

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

Очень простой пример:

userid= 12345
time=now()
signature = hmac('SHA1',userid + ":" + time, secret);

cookie = userid + ':' + time + ':' + signature;

Время будет использоваться для максимального срока годности, поэтому куки не будут жить вечно.

Теперь о большом вопросе: это плохая идея?

Мне лучше использовать AES256 вместо этого? В моем случае данные не являются конфиденциальными, но их нельзя изменять ни при каких обстоятельствах.

РЕДАКТИРОВАТЬ

После некоторой хорошей критики и комментариев я хотел бы добавить это:

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

Последнее замечание: я пытаюсь найти решения для уменьшения нагрузки на базу данных. Это только одно из решений, которые я исследую, но это мое любимое решение. Основная причина в том, что мне не нужно искать другой механизм хранения, лучше подходящий для такого рода данных (memcache, nosql), и это делает веб-приложение немного более "не имеющим состояния".

10 лет спустя редактировать

JWT теперь вещь.

Ответ 1

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

с ограничением по времени, счет-Логин;
пароль восстановление;
формы анти-XSRF;
время-ограничение-форма-представление (анти-спам).

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

HMAC - один из разумных способов генерации подписанного токена. Это не будет самым быстрым; вы можете уйти с простым хешем, если знаете и можете избежать атак расширения. Я оставлю вас решить, стоит ли вам рисковать.

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

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

Ответ 2

Да, это плохая идея.

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

Идентификаторы сеансов должны выбираться из большого (128-битного) пространства криптографическим генератором случайных чисел.

Они должны быть закрытыми, чтобы злоумышленники не могли украсть их и олицетворять аутентифицированного пользователя. Любой запрос, который выполняет действие, требующее авторизации, должен быть защищен от несанкционированного доступа. То есть весь запрос должен иметь некоторую защиту целостности, такую как HMAC, чтобы его содержимое не могло быть изменено. Для веб-приложений эти требования неумолимо приводят к HTTPS.

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

Если канал не имеет конфиденциальности и целостности, вы открываете себя для атак типа "человек в середине". Например, без конфиденциальности Алиса отправляет свой пароль Бобу. Ева обманывает его и может войти позже, как Алиса. Или, с частичной честностью, Алиса присоединяет свой подписанный файл cookie к запросу на покупку и отправляет его Бобу. Ева перехватывает запрос и изменяет адрес доставки. Боб проверяет MAC на cookie, но не может обнаружить, что адрес был изменен.

У меня нет цифр, но мне кажется, что возможности для нападений "человек в середине" постоянно растут. Я замечаю рестораны, используя сеть wi-fi, которую они предоставляют клиентам для обработки своей кредитной карты. Люди в библиотеках и на рабочих местах часто восприимчивы к обнюхиванию, если их трафик не превышает HTTPS.

Ответ 3

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

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

Теперь о большом вопросе: это плохая идея?

Короткий ответ: нет, это не плохая идея, на самом деле это действительно хорошая идея, ставшая отраслевым стандартом.

Длинный ответ: это зависит от вашей реализации. Сессии отличные, они быстрые, они простые и их легко защитить. Однако, когда система без сохранения состояния работает хорошо, она немного сложнее для развертывания и может выходить за рамки небольших проектов.

Внедрение системы аутентификации на основе токенов (куки) в настоящее время очень распространено и работает исключительно хорошо для систем без учета состояния /apis. Это позволяет проводить аутентификацию для множества различных приложений с одной учетной записью. то есть. войдите на {неаффилированный сайт} через Facebook/Google.

Внедрение такой системы oAuth само по себе является БОЛЬШИМ предметом. Поэтому я оставлю вас с некоторыми документами oAuth2 Docs. Я также рекомендую изучить Json Web Tokens (JWT).

дополнительный

Последнее замечание: я пытаюсь найти решения для уменьшения нагрузки на базу данных. Это только одно из решений, которые я исследую

Redis будет хорошо работать для разгрузки запросов к базе данных. Redis - это простая в памяти система хранения. Очень быстрое ~ временное хранилище, которое может помочь уменьшить количество обращений к БД.

Ответ 4

Что заставляет вас думать, что это улучшит производительность по сравнению с безопасными идентификаторами сеанса и извлечет информацию о пользователе и времени из серверного компонента сеанса?

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

Игнорируя идеологические проблемы, это выглядит довольно прилично. У вас нет nonce. Вы должны добавить это. Просто какой-то случайный мусор, который вы храните вместе с идентификатором пользователя и временем, чтобы предотвратить повтор или предсказание.

Ответ 5

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

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

Вероятно, вы используете тот же секрет для расчета HMAC для всех сеансов. Таким образом, этот секрет может быть грубо принужден злоумышленником, входящим в его учетную запись. Рассматривая его идентификатор сеанса, он может получить все, кроме тайны. Тогда злоумышленник может перенаправить секрет, пока значение hmac не будет воспроизведено. Используя этот секрет, он может восстановить административный файл cookie и изменить его user_id=1, который, вероятно, предоставит ему административный доступ.