Идентификация и аутенцтификация с веб-страницы

http://www.vladmiller.info/blog/index.php?comment=61
А вообще, конечно, лучше используйте взаимную SSL-аутентификацию (аналогично аутентификации в WebMoney Keeper Light). С WebMoney Keeper Classic история немного иная — используется компонент ActiveX, — поскольку ключ аутентификации пользователя передаётся из стороннего приложения.

почитал Ваш блог. Хотелось бы узнать по подробнее про ActiveX авторизацию. Какую строку я должен подписывать своими ключами и тому подобное. Допустим, если я буду подписывать фиксированную строку, то достаточно перехватить ее злоумышленнику и он сможет ее использовать всегда. как обеспечить должный уровень защиты ? (данные передаем по SSL каналу, но без идентификации клиента с помощью сертификата. Сертификат только у сервера будет, чтобы ему можно было доверять).

Если у Вас есть SSL, зачем Вам ActiveX или подписывание каких-то строк? (ActiveX вообще нужен только в том случае, когда Вы реализуете какие-то нестандартные функции по объединению данных от локальных приложений пользователя и веб-содержимого сайта; к тому же вся эта кухня будет работать только в Internet Explorer.)

Т.е. я предполагаю, что у Вас есть некий веб-сайт, на котором пользователь должен авторизоваться, чтобы подтвердить свои полномочия (допустим, интернет-магазин). Если есть поддержка SSL, пользователь просто открывает страницу авторизации по протоколу HTTPS, вводит своё имя и пароль в форму и вводит эти данные на сервер. Благодаря SSL они будут переданы в зашифрованном виде. SSL обеспечивает шифрование на уровне транспортного протокола, поэтому Ваши веб-приложения во многих случаях даже не будут догадываться, что данные передаются в защищённом виде.

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

Если Вам требуется что-то другое, формализуйте свою задачу или приведите больше деталей.

Т.е. я предполагаю, что у Вас есть некий веб-сайт, на котором пользователь должен авторизоваться, чтобы подтвердить свои полномочия (допустим, интернет-магазин). Если есть поддержка SSL, пользователь просто открывает страницу авторизации по протоколу HTTPS, вводит своё имя и пароль в форму и вводит эти данные на сервер. Благодаря SSL они будут переданы в зашифрованном виде. SSL обеспечивает шифрование на уровне транспортного протокола, поэтому Ваши веб-приложения во многих случаях даже не будут догадываться, что данные передаются в защищённом виде.

изначально задача немного не такая. у пользователя есть ключи (собственно сгенерированные), необходимо организовать его идентификацию с помощью этих ключей. SSL испльзуется только в качестве шифрования данных в канале, но не как механизм идентификации. пока использование сертификатов SSl не предполагается. можете ли подсказать, как подобное реализовать. пример использования – Web Money Keeper Classic. Мне не понятно, что между ActiveX и сервером передается и что подписывать этими ключами.

изначально задача немного не такая. у пользователя есть ключи (собственно сгенерированные)

Какие ключи: симметричные или асимметричные? Есть ли у сервера копия этих ключей?

Вся документация по протоколу WebMoney есть на официальном сайте.

Какие ключи: симметричные или асимметричные? Есть ли у сервера копия этих ключей?

ключи ассиметричные, на сервере есть открытый ключ клиента.

Вся документация по протоколу WebMoney есть на официальном сайте.

по внутреннему устройству? Я не видел. поищу, но, если Вам не сложно, киньте ссылочку.

Добавлю еще вот что. Целесообразно ли применение не ActixveX, а использование, например, программы типа Кипера и в ней функции, скопировать ключ для входа (тут у нас в буффер копируется строка некоторая, подписанная, о которой я у Вас спрашиваю :)) пользователь ее вставляет в текстовое поле и мы входим. Немного накладнее, однако, если учесть, что опыта работы с COM / ACtiveX у меня нет, времени на разработку потрачу меньше.

к слову, посмотрел исходники подписывающего модуля WebMoney (не тот, что ActiveX, а просто их библиотеку), они используют MD4, насколько я понял.

Допускаю, что открытый ключ на сервер попадает безопасным путём (короче, что его перехват Вы исключили). Тогда передайте клиенту на подпись простой порядковый номер аутентификации и текущую метку времени (конечно, по SSL). Я не вдаюсь в детали Вашей реализации асимметричной криптосистемы и надеюсь, что она защищена от тривиальных атак.

Допускаю, что открытый ключ на сервер попадает безопасным путём (короче, что его перехват Вы исключили).

чем может грозить перехват открытого ключа? Ведь его содержимое не является секретным.

Тогда передайте клиенту на подпись простой порядковый номер аутентификации и текущую метку времени (конечно, по SSL).

нО, ведь время у сервера может быть другое, нежели у клиента. я подумываю о том, чтобы запрашивать у сервера некоторую строку, GUID – индентификатор сессии, что ли. Который остается валидным для входа некоторый промежуток времени. Затем я подписываю его + еще некоторое число (увеличивающееся при каждой операции), защищающее от прямого дублирования пересылаемой информации. И передаю это дело на сервер. На сервере происходит индентификация и авторизация, а данная строка входа становится не валидной. Если в течении времени жизни, GUID был отослан, но не подписан, мы с ним прощаемся – сессия для входа умирает (на сервере).

Я не вдаюсь в детали Вашей реализации асимметричной криптосистемы и надеюсь, что она защищена от тривиальных атак.

Что имеется в виду под "тривиальными" ?

спасибо за обсуждение, Вы мне здорово помагаете!

Еще хотелось бы услышать мнение по поводу

использование, например, программы типа Кипера и в ней функции, скопировать ключ для входа (тут у нас в буффер копируется строка некоторая, подписанная, о которой я у Вас спрашиваю :)) пользователь ее вставляет в текстовое поле и мы входим.

Насколько хуже, что мы получаем доступ к строке для входа.

чем может грозить перехват открытого ключа? Ведь его содержимое не является секретным.

Это грозит тем, что ключ может быть подменён для последующего проведения атаки "человек посередине".

я подумываю о том, чтобы запрашивать у сервера некоторую строку, GUID – индентификатор сессии, что ли.

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

Что имеется в виду под «тривиальными» ?

Это и т.п.

Еще хотелось бы услышать мнение по поводу
<...>
Насколько хуже, что мы получаем доступ к строке для входа

Не хуже, я бы сделал именно так. Конечно, если требуется автоматизировать процесс авторизации, придётся писать какой-то клиентский модуль, будь то на javascript, AcriveX или чём-то ещё.

Спасибо, содержательно!

Это грозит тем, что ключ может быть подменён для последующего проведения атаки «человек посередине».

Можно ли этого избежать, используя для сайта сертификат SSL? И как правильно организовать защиту?

В принципе, да, наличие SSL позволяет избежать такой подмены, доверие к ключу в этом случае устанавливается опосредованно через механизм подтверждения X.509 (желательно, конечно, иметь не самоподписанный SSL-сертификат для такой цели). Т.е., предположим, клиент генерирует на своей стороне пару закрытый/открытый ключ, заходит на страницу сайта, защищённую соединением SSL, через веб-форму загружает открытый ключ на сервер (вероятно, в процессе регистрации), а в дальнейшем использует свой закрытый ключ для авторизации.

У меня в системе предполагалось не защищать особенно сильно открытый ключ клиента. то есть он может быть доступен злоумышленнику, но у нас он гарантированно верный – заверяется лично клиентом.
Кстати, на лекции по безопасности сказали, что 1024 битный ключ RSA – недостаточно. Если предполагается ключи системы использовать достаточно долго – несколько лет, лучше сделать ключи 2048 бит, чтобы потом их не менятЬ?

доверие к ключу в этом случае устанавливается опосредованно через механизм подтверждения X.509

а где про это можно подробнее почитать?

снова запутался совсем =) для использования в SSL и подписи данных в канале (программных, не на уровне протокола) я должен использовать один и тот же ключ системы? Или могу разные, или это не красиво?