Реализация SCRAM - одноразовая проверка и ключи сервера / клиента

Question

Технически два вопроса - но они так тесно связаны, что я не хотел их разделять; но если сообщество считает, что я должен, я буду.

После недавнего вопроса Я внедряю SCRAM для входа на веб-сайт и API веб-службы. Клиентские среды будут .Net и Javascript (с вероятностью появления Java в будущем).

Моя первая проблема является базовой: Протокол использует клиентский и серверный ключ в качестве ключевых шагов в процессе аутентификации; и тем не менее, для того, чтобы их можно было проверить, обе стороны должны знать заранее, так как протокол не позволяет обмениваться ими (это может привести к некоторому сценарию с курицей и яйцом). Например, если вы рассматриваете клиент Javascript, это означает, что оба ключа, вероятно, будут константами, определенными в источнике, что облегчает их выбор. Итак: зачем? Это просто для смягчения против Eve, когда Eve по какой-то причине не удосужился получить исходный код JS или клиента, который обязательно будет общедоступным!?

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

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

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

Как всегда с аутентификацией и шифрованием; Несмотря на то, что я очень опытный разработчик программного обеспечения, я чувствую, что возвращаюсь в школу! Чего мне не хватает!?

Answer 1

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

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

Если вы, например, рассматриваете клиент Javascript, этоозначает, что оба ключа могут быть константами, определенными в источнике, что упрощает их выборку.

Это не очень хорошая идея.В качестве альтернативы клиент и сервер могут согласовать ключ во время предварительной регистрации.

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

НЕТ.Новый одноразовый номер должен генерироваться для каждого нового сеанса с использованием генерации псевдослучайных чисел.Очень маловероятно, что вы получите один и тот же одноразовый номер дважды, так или иначе. Не имеет значения, использовался ли этот одноразовый номер, если злоумышленник этого не знает.