Аутентификация на базе ЭЦП

Имея на руках даже один раз перехваченные Login, RNDclient, RNDserver и ЭЦП, для атакующего все сведется опять к той же самой атаке на пароль по словарю или перебором.

«ECC криптографически более стойкая чем RSA, что позволяет использовать более короткие ключи, и как следствие, снижает требования к производительности.»
Некорректное утверждение про производительность.
1) ECC и RSA работают на разной математике. ECC использует более короткую длину ключей, но и сложность вычислений ECC для такой длины ключей существенно выше.
2) RSA может быть ускорен за счёт CRT, ECC может быть ускорен за счёт предвычислений.
3) У RSA операция на закрытом ключе (расшифровка/подпись) считается сложнее, чем на открытом (шифрования/проверка); у ECC проверка подписи в ~2 раза сложнее формирования и согласования ключа.
А ещё зависит от архитектуры вычислителя и т.п.

Спасибо, за профессиональный комментарий!
Фраза про производительность у меня вышла конечно корявенькая. Расшифрую.
1) При генерации ключевой пары в RSA на основе пароля открытый ключ получится с весом приблизительно равным половине длины открытого ключа в битах. Это повлечет за собой увеличение нагрузки на сервер при проверке ЭЦП.
2) Сама по себе генерация ключевой пары, проходящая на стороне клиента, в RSA более требовательна к производительности чем в ECC в связи с необходимостью проверки p и q на простоту.
3) Так же на стороне клиента производится именно формирование подписи которая в RSA более требовательная к производительности чем проверка, а в ECC наоборот.
Последние два пункта особенно заметно влияют на производительность в скриптовых языках на которых написан пример (javascript).

А существует ли такая вещь, как СКЗИ на ГОСТе с реализацией на JS? Чтобы генерировать юридически-значимую ЭЦП?

Я не понял. 1. Где тут ЭЦП? 2. Зачем тут «RSA»? 3. Почему бы, если уж «RSA» и «SHA256(login+password)», не пользоваться потом обычной Digest аутентификацией из восстановленного пароля?

Да и вообще, зачем все это? Если так хочется что-то навелосипедить, можно прочитать сначала ISO/IEC 11770-* (4)

Я не совсем понял что мешает использовать пресловутый SSL.
Зачем использовать небезопасное соединение и потом мучиться оттого что оно небезопасное? Критические данные на сервисе, где безопасность прежде всего, должны передаваться через https и не только пароли, но и данные из GET, POST.

В предложенной схеме нехватает привязки к промежутку времени.

MitM может перехватывать RNDserver и запоминать соответствующие Sign(SHA256(RNDserver+RNDclient)).
Через некоторое время он накопит достаточное количество RNDServer и будет осуществлять попытки пройти аутентификацию перед сервером. Как только он получит известный ему RNDServer, он достанет из базы подписанный ответ и войдёт в систему.

Разумеется вероятность взлома зависит количества возможных RNDserver и от фазы луны. Но мы имеем дело с точной наукой и такого фейла можно избежать.

Ключевая идея в алгоритме — это генерация пары открытый/закрытый ключ на лету на основе парольной фразы. Остальной механизм аутентификации можно сделать более стойким. см. Applied cryptography by Bruce Schneier.

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

Данный методе некорректно сравнивать с HTTPS:
Он решает задачу надёжной авторизации пользователей без затрат на разворачивание PKI на сервере.

Зато метод можно сравнить с Digest Auth.
Для последнего, пароль на сервере должен храниться в открытом виде, а это просто уничтожает преимущество того, что пароль не передаётся по сети. Как только злоумышленник получит доступ к серверу — сразу все пользователи скомпрометированы. Не айс.

В этом методе (WebToken — да?) по сети передаётся только цифровая подпись, а на сервере хранится только публичный ключ, который можно хоть на сайте публиковать. Тру :)

Да, кстати. Забыл добавить. При использовании такого метода аутентификации в веб форме не имеет смысла. Просто потому что я при активном MitM могу подгрузить заместь вашего js что угодно. Тут — только HTTPS.

> Почему до сих пор пароли передают в открытом виде?
очевидно скоро уже сделают реализацию md5 & sha самим браузером или встроенной функцией JS
это сильно упростит жизнь и повысит быстродействие

> Почему хранят и пароли в БД в открытом виде или в виде хешей без соли?
ну, это не секрет — много дураков на белом свете
лень матушка вперед нас родилась.

Мне лично больше нравится механизм Oauth 1.0 (1.0a).
Клиент к каждому http-запросу добавляет заголовок типа:

Authorization: OAuth oauth_consumer_key="mipeha.org.ru",
  oauth_token="1%252FI7yTvPqJeJvD0MRC-LFLDrKZi0RNap7ZgVabspi6HOk",
  oauth_nonce="6da9c93552fe248616009923350e66a9",
  oauth_timestamp="1303544907",
  oauth_signature_method="RSA-SHA1",
  oauth_signature="jxw9GcA098Lo3nJ.......Wx5ZhX34vQmY15PiejefoD1Dw4v9eE%3D"

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

Мне тоже нравится механизм Oauth 1.0, но он не имеет отношения к аутентификации пользователей. Он используется для аутентификации приложений. Oauth 1.0 по сути очень похож на описанную выше схему, он использует подпись присланного запроса с помощью своего закрытого ключа прописанного в приложении. Этот ключ может быть полноценным RSA ключом (генерится владельцем приложения) или неким «паролем», который по сути тоже ключ (генерится на сервере и сообщается владельцу, по крайней мере так в Google).