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

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

Ранее мы уже рассмотрели несколько вариантов:

• Решение с шифрованием пароля самое простое и имеет огромное преимущество — внедрение такой схемы не требует перерегистрация пользователей. Безопасность этого решения не на высоте, но все равно лучше, чем пароли передаваемые в открытом виде.
• SRP-6, о котором тоже рассказывалось — безопасный протокол. Из недостатков, пожалуй, только длинный диалог с сервером и сложность реализации.
  
• Аутентификация на базе Рутокен, описанная здесь, очень безопасное решение, но сравнивать его с чисто программными решениями некорректно. И надо отметить, что не все пользователи готовы платить за дополнительное устройство.

Предлагаемый механизм аутентификации использует тот же протокол, что и решение на базе Рутокен. Основное отличие заключается в том, что все криптографические операции выполняются программно, а приватный ключ формируется на основании пароля. Оба решения используют криптографию на базе эллиптических кривых (ECC). ECC криптографически более стойкая чем RSA, что позволяет использовать более короткие ключи, и как следствие, снижает требования к производительности. И так:

Регистрация.

• Клиент выбирает login и password;
• На их основе формируется PrivateKey = SHA256(login+password);
• На основе PrivateKey формируется PublicKey;
• Login и PublicKey отправляются на сервер и сохраняются в БД.

Аутентификация.

• Клиент вводит логин и пароль;
• На их основе формируется PrivateKey = SHA256(login+password);
• Клиент получает от сервера случайное число(RNDserver) и генерирует свое случайное число(RNDclient);
• С помощью PrivateKey клиент формирует ЭЦП Sign(SHA256(RNDserver+RNDclient)) и отправляет на сервер Login, RNDclient и ЭЦП;
• Сервер проверяет корректность ЭЦП с помощью PublicKey клиента, хранящегося в БД.

Прилагается демонстрация. В подготовке примера использовались библиотека написанная студентами Стэнфорда. Отдельное спасибо хорошему человеку Мартыненко Александру, у которого к сожалению нет инвайта на Хабр, за программную реализацию генерации ключевой пары и формирования ЭЦП по алгоритму ГОСТ Р 34.10-2001 в прилагаемом примере.

Конечно, все приведенные примеры, всего лишь примеры. Для их «боевого» использования надо сперва хорошо подумать и больше внимания уделить различным «мелочам». Однако само существование различных защищенных протоколов аутентификации приводит к вопросам. Почему до сих пор пароли передают в открытом виде? Почему хранят и пароли в БД в открытом виде или в виде хешей без соли? При общении с некоторыми представителями крупных онлайн-сервисов о безопасности их аккаунтов не раз слышал вопрос — А где здесь наша выгода? Так все же, есть ли выгода в безопасности ваших пользователей?