Cookie Security

Question

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

Вот мое гипотетическое решение для безопасности:

• Пользователь регистрируется на сайте (посредством регистрации по электронной почте, через Facebook и т. Д.) И получает идентификационный номер пользователя.Этот номер является общедоступным и может использоваться для доступа к профилю пользователя, ссылки на него в сообщениях и т. Д.
• При регистрации пользователю также назначается случайно сгенерированный ROWID, поскольку его информация хранится вбаза данных (размещена в Google Fusion Tables).Этот номер ROWID скрыт от пользователя и никогда не раскрывается.
• Идентификатор пользователя зашифрован относительно номера ROWID, и этот номер сохраняется в файле cookie на компьютере пользователя.Он никогда не будет виден другим пользователям, и, теоретически, это может просматривать только пользователь.

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

Answer 1

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

Вот как избежать этих проблем:

Set-Cookie: userName=Alice; authCode=eeba95a4...

Где: authCode = HMAC (ROWID, userName + ipAddr)

Когда вы получите этот cookie, найдите пользователя в базе данных, пересчитайте / проверьте authCode в cookie, используя ROWID иIP-адрес запроса.Нет необходимости хранить файлы cookie в базе данных.

Для дополнительных точек шифрования добавьте в смесь параметр salt :

Set-Cookie: userName=Alice; salt=59843...; authCode=eeba9...

Где: authCode = HMAC (ROWID, userName + ipAddr + salt)

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

Answer 2

Это хороший вопрос, и так как у вас еще нет ответов, я попробую.Насколько я понимаю (я не специалист по криптографии), это кажется разумным, по крайней мере, в теории.Я вижу одну проблему: если злоумышленник получит ключ потребителя (и он никак не защищен), он может попытаться перехватить ROWID, поскольку он уже знает идентификатор пользователя.Поэтому, по крайней мере, какая-то соль должна быть добавлена ​​в идентификатор пользователя перед шифрованием.Кроме того, «потребительский» ключ ccokie должен передаваться только как безопасный, чтобы он никогда не передавался по незашифрованному соединению.

Но все зависит от того, для чего вы собираетесь использовать разные ключи.