Вопрос или проблема
Недавно я прочитал о протоколе аутентификации SCRAM. Одной из заявленных целей проектирования является поддержка взаимной аутентификации, но как клиент может проверить, что параметры соли и стоимости, предоставленные сервером, являются правильными?
Если сервер предоставляет ту же соль, что и для другого пользователя, это может раскрыть, что у них общий пароль, а если сервер предлагает очень низкие параметры стоимости, хэш будет легче взломать. Это может позволить серверу обмануть во время взаимной аутентификации, и, возможно, злонамеренному серверу получить доступ к учетным данным пользователя.
Эту проблему можно легко решить, позволив клиенту игнорировать то, что говорит сервер, и использовать статический параметр стоимости и детерминированную соль, определённую клиентом, но тогда мы больше не будем следовать спецификации. Если мы хотим использовать значения, предоставленные сервером, каков хороший способ это сделать? Должен быть способ для клиента проверить, что это те же параметры, что использовались при регистрации учетной записи, но у меня не получается найти информацию о том, как.
Протокол SCRAM предполагает, что клиент и сервер уже в какой-то момент установили доверие, согласовали параметры хэширования (алгоритм хэширования/HMAC, количество итераций, соль) и безопасно обменялись StoredKey и ServerKey. Оба действуют как общие секреты для обеспечения взаимной аутентификации в последующих соединениях.
Если клиент не доверяет серверу, то ему вообще не следует создавать учетную запись. В этом случае SCRAM не имеет значения. Если клиент доверяет серверу, он все равно может требовать другие параметры хеширования в процедуре регистрации (что не определено в SCRAM). Например, он может отклонять слабые алгоритмы хэширования/HMAC или низкое количество итераций. Либо клиент и сервер могут согласовать параметры, либо им придется прервать регистрацию, и SCRAM не имеет значения.
В процессе аутентификации SCRAM клиент снова может отклонить параметры хэширования, которые он считает ненадежными. Верно, что соль не может быть легко проверена сама по себе. Однако, если пароль настолько слаб, что другой пользователь придумал такой же, то его легко атаковать в любом случае. Соли не могут и не должны скрывать слабые пароли.
Ответ или решение
Как проверить соль в протоколе SCRAM
Введение
Протокол аутентификации SCRAM (Salted Challenge Response Authentication Mechanism) разработан для обеспечения безопасной аутентификации и поддержки взаимной аутентификации между клиентом и сервером. Одной из ключевых проблем, поднимаемых пользователями, является возможность верификации соли и параметров стоимости, предоставляемых сервером. В данной статье мы рассмотрим, как клиент может обеспечить достоверность этих параметров и какие меры предосторожности следует принимать для предотвращения возможных атак.
Основы протокола SCRAM
Прежде чем углубляться в детали, важно понимать, что SCRAM предполагает, что клиент и сервер ранее установили уровень доверия и согласовали параметры хеширования (хеш/алгоритм HMAC, итерации, соль). Во время регистрации учетной записи сервер хранит два реакции: StoredKey и ServerKey, которые служат для взаимной аутентификации в последующих соединениях.
Проблемы верификации параметров соли и стоимости
-
Вероятные атаки: Если сервер предоставляет ту же соль, что и для другого пользователя, это может позволить злоумышленником обнаружить, что два пользователя используют один и тот же пароль. Кроме того, если сервер выбирает слишком низкие параметры стоимости, то хеширование становится проще для подбора, что подвергает угрозе безопасность аутентификации.
-
Недостаток контроля: Клиент не может проверить соль в явном виде, но это можно компенсировать правильной комбинацией других проверок.
Как клиент может проверить параметры
Хотя клиенты не могут независимо проверить соль и параметры стоимости, существуют следующие подходы для обеспечения безопасности протокола:
-
Договорённости на этапе регистрации: Клиент может установить определённые политики на этапе регистрации, такие как минимальная стоимость и рекомендуемые алгоритмы хеширования. Если сервер предложит параметры, которые не соответствуют этим требованиям, клиент должен отказать в регистрации или запросе аутентификации.
-
Безопасный обмен ключами: При аутентификации клиент использует
StoredKeyиServerKeyдля выполнения проверки. На этом этапе, даже если сервер предоставляет неверные параметры соли или стоимости, проверка на основе этих ключей позволяет выявить несоответствия. -
Сравнение с заранее известными значениями: Клиент может сохранять информацию о зарегистрированных учетных записях и их параметрах. Если при последующих аутентификациях сервер предоставляет не те значения, с которыми был первоначально зарегистрирован пользователь, клиент может завершить сессию.
-
Динамическое управление безопасностью: Клиент может осуществлять динамическое управление границами безопасности и необходимо повторно проходить процедуру верификации, если параметры системы изменяются. Например, если сервер изменяет параметры стоимости, клиент может инициировать новый процесс регистрации или запрашивать изменение аутентификационных данных.
-
Использование специальных флагов: Протокол может быть дополнен механизмами, позволяющим клиенту проверять надежность параметров, таких как добавление флагов, указывающих на приемлемость условий безопасности и параметров хеширования.
Заключение
Вопрос проверки параметров соли и стоимости в протоколе SCRAM представляет собой сложную задачу, без явных способов верификации. Тем не менее, с помощью установления твердых правил на этапе регистрации и использования хеш-кодов на основе заранее согласованных параметров, клиент может защищать свои учетные записи и гарантировать, что протокол аутентификации поддерживается на уровне, соответствующем современным стандартам безопасности. Полное доверие к серверу в вопросах аутентификации должно базироваться на предыдущих договорах об обмене секретами и параметрами безопасности, что минимизирует любые риски компрометации.