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

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

    Ранее мы уже рассмотрели несколько вариантов:
    • Решение с шифрованием пароля самое простое и имеет огромное преимущество — внедрение такой схемы не требует перерегистрация пользователей. Безопасность этого решения не на высоте, но все равно лучше, чем пароли передаваемые в открытом виде.
    • 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 в прилагаемом примере.

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

    Подробнее
    Реклама
    Комментарии 48
    • 0
      Имея на руках даже один раз перехваченные Login, RNDclient, RNDserver и ЭЦП, для атакующего все сведется опять к той же самой атаке на пароль по словарю или перебором.
      • 0
        Перебор возможен всегда. А вот другие «более быстрые» варианты типа радужных таблиц здесь не применимы.
        • 0
          Перебор возможен всегда, если перехвачены передаваемые данные. Поэтому слабый пароль может спасти только SSL-соединение и ограничение на количество неправильно введенных паролей.
          • +1
            Да, как и на любую криптографическую систему, на эту схему возможна атака полным перебором, однако при использовании нормального ключа в приемлемые сроки это сделать невозможно. При использовании же в качестве ключа пароля, стойкость системы ограничена стойкостью пароля.
      • +3
        «ECC криптографически более стойкая чем RSA, что позволяет использовать более короткие ключи, и как следствие, снижает требования к производительности.»
        Некорректное утверждение про производительность.
        1) ECC и RSA работают на разной математике. ECC использует более короткую длину ключей, но и сложность вычислений ECC для такой длины ключей существенно выше.
        2) RSA может быть ускорен за счёт CRT, ECC может быть ускорен за счёт предвычислений.
        3) У RSA операция на закрытом ключе (расшифровка/подпись) считается сложнее, чем на открытом (шифрования/проверка); у ECC проверка подписи в ~2 раза сложнее формирования и согласования ключа.
        А ещё зависит от архитектуры вычислителя и т.п.
        • +2
          Спасибо, за профессиональный комментарий!
          Фраза про производительность у меня вышла конечно корявенькая. Расшифрую.
          1) При генерации ключевой пары в RSA на основе пароля открытый ключ получится с весом приблизительно равным половине длины открытого ключа в битах. Это повлечет за собой увеличение нагрузки на сервер при проверке ЭЦП.
          2) Сама по себе генерация ключевой пары, проходящая на стороне клиента, в RSA более требовательна к производительности чем в ECC в связи с необходимостью проверки p и q на простоту.
          3) Так же на стороне клиента производится именно формирование подписи которая в RSA более требовательная к производительности чем проверка, а в ECC наоборот.
          Последние два пункта особенно заметно влияют на производительность в скриптовых языках на которых написан пример (javascript).
          • 0
            А существует ли такая вещь, как СКЗИ на ГОСТе с реализацией на JS? Чтобы генерировать юридически-значимую ЭЦП?
            • +2
              На сколько мне известно, это первая реализация чего либо ГОСТ-ового на JS. Сертифицировать же что-либо на JS, думаю не удастся, и соответсвенно юридической значимости не будет. Однако решение описанное здесь выполняет все операции на борту сертифицированного устройства, так-что его использование для построения юридически значимых систем возможно.
              • 0
                Не знал про это, классная вещь. Но это логин, а ЭЦП так можно сделать? И еще вопрос — Winda only?
                • 0
                  Евгений, разъясните пожалуйста почему не удастся сертифицировать что-либо чисто Webовское — JS/Flash/Silverlight? Интерес у многих большой, а у нас лицензия на подходе, думаем заняться попутно и этим.
                  • 0
                    Это мое субъективное мнение, основанное на общении с сертифицирующими органами. Если интересны web-решения ЭЦП, стоит обратить внимание на Рутокен Web.
                    • 0
                      Рутокен Web — это же только авторизация. Во всяком случае, из описания такое мнение складывается. Можно при помощи него, например, подписать содержимое текстового поля в форме не передавая закрытый ключ на сервер?
                      • 0
                        Можно и подписывать, и ключи сессионные вырабатывать. Аутентификация, это только вариант использования.
                        • +1
                          Если интересно, сделаю пример и выложу. Как только посвободнее буду.
                          • 0
                            Буду очень ждать.
                  • +1
                    Как раз сегодня попалась новость www.cryptopro.ru/cadesplugin/Welcome.aspx
                    • 0
                      То что нужно. Спасибо!
                      • 0
                        Хочу обратить внимание, для подписи по ГОСТ требуется установить КриптоПро CSP. Теряется идея доступности услуги из любого места.
                        • 0
                          Для доступа в интернет вам и браузер нужен. Поэтому хотите подпись надо СКЗИ.

                          Чтобы Токен с собой не носить можно ключевой контейнер экспортом куда нить в облака положить и при необходимости доставать для подписи.
                          • 0
                            Лицензия на КриптоПро CSP на одно рабочее место стоит 1800 рублей, например у меня три компьютера на которых я работаю. На каждую надо поставить CSP? а если вообще на чужом компьютере? Аппаратный токен с криптографией на борту мне более симпатичен.
                          • 0
                            Да, но сохраняется возможность создавать чисто Web кроссплатформенные приложения для внутреннего пользования, например энтерпрайз документооборот. К тому же, есть ноутбуки и удаленка. Хотя, с другой стороны, это таки минус.
                    • 0
                      Я не понял. 1. Где тут ЭЦП? 2. Зачем тут «RSA»? 3. Почему бы, если уж «RSA» и «SHA256(login+password)», не пользоваться потом обычной Digest аутентификацией из восстановленного пароля?

                      Да и вообще, зачем все это? Если так хочется что-то навелосипедить, можно прочитать сначала ISO/IEC 11770-* (4)
                      • +1
                        >Да и вообще, зачем все это?
                        Предложите лучше…
                        • 0
                          Без проблем. Какая модель угроз?
                          • +1
                            Задача озвучена в начале статьи — безопасная аутентификация по незащищенному каналу.
                            • 0
                              A -[ CONNECT ]-> B
                              A <-[ x = Random() ]- B
                              A -[ H(x' || H(pass')) ]-> B
                              A < — [ H(x' || H(pass')) == H(x || H(pass)) ]- B
                              • +1
                                Это вариант дайджест аутентификации, при которой база хранит хэш пароля. Кража бд позволит злоумышленнику аутентифицироваться вместо клиента зная только хэш пароля.
                                • +1
                                  Ну, поэтому я спросил про модель угроз. Аутентификация по незащищенному каналу не подразумевает, что база секретов доступна всем желающим )

                                  Лично моё мнение — сервер аутентификации надо физически отделять от клиентов. Как в моделях с керберосом.

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

                                  Варианты с асимметрией есть в упомянутом мной стандарте
                                  • 0
                                    Если вас беспокоят стандарты — погуглите «ISO public-Key Two-pass Unilateral Authentication Protocol»
                      • –1
                        > Почему до сих пор пароли передают в открытом виде? Почему хранят и пароли в БД в открытом виде или в виде хешей без соли?

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

                            1. Почему-то все равно не везде используется.
                            2. Без использования обоюдной аутентификации уязвима перед некоторыми атаками на инфраструктуру, в результате которой злоумышленник получает доступ к трафику в открытом виде.
                            • 0
                              1. Далеко не везде это необходимо.
                              2. Наверно потому и придумали HTTPS, не?
                              Если есть необходимость, то нужно использовать. Сейчас нет проблем чтобы взять VDS/VPS за копейки чтобы иметь возможность самостоятельно все настроить и не выкручиваться теми средствами что попали под руку. Хотя в общем обзор методов хорош, но я бы предпочел использовать готовые варианты.
                              • 0
                                Спасибо!
                                1. я имел ввиду аутентификацию.
                                2. уязвима односторонняя аутентификация, в случае когда сертификат есть у сервера, а у клиента нет. Именно она и используются в подавляющем большинстве случаев при аутентификации.
                                • 0
                                  Понял, вы имеете в виду аутентификацию сервера перед клиентом. В таком случае если это критично, используются сертификаты, подписанные центрами сертификации. Чтобы клиент мог быть уверен, что перед ним именно тот сервер, с которым он хочет общаться. Но это уже не бесплатное решение.
                                  • +2
                                    Даже используя подписанные сертификаты возможна атака MitM, например в корпоративной среде.
                              • 0
                                Какие атаки на инфраструктуру решает предложенный метод аутентификации?
                            • 0
                              В предложенной схеме нехватает привязки к промежутку времени.

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

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

                              Ключевая идея в алгоритме — это генерация пары открытый/закрытый ключ на лету на основе парольной фразы. Остальной механизм аутентификации можно сделать более стойким. см. Applied cryptography by Bruce Schneier.
                              • 0
                                Полагаю, возможность дождаться повторения 256-битного числа близка к возможности угадать секретный ключ.
                                Но вы абсолютно правы, это только пример!
                              • 0
                                Не очень понятно, для чего такая тяжёлая криптоартиллерия, если стойкость схемы определяется стойкостью пароля. Можно использовать и более простые схемы, вроде пробегавшего тут не так давно Лэмпорта.
                                • +1
                                  Данный методе некорректно сравнивать с HTTPS:
                                  Он решает задачу надёжной авторизации пользователей без затрат на разворачивание PKI на сервере.

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

                                  В этом методе (WebToken — да?) по сети передаётся только цифровая подпись, а на сервере хранится только публичный ключ, который можно хоть на сайте публиковать. Тру :)
                                • 0
                                  Да, кстати. Забыл добавить. При использовании такого метода аутентификации в веб форме не имеет смысла. Просто потому что я при активном MitM могу подгрузить заместь вашего js что угодно. Тут — только HTTPS.
                                  • 0
                                    Вот тут не могу не согласится :)
                                  • 0
                                    > Почему до сих пор пароли передают в открытом виде?
                                    очевидно скоро уже сделают реализацию md5 & sha самим браузером или встроенной функцией JS
                                    это сильно упростит жизнь и повысит быстродействие

                                    > Почему хранят и пароли в БД в открытом виде или в виде хешей без соли?
                                    ну, это не секрет — много дураков на белом свете
                                    лень матушка вперед нас родилась.
                                    • 0
                                      за статью спасибо.
                                      обязательно приму на вооружение
                                    • 0
                                      Мне лично больше нравится механизм 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-ключ генерирует и хранит только у себя, а передает лишь токены с цифровой подписью.
                                      • 0
                                        Мне тоже нравится механизм Oauth 1.0, но он не имеет отношения к аутентификации пользователей. Он используется для аутентификации приложений. Oauth 1.0 по сути очень похож на описанную выше схему, он использует подпись присланного запроса с помощью своего закрытого ключа прописанного в приложении. Этот ключ может быть полноценным RSA ключом (генерится владельцем приложения) или неким «паролем», который по сути тоже ключ (генерится на сервере и сообщается владельцу, по крайней мере так в Google).

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.