Я хочу знать, что более безопасно реализовать для аутентификации и почему? Аутентификация на основе сеанса ИЛИ аутентификация на основе токена?

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

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

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

Безопасность

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

Например, генерация внутреннего идентификатора сеанса PHP использует полностью случайное число в 288 бит (настройка по умолчанию), поэтому оно считается безопасным, OTOH — по умолчанию он генерирует сеансы автоматически, поэтому необходимо придерживаться предыдущего комментария (или отключить автоматическое создание сеанса и убедиться, что сервер создает сеанс только по мере необходимости).

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

Безопасность токенов в основном основана на безопасной генерации токенов: если сервер генерирует токены безопасным способом, то есть не поддающимся угадыванию и проверке, как показано в ответе по информационной безопасности. Наивная реализация (которую я видел однажды) может заключаться в том, чтобы MD5 хэшировал известный токен, такой как имя пользователя, и это делает его очень небезопасным, даже если он соленый. При использовании криптографических токенов безопасность тесно связана с надежностью шифрования, которая определяется используемым алгоритмом, длиной ключа и — что наиболее важно — тем, насколько хорошо защищен ключ сервера: если ключ сервера жестко закодирован в серверной реализации, и этот код затем является открытым исходным кодом…

Хранение

Нужно ли серверу что-либо хранить, обычно зависит от реализации токенов.

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

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

Два шаблона, используемые для этого, хорошо продемонстрированы в ответе по информационной безопасности: подписание и шифрование.

• Подписание: Токен представляет собой некоторую простую кодировку (например, JSON или CSV) учетных данных аутентификатора (таких как имя пользователя) и, возможно, время истечения срока действия токена (если вы хотите, чтобы срок действия токенов истек — как правило, хорошая идея, если вы не можете отозвать токены), а затем сервер подписывает сгенерированный текст, используя секрет сервера, и добавляет его к токену. Когда клиент отправляет токен, сервер может извлечь открытый текст из токена, повторно подписать его и сравнить новую подпись с частью подписи в отправленном токене — если они идентичны, то токен действителен. После проверки вы, вероятно, захотите сверить подтвержденную дату истечения срока действия с текущим временем. Основным недостатком здесь является то, что следует позаботиться о том, чтобы данные аутентификации открытым текстом были явно недостаточны для повторной аутентификации злоумышленника — в противном случае это наносит ущерб требованиям безопасности. т. е. не отправляйте пароль как часть токена или любой другой внутренней детали.

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

В обоих методах безопасность тесно связана с надежностью алгоритма шифрования / подписи — слабый алгоритм позволит злоумышленнику перепроектировать секрет сервера и сгенерировать новые действительные токены без аутентификации.

Личное замечание

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

Всегда помните правило № 1 криптографической безопасности: никогда не разрабатывайте собственные одноразовые криптографические меры.