Comments 48
Имея на руках даже один раз перехваченные Login, RNDclient, RNDserver и ЭЦП, для атакующего все сведется опять к той же самой атаке на пароль по словарю или перебором.
«ECC криптографически более стойкая чем RSA, что позволяет использовать более короткие ключи, и как следствие, снижает требования к производительности.»
Некорректное утверждение про производительность.
1) ECC и RSA работают на разной математике. ECC использует более короткую длину ключей, но и сложность вычислений ECC для такой длины ключей существенно выше.
2) RSA может быть ускорен за счёт CRT, ECC может быть ускорен за счёт предвычислений.
3) У RSA операция на закрытом ключе (расшифровка/подпись) считается сложнее, чем на открытом (шифрования/проверка); у ECC проверка подписи в ~2 раза сложнее формирования и согласования ключа.
А ещё зависит от архитектуры вычислителя и т.п.
Некорректное утверждение про производительность.
1) ECC и RSA работают на разной математике. ECC использует более короткую длину ключей, но и сложность вычислений ECC для такой длины ключей существенно выше.
2) RSA может быть ускорен за счёт CRT, ECC может быть ускорен за счёт предвычислений.
3) У RSA операция на закрытом ключе (расшифровка/подпись) считается сложнее, чем на открытом (шифрования/проверка); у ECC проверка подписи в ~2 раза сложнее формирования и согласования ключа.
А ещё зависит от архитектуры вычислителя и т.п.
Спасибо, за профессиональный комментарий!
Фраза про производительность у меня вышла конечно корявенькая. Расшифрую.
1) При генерации ключевой пары в RSA на основе пароля открытый ключ получится с весом приблизительно равным половине длины открытого ключа в битах. Это повлечет за собой увеличение нагрузки на сервер при проверке ЭЦП.
2) Сама по себе генерация ключевой пары, проходящая на стороне клиента, в RSA более требовательна к производительности чем в ECC в связи с необходимостью проверки p и q на простоту.
3) Так же на стороне клиента производится именно формирование подписи которая в RSA более требовательная к производительности чем проверка, а в ECC наоборот.
Последние два пункта особенно заметно влияют на производительность в скриптовых языках на которых написан пример (javascript).
Фраза про производительность у меня вышла конечно корявенькая. Расшифрую.
1) При генерации ключевой пары в RSA на основе пароля открытый ключ получится с весом приблизительно равным половине длины открытого ключа в битах. Это повлечет за собой увеличение нагрузки на сервер при проверке ЭЦП.
2) Сама по себе генерация ключевой пары, проходящая на стороне клиента, в RSA более требовательна к производительности чем в ECC в связи с необходимостью проверки p и q на простоту.
3) Так же на стороне клиента производится именно формирование подписи которая в RSA более требовательная к производительности чем проверка, а в ECC наоборот.
Последние два пункта особенно заметно влияют на производительность в скриптовых языках на которых написан пример (javascript).
А существует ли такая вещь, как СКЗИ на ГОСТе с реализацией на JS? Чтобы генерировать юридически-значимую ЭЦП?
На сколько мне известно, это первая реализация чего либо ГОСТ-ового на JS. Сертифицировать же что-либо на JS, думаю не удастся, и соответсвенно юридической значимости не будет. Однако решение описанное здесь выполняет все операции на борту сертифицированного устройства, так-что его использование для построения юридически значимых систем возможно.
Не знал про это, классная вещь. Но это логин, а ЭЦП так можно сделать? И еще вопрос — Winda only?
Евгений, разъясните пожалуйста почему не удастся сертифицировать что-либо чисто Webовское — JS/Flash/Silverlight? Интерес у многих большой, а у нас лицензия на подходе, думаем заняться попутно и этим.
Это мое субъективное мнение, основанное на общении с сертифицирующими органами. Если интересны web-решения ЭЦП, стоит обратить внимание на Рутокен Web.
Как раз сегодня попалась новость www.cryptopro.ru/cadesplugin/Welcome.aspx
То что нужно. Спасибо!
Хочу обратить внимание, для подписи по ГОСТ требуется установить КриптоПро CSP. Теряется идея доступности услуги из любого места.
Для доступа в интернет вам и браузер нужен. Поэтому хотите подпись надо СКЗИ.
Чтобы Токен с собой не носить можно ключевой контейнер экспортом куда нить в облака положить и при необходимости доставать для подписи.
Чтобы Токен с собой не носить можно ключевой контейнер экспортом куда нить в облака положить и при необходимости доставать для подписи.
Да, но сохраняется возможность создавать чисто Web кроссплатформенные приложения для внутреннего пользования, например энтерпрайз документооборот. К тому же, есть ноутбуки и удаленка. Хотя, с другой стороны, это таки минус.
Я не понял. 1. Где тут ЭЦП? 2. Зачем тут «RSA»? 3. Почему бы, если уж «RSA» и «SHA256(login+password)», не пользоваться потом обычной Digest аутентификацией из восстановленного пароля?
Да и вообще, зачем все это? Если так хочется что-то навелосипедить, можно прочитать сначала ISO/IEC 11770-* (4)
Да и вообще, зачем все это? Если так хочется что-то навелосипедить, можно прочитать сначала ISO/IEC 11770-* (4)
>Да и вообще, зачем все это?
Предложите лучше…
Предложите лучше…
Без проблем. Какая модель угроз?
Задача озвучена в начале статьи — безопасная аутентификация по незащищенному каналу.
A -[ CONNECT ]-> B
A <-[ x = Random() ]- B
A -[ H(x' || H(pass')) ]-> B
A < — [ H(x' || H(pass')) == H(x || H(pass)) ]- B
A <-[ x = Random() ]- B
A -[ H(x' || H(pass')) ]-> B
A < — [ H(x' || H(pass')) == H(x || H(pass)) ]- B
Это вариант дайджест аутентификации, при которой база хранит хэш пароля. Кража бд позволит злоумышленнику аутентифицироваться вместо клиента зная только хэш пароля.
Ну, поэтому я спросил про модель угроз. Аутентификация по незащищенному каналу не подразумевает, что база секретов доступна всем желающим )
Лично моё мнение — сервер аутентификации надо физически отделять от клиентов. Как в моделях с керберосом.
Но если уж так ставить вопрос, то да. Нужна асимметрия. Но тут важно понимать такой нюанс. Если это производные *DSA, то есть капитальный риск засветить свой личный ключ, при дурацких реализациях схемы.
Варианты с асимметрией есть в упомянутом мной стандарте
Лично моё мнение — сервер аутентификации надо физически отделять от клиентов. Как в моделях с керберосом.
Но если уж так ставить вопрос, то да. Нужна асимметрия. Но тут важно понимать такой нюанс. Если это производные *DSA, то есть капитальный риск засветить свой личный ключ, при дурацких реализациях схемы.
Варианты с асимметрией есть в упомянутом мной стандарте
> Почему до сих пор пароли передают в открытом виде? Почему хранят и пароли в БД в открытом виде или в виде хешей без соли?
Скорее всего, потому что глупый SASL
Скорее всего, потому что глупый SASL
Я не совсем понял что мешает использовать пресловутый SSL.
Зачем использовать небезопасное соединение и потом мучиться оттого что оно небезопасное? Критические данные на сервисе, где безопасность прежде всего, должны передаваться через https и не только пароли, но и данные из GET, POST.
Зачем использовать небезопасное соединение и потом мучиться оттого что оно небезопасное? Критические данные на сервисе, где безопасность прежде всего, должны передаваться через https и не только пароли, но и данные из GET, POST.
https очень хорошая технология, по возможности ее лучше использовать, но…
1. Почему-то все равно не везде используется.
2. Без использования обоюдной аутентификации уязвима перед некоторыми атаками на инфраструктуру, в результате которой злоумышленник получает доступ к трафику в открытом виде.
1. Почему-то все равно не везде используется.
2. Без использования обоюдной аутентификации уязвима перед некоторыми атаками на инфраструктуру, в результате которой злоумышленник получает доступ к трафику в открытом виде.
1. Далеко не везде это необходимо.
2. Наверно потому и придумали HTTPS, не?
Если есть необходимость, то нужно использовать. Сейчас нет проблем чтобы взять VDS/VPS за копейки чтобы иметь возможность самостоятельно все настроить и не выкручиваться теми средствами что попали под руку. Хотя в общем обзор методов хорош, но я бы предпочел использовать готовые варианты.
2. Наверно потому и придумали HTTPS, не?
Если есть необходимость, то нужно использовать. Сейчас нет проблем чтобы взять VDS/VPS за копейки чтобы иметь возможность самостоятельно все настроить и не выкручиваться теми средствами что попали под руку. Хотя в общем обзор методов хорош, но я бы предпочел использовать готовые варианты.
Спасибо!
1. я имел ввиду аутентификацию.
2. уязвима односторонняя аутентификация, в случае когда сертификат есть у сервера, а у клиента нет. Именно она и используются в подавляющем большинстве случаев при аутентификации.
1. я имел ввиду аутентификацию.
2. уязвима односторонняя аутентификация, в случае когда сертификат есть у сервера, а у клиента нет. Именно она и используются в подавляющем большинстве случаев при аутентификации.
Какие атаки на инфраструктуру решает предложенный метод аутентификации?
В предложенной схеме нехватает привязки к промежутку времени.
MitM может перехватывать RNDserver и запоминать соответствующие Sign(SHA256(RNDserver+RNDclient)).
Через некоторое время он накопит достаточное количество RNDServer и будет осуществлять попытки пройти аутентификацию перед сервером. Как только он получит известный ему RNDServer, он достанет из базы подписанный ответ и войдёт в систему.
Разумеется вероятность взлома зависит количества возможных RNDserver и от фазы луны. Но мы имеем дело с точной наукой и такого фейла можно избежать.
Ключевая идея в алгоритме — это генерация пары открытый/закрытый ключ на лету на основе парольной фразы. Остальной механизм аутентификации можно сделать более стойким. см. Applied cryptography by Bruce Schneier.
MitM может перехватывать RNDserver и запоминать соответствующие Sign(SHA256(RNDserver+RNDclient)).
Через некоторое время он накопит достаточное количество RNDServer и будет осуществлять попытки пройти аутентификацию перед сервером. Как только он получит известный ему RNDServer, он достанет из базы подписанный ответ и войдёт в систему.
Разумеется вероятность взлома зависит количества возможных RNDserver и от фазы луны. Но мы имеем дело с точной наукой и такого фейла можно избежать.
Ключевая идея в алгоритме — это генерация пары открытый/закрытый ключ на лету на основе парольной фразы. Остальной механизм аутентификации можно сделать более стойким. см. Applied cryptography by Bruce Schneier.
Не очень понятно, для чего такая тяжёлая криптоартиллерия, если стойкость схемы определяется стойкостью пароля. Можно использовать и более простые схемы, вроде пробегавшего тут не так давно Лэмпорта.
Данный методе некорректно сравнивать с HTTPS:
Он решает задачу надёжной авторизации пользователей без затрат на разворачивание PKI на сервере.
Зато метод можно сравнить с Digest Auth.
Для последнего, пароль на сервере должен храниться в открытом виде, а это просто уничтожает преимущество того, что пароль не передаётся по сети. Как только злоумышленник получит доступ к серверу — сразу все пользователи скомпрометированы. Не айс.
В этом методе (WebToken — да?) по сети передаётся только цифровая подпись, а на сервере хранится только публичный ключ, который можно хоть на сайте публиковать. Тру :)
Он решает задачу надёжной авторизации пользователей без затрат на разворачивание PKI на сервере.
Зато метод можно сравнить с Digest Auth.
Для последнего, пароль на сервере должен храниться в открытом виде, а это просто уничтожает преимущество того, что пароль не передаётся по сети. Как только злоумышленник получит доступ к серверу — сразу все пользователи скомпрометированы. Не айс.
В этом методе (WebToken — да?) по сети передаётся только цифровая подпись, а на сервере хранится только публичный ключ, который можно хоть на сайте публиковать. Тру :)
Да, протокол аутентификации тот же, что и при использовании аппаратного токена — http://habrahabr.ru/blogs/web_security/120990/.Только криптография реализована программно.
Да, кстати. Забыл добавить. При использовании такого метода аутентификации в веб форме не имеет смысла. Просто потому что я при активном MitM могу подгрузить заместь вашего js что угодно. Тут — только HTTPS.
> Почему до сих пор пароли передают в открытом виде?
очевидно скоро уже сделают реализацию md5 & sha самим браузером или встроенной функцией JS
это сильно упростит жизнь и повысит быстродействие
> Почему хранят и пароли в БД в открытом виде или в виде хешей без соли?
ну, это не секрет — много дураков на белом свете
лень матушка вперед нас родилась.
очевидно скоро уже сделают реализацию 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-ключ генерирует и хранит только у себя, а передает лишь токены с цифровой подписью.
Клиент к каждому 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).
Sign up to leave a comment.
Аутентификация на базе ЭЦП