Уже в нескольких топиках рассматривались проблемы построения безопасного механизма аутентификации при небезопасном соединении. Ниже предлагается к обсуждению схема с использованием асимметричной криптографии. Такой подход позволит аутентифицироваться на сервере, никогда не передавая серверу пароль, ни при регистрации, ни при аутентификации. Как всегда, будет демонстрация и исходные коды. Кому данная тема интересна, прошу под кат.
Ранее мы уже рассмотрели несколько вариантов:
Регистрация.
Прилагается демонстрация. В подготовке примера использовались библиотека написанная студентами Стэнфорда. Отдельное спасибо хорошему человеку Мартыненко Александру, у которого к сожалению нет инвайта на Хабр, за программную реализацию генерации ключевой пары и формирования ЭЦП по алгоритму ГОСТ Р 34.10-2001 в прилагаемом примере.
Конечно, все приведенные примеры, всего лишь примеры. Для их «боевого» использования надо сперва хорошо подумать и больше внимания уделить различным «мелочам». Однако само существование различных защищенных протоколов аутентификации приводит к вопросам. Почему до сих пор пароли передают в открытом виде? Почему хранят и пароли в БД в открытом виде или в виде хешей без соли? При общении с некоторыми представителями крупных онлайн-сервисов о безопасности их аккаунтов не раз слышал вопрос — А где здесь наша выгода? Так все же, есть ли выгода в безопасности ваших пользователей?
Ранее мы уже рассмотрели несколько вариантов:
- Решение с шифрованием пароля самое простое и имеет огромное преимущество — внедрение такой схемы не требует перерегистрация пользователей. Безопасность этого решения не на высоте, но все равно лучше, чем пароли передаваемые в открытом виде.
- SRP-6, о котором тоже рассказывалось — безопасный протокол. Из недостатков, пожалуй, только длинный диалог с сервером и сложность реализации.
- Аутентификация на базе Рутокен, описанная здесь, очень безопасное решение, но сравнивать его с чисто программными решениями некорректно. И надо отметить, что не все пользователи готовы платить за дополнительное устройство.
Регистрация.
- Клиент выбирает 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 в прилагаемом примере.
Конечно, все приведенные примеры, всего лишь примеры. Для их «боевого» использования надо сперва хорошо подумать и больше внимания уделить различным «мелочам». Однако само существование различных защищенных протоколов аутентификации приводит к вопросам. Почему до сих пор пароли передают в открытом виде? Почему хранят и пароли в БД в открытом виде или в виде хешей без соли? При общении с некоторыми представителями крупных онлайн-сервисов о безопасности их аккаунтов не раз слышал вопрос — А где здесь наша выгода? Так все же, есть ли выгода в безопасности ваших пользователей?