Pull to refresh

Comments 48

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

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

Да и вообще, зачем все это? Если так хочется что-то навелосипедить, можно прочитать сначала 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
Это вариант дайджест аутентификации, при которой база хранит хэш пароля. Кража бд позволит злоумышленнику аутентифицироваться вместо клиента зная только хэш пароля.
Ну, поэтому я спросил про модель угроз. Аутентификация по незащищенному каналу не подразумевает, что база секретов доступна всем желающим )

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

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

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

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

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

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

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

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

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

В этом методе (WebToken — да?) по сети передаётся только цифровая подпись, а на сервере хранится только публичный ключ, который можно хоть на сайте публиковать. Тру :)
Да, кстати. Забыл добавить. При использовании такого метода аутентификации в веб форме не имеет смысла. Просто потому что я при активном MitM могу подгрузить заместь вашего js что угодно. Тут — только HTTPS.
> Почему до сих пор пароли передают в открытом виде?
очевидно скоро уже сделают реализацию 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-ключ генерирует и хранит только у себя, а передает лишь токены с цифровой подписью.
Мне тоже нравится механизм Oauth 1.0, но он не имеет отношения к аутентификации пользователей. Он используется для аутентификации приложений. Oauth 1.0 по сути очень похож на описанную выше схему, он использует подпись присланного запроса с помощью своего закрытого ключа прописанного в приложении. Этот ключ может быть полноценным RSA ключом (генерится владельцем приложения) или неким «паролем», который по сути тоже ключ (генерится на сервере и сообщается владельцу, по крайней мере так в Google).
Only those users with full accounts are able to leave comments. Log in, please.