Передача пароля по открытому каналу (часть 2)

Ушел ставить эксперименты. Спасибо за статью, очень актуально для моего проекта.

Идея интересная.
Демонстрация у меня не работает :(

alert: Invalid RSA private key
и экзепшн:
Uncaught TypeError: Cannot call method 'bitLength' of null
jsbn2.js:412

Chrome (Linux) 12.0.742.91

Отличное решение, круче по-моему только использование clietside-токенов.

Рекоммендую почитать RFC2945 — авторизация без SSL, при которой на сервере вообще не хранится пароль от пользователя, и не передаётся никогда — ни при авторизации, ни при регистрации, и прослушивание не позволяет получить информации, достаточной для доступа до системы.

Я реализовывал это на JS + PHP, и даже работало :) одна проблема, тормозило тогда.
Возможно, на современных JS движках будет работать быстро.

Если народу будет интересно — обнародую, а может даже доведу до ума — ибо самое простое решение это flash/java аутентификатор, и fallback на js если эти два недоступны.

Прекрасная техническая статья, с минимумом «воды». Спасибо!

У Вас сейчас везде логин просто конкатенируется с паролем, а это значит, что у юзера «test» с паролем «test» и юзера «tes» с паролем «ttest» ключи k, под которыми шифруются их закрытые ключи, совпадают :)

Я бы поправил для красоты.

Еще можно было бы добавить, что схема авторизации может маштабироваться на множество сайтов
как система OpenID. То есть закрытый ключ публикуется на доверенном сайте, а открытые ключи хранятся
на сайте регистрации пользователя. Иначе система напоминает PGP с удаленным недоверенным хранилищем
(что мешает подменить ключ на свой, с иным паролем?). Так на закрытый ключ можно было бы
ограничить распространение с помощью листа доступа с тем, чтобы исключить возможность
компрометации слабых паролей брутфорсом или словарным подбором. Подобная мера позволила бы менять
пароль в случае вероятности вскрытия этого секрета, и не потребовало бы обязательного отзыва всех
имеющихся сертификатов открытых ключей. Хотя вариант в протоколе заложить возможность отзыва
старого сертификата все же предпочтительней.

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

В довершение хочу заметить, что DSA больше подходит для воплощения данного алгоритма, так как
подпись на RSA (можно использовать SIGN(RND,e,N) вместо передачи HASH(RND) в ответе на запрос
авторизации, а в самом запросе отказаться от шифрации случайного числа) на порядок медленней,
чем в DSA.