15 ноября, четверг 19:35
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

"Новость" RSN на BugTraq.Ru об ошибке в iBank 2.0.1.4

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • "Новость" RSN на BugTraq.Ru об ошибке в iBank 2.0.1.4

    Уважаемые участники форума!

    В Russian Security Newsline, издаваемой Дмитрием Леоновым - dl@bugtraq.ru - на сайте BugTraq.Ru появилась "новость" с интригующим названием "Уязвимость iBank 2.0.1.4" - http://bugtraq.ru/rsn/. Текст "новости" следующий:

    В последней версии iBank 2.0.1.4 компании БИФИТ (www.bifit.ru) со сторонней криптографией, при недобросовестности администратора банка, существует возможность исполнения на машине клиента неподписанного кода с правами подписанного без каких-либо уведомлений пользователя.

    "Отравленный" код будет исполняться с правами и от имени браузера (или его JVM) и соответственно не будет заблокирован/отслежен большинством firewall'ов и антитроянов.

    Эта ошибка позволяет легко и незаметно захватить машину даже опытного пользователя с грамотно поставленной защитой.

    В новой версии iBank 2.1.0.5 ошибка устранена: http://www.bifit.com/s-download.html
    Новость составлена на основе цитат из письма Александра Комлина, также размещенного на сайте BugTraq.Ru - http://www.bugtraq.ru/cgi-bin/forum....b&b=15&m=50191

    Наши комментарии к рассуждениям Александра Комлина о наличие ошибки мы опубликовали там же, на форуме багтрэка - http://www.bugtraq.ru/cgi-bin/forum....b&b=15&m=50536

    В тоже время я считаю необходимым кроме комментария к письму г-на Комлина сделать заявление к появившейся "новости" в RSN.

    Размещенная на сайте BugTraq.Ru новость - http://www.bugtraq.ru/rsn/archive/2002/06/14.html - об обнаружении уязвимости в системе iBank 2 при использовании внешнего СКЗИ является тенденциозной, явно носит "жареный" характер, и что самое печальное - не соответствует действительности.

    Чуть менее недели назад я в личной переписке комментировал Александру Комлину ситуацию с использованием в iBank 2 ПБЗИ "Базис-защита". Я считал, что мне удалось донести до Александра необоснованность его выводов, ибо исходные данные, от которых отталкивался г-н Комлин, были ошибочны (по всей видимости из-за поверхностного ознакомления с системой, из-за горячности и скорополительности эксперта, а также из-за, к сожалению, явного недостатка квалификации в нюансах Java-security).

    Позиция компании "БИФИТ" всегда была, есть и будет открытой в отношении вопросов информационной безопасности разрабатываемого нами банковского ПО. Мы всецело приветствуем и поддерживаем проведение независимых исследований наших разработок. Более того, мы постоянно привлекаем сторонних специалистов для проведения независимых экспертиз.

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

    То, что приемлемо и полезно с пиаровской точки зрения для фришных интернет-сервисов и шароварных программ, совершенно недопустимо для сферы финансового ПО. Подобные жаренные и всесторонне непроверенные новости в секторе банковского ПО чреваты колосальными убытками для пользоваталей этих решений.

    Что если завтра какой-нибудь большой и серьезный клиент не менее серьезного банка позвонит в свой банк, и не разобравшись в сути вопроса, а также используя подобную непроверенную жаренную новость всего лишь как повод, заявит о своем уходе из этого банка, и последний потеряет гарантированно зарабатываемые ххх k$ в месяц на этом клиенте? Что тогда? Ведь люди работают, трудятся....

    "Новость" об уязвимости iBank 2.0.1.4, абсолютно не соответствующая действительности, вдобавок была изложена в стиле ответственного редактора газеты "Утренняя Заря и Боевой Клич округа Джонсон" из знаменитого рассказа Марка Твена "Журналистика в Теннесси" - http://www.twain.narod.ru/ten.htm

    BugTraq.Ru пользуется заслуженным уважением, портал посещает большое количество IT-специалистов, работающих в том числе и в банковской сфере. Подобная жаренная "новость" нам и нашим клиентам точно в минус. В очень большой минус. К сожалению, далеко не все будут разбираться в перепетиях и тонкостях, в рассуждениях эксперта и в комментариях разработчика. И очень многие вынесут только негатив из этой новости, собранной из фраз бурного и эмоционального письма г-на Комлина.

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

    Единственным корректным выходом является размещение в новостях RSN официального опровержения.

    С уважением, Репан Димитрий
    Исполнительный директор компании "БИФИТ" - www.bifit.com
    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com

  • #2
    И очень многие вынесут только негатив из этой новости, собранной из фраз бурного и эмоционального письма г-на Комлина.

    Просто вы опять наступили на те же грабли, на которые наступали два
    года назад (когда подписывали апплет "отладочными ключами"). Сейчас даже ими dll-ны не подписаны. За что вы и преданы анафеме. История повторяется.

    добавлю: беда в том, что до сих пор нет профайла безопасности иБанка.
    Если бы он был, у ловцов блох (баг трэкеров), не возникло бы вопросов в том,
    что администратор может украсть ключи клиента и отправить платеж
    от имени клиента. Просто в профайле следовало бы честно написать:
    систма не защищает от администратора и тд тп.
    Последний раз редактировалось sharpcat; 13.06.2002, 14:03.
    WBR
    serg

    Комментарий


    • #3
      Сергей, в отличие от порнографических помоек, банк по определению является доверенным источником банковского ПО, предоставляемого клиентам (не важно - экзешники это, HTML-странички, нативные библиотеки, конфигурационные файлы или же Java-апплеты ).

      И если стоит задача защиты клиентов банка от нелояльного банковского сисадмина, формирующего к примеру дистрибутив для клиента, достаточно обычных организационных мер.

      следовало бы честно написать: систма не защищает от администратора и тд тп.
      Сергей, при корректной эксплуатации ПО проблемы защиты от администратора не возникает. Если администратор в твоем банке заведомо засланный казачек, если администратор раздает вместо положенного дистрибутива с сертифицированным ФАПСИ СКЗИ левый софт с закладкой - это уже внутренние организационные проблемы твоего банка. За это - лишают Лицензий ФАПСИ. И в этом вопросе не помогут ни сертификаты, ни подписи - только организационные меры.
      С уважением, Репан Димитрий
      Компания "БИФИТ" - www.bifit.com

      Комментарий


      • #4
        Сергей, в отличие от порнографических помоек, банк по определению является доверенным источником банковского ПО, предоставляемого клиентам

        никогда не был на порнографических помойках... сложно сравнивать


        И если стоит задача защиты клиентов банка от нелояльного банковского сисадмина, формирующего к примеру дистрибутив для клиента, достаточно обычных организационных мер.

        я не против организационных мер. я хочу сказать о том, что если бы у вас был
        опубликован профайл защиты, те, что и каким образом от чего защищено и что не защищено, то никто бы не стал ломиться в открытую дверь и писать, что
        администратор - источник угрозы безопасности. Администратор, как я понял,
        у вас изначально вне списка угроз.
        Тогда бы не возникало лишних вопросов.
        WBR
        serg

        Комментарий


        • #5
          Об ошибке.

          Если исходить не из краткого описания RSN, а из оригинального постинга, Комлина в программе(апплете) iBank имелась недокументированная возможность по подключению внешний библиотеки (ошибки ? 3) неизвестного происхожения для подписи сообщений (эта дырка Вами тактично названа "фичей"). Эта операция незаметна для жертвы (никто из бухгалтеров не просматривает HTMLины на предмет дополнительной строчки ARCHIVE). Эта ошибка того же плана, что и найденная год назад Лан Крипто.
          Ш) Схема подключения библиотек криптоалгоритмов, задаваемая внешними файлами храняшимися на сервере, позволяет непорядочному сотруднику банка заменить стандартные библиотеки генерации ключей и подписи данных на свою собственную. Эта операция весьма трудоёмка, но вполне реальна, с учётом, что за основу можно взять открытые оригинальные библиотеки изменив их лишь в деталях. Для её реализации в параметр ARCHIVE тега апплета файла makekeys.htm (client.htm) добавляется ещё один архив (неподписанный), и меняется наименование библиотеки в xml-файле.

          Атака возможна в отношении апплетов client.jar и makekeys.jar

          *-*-*-*-*-*-*-*-*
          *.htm
          APPLET
          ...
          ARCHIVE=..., badprovider.jar
          ...

          Класс провайдера задаётся вызовом Class.forName(s1)
          Security.addProvider((Provider)Class.forName(s1).newInstance());
          s1 берётся из *transport.xml
          -*-*-*-*-*-*-*-*
          CryptoEngine>
          Security provider="com.bifit.security.provider.AncortApplet" />
          Последний оператор можно заменить например на
          Security provider="badcom.FalseApplet" />

          (класс badcom.FalseApplet находится в библиотеке badprovider.jar ).

          По утверждению разработчиков эта ошибка устранена в новых версиях продуктов Бифит, но на сервере bifit.com пока лежит уязвимый вариант.
          Ответ:
          Я уже не раз в своих письмах упоминал, что ДОВЕРИЕ КЛИЕНТА В БАНКОВСКОМУ ПО - НЕОБХОДИМОЕ УСЛОВИЕ ДЛЯ РАБОТЫ СИСТЕМЫ.

          (выпущено)

          На самом деле изначально возможность банка самостоятельно подключать к iBank 2 внешние криптобиблиотеки, полностью соответствующие спецификациям JCA и JCE, была ФИЧЕЙ, а не багом.

          То есть раньше банк самостоятельно мог определить какие СКЗИ использовать в своем конкретном случае и переопределять это по мере необходимости. Подобные возможности присутствуют в подавлающем большинстве решений Б-К и И-Б.
          Где гарантия, что банк подключит надёжную библиотеку и известит об этом клиентов, а не свою собственную, где ключи вычисляются по неслучайной формуле? Из предыдущих сообщений Комлина известно, что достаточно предсказуемости параметров подписи (случайного ключа) и подпись уже можно подобрать?

          Из Ваших соображений в ответе Комлину, следует: "пользователь iBank должен полностью доверять порядочности банка". Это детский лепет. Любому, кто попробует довести его до логического конца, становится ясно, что Ваш продукт в этом случае не нужен.

          Для чего нужна сложная и трудоёмкая технология ЭЦП, если банку не составляет труда узнать секретный ключ её пользователя?
          Напишите честно, что Вы выпускаете программу для обмена информации с банком, так как методы по его защите у Вас - формальность. Но тогда придётся снизить цену, не так ли?
          Ремарка: на этом фоне проблемы распространения библиотеки ПБЗИ "Базис-защита" выглядят мелким укусом. Непонятно зачем было её упоминать.

          О последствиях

          Опять двадцать пять! Вместо перегенерации ключей и отзыва сертификата тихо выпускается новая версия. Смысл? Во-первых ключи уже могли быть украдены. Во-вторых на руках в банках дырявый апплет с Вашей подписью. Его по-прежнему можно использовать для подмены алгоритма подписи

          О лицемерии

          Цитата из RSN


          Уважаемый Александр!

          Я искренне рад, что наше решение для Интернет-Банкинга - система iBank 2 - привлекает внимание независимых экспертов и специалистов в области информационной безопасности. В любом случае независимые исследования части или всего решения, глубоко до самых корней или не очень, никогда не бывают лишними.

          Я также благодарен Вам за предоставленную нам возможность предварительно, до публикации, ознакомиться с материалами и результатами Вашего исследования.

          Успехов Вам, Александр!
          Цитата отсюда


          явление к появившейся "новости" в RSN.

          Размещенная на сайте BugTraq.Ru новость - http://www.bugtraq.ru/rsn/archive/2002/06/ 14.html - об обнаружении уязвимости в системе iBank 2 при использовании внешнего СКЗИ является тенденциозной, явно носит "жареный" характер, и что самое печальное - не соответствует действительности.

          Чуть менее недели назад я в личной переписке комментировал Александру Комлину ситуацию с использованием в iBank 2 ПБЗИ "Базис-защита". Я считал, что мне удалось донести до Александра необоснованность его выводов, ибо исходные данные, от которых отталкивался г-н Комлин, были ошибочны (по всей видимости из-за поверхностного ознакомления с системой, из-за горячности и скорополительности эксперта, а также из-за, к сожалению, явного недостатка квалификации в нюансах Java-security).
          Почему-то все, кто имел честь указать г. Репану на его ошибки становятся некомпетентными наймитами врагов.


          Ремарка: Через неделю выяснится, что нерасторопные автоматизаторы очередного банка забыли забрать у Комлина их версию договора

          Аналитик

          Комментарий


          • #6

            import Ланкритпо.Русскриптою.Волчков.*;
            class Aналитик extends Cryptolog implements Le_Colonel;

            Комментарий


            • #7
              Тяжело и грустно общаться с анонимами.

              Сначала был сумбурный Cryptolog, потом не менее беззаботный Le Colonel. Теперь просто Аналитик. И каждый не применул припечатать БИФИТ, вспомнить все тонкости прошлогоднего скандала и при этом лестно отозваться о всеми "любимой" компании "ЛАН Крипто". В общем "случайность - частный случай - закономерность...."

              Но давайте попробуем возразить г-ну Аналитику. Итак, затронута возможность банка самостоятельно выбирать и менять СКЗИ для работы с iBank'ом 2.

              Если уважаемый Аналитик соизволит ознакомиться с функциональными возможностями подобных iBank'у коммерческих продуктов (а не нести околесицу о ценах, сменах и прочем), а также ознакомиться с классическими толстыми Банк-Клиентами, то он с большим удивлением обнаружит практически в каждой программе подобный "баг" - возможность банка самостоятельно выбирать СКЗИ и настраивать прикладное решение

              В одних программах это будет вызов внешнего исполняемого файлика с СКЗИ с настраиваемым именем и передаваемыми параметрами, в других - выбор из самостоятельно расширяемого банком списка СКЗИ. Для любителей СКЗИ от ЛАН Крипто можно кстати посмотреть КАК ВЫЗЫВАЮТСЯ криптографические функции в прикладных продуктах, пока еще использующих указанные СКЗИ.

              Более того, Аналитик с еще бОльшим удивлением обнаружит практически уже во всех толстых решениях типа Банк-Клиент возможность автоматического удаленного обновления установленного у клиента ПО, включая СКЗИ, конфигурационные файлы и т.д. по инициативе Банка (банковского IT-сотрудника).

              Возможность дистанционно, по инициативе банка обновлять клиентское ПО, включая СКЗИ и транспорт - необходимое условие для любого решения, ориентированного на массовое обслуживание. И естественно бразды правления сим процессом всецело лежат на банке и только на банке. Никто кроме банка не должен поставлять и уж тем более дистанционно обновлять клиенту банковское ПО.
              С уважением, Репан Димитрий
              Компания "БИФИТ" - www.bifit.com

              Комментарий


              • #8
                Почему все так упёрлись именно в непорядочность администратора. А сам банк не может пожелать безнаказанно кинуть клиента?

                2 Димитрий
                г-на Комлина... а также из-за, к сожалению, явного недостатка квалификации в нюансах Java-security)
                Забавное утверждение. До сих пор считалось наоборот.
                См. например его статью трёхлетней давности:

                http://hackzone.ru/articles/netscape2.html

                Если это недостаток квалификации, то что же считать достаточным?

                возможность автоматического удаленного обновления установленного у клиента ПО, включая СКЗИ, конфигурационные файлы и т.д. по инициативе Банка (банковского IT-сотрудника).
                Есть пара вопросов:
                Разве при таком обновлении не предусмотрен
                никакой контроль целостности?
                Согласия на online установку не требуется и даже не выдаётся предупреждения?
                Пользователь не имеет возможность выбрать обновление установленным способом (на CD или дискетах)?

                В известном мне "Банк-Клиенте" (не буду называть его) дело обстоит именно так. ПО пользователя не может быть изменено без его согласия и он сам выбирает способ получения обновления.


                С Уажением Наталья

                Комментарий


                • #9
                  2 All

                  Забавно смотреть, как повторяется ситуация на новом витке развития. Мне например уже давно ясен способ "ведения дел" в БИФИТЕ, и modus operandi Димитрия.
                  Компания выбрасывает на рынок "самый передовой и технологичный продукт" с самым "большим и продвинутым количеством дырок", который стыдливо называет багами и фичами. По количеству версий и заплаток, БИФИТ отстает пожалуй только от Microsoft. Агресивный маркетинг сочетается с низкой технической культурой разработчиков и отсутствием культуры ведения цивилизованной дискуссии у руководетелей компании.
                  Собственно говоря, посмотрев старые постинги, можно прочесть мое высказывание - "любой анализ симптоматичен", редко, найдя одну дыру в продукте, можно говорить о том, что в "остальном прекрасная маркиза все хорошо...". Именно это и было продемонстрировано в прошлом году - две дырки в одном месте, причем вторая после "ликвидации бага" (согласно словам Димиртия).
                  Я думаю, что читатели уже очень хорошо освоили основные способы "контрпропаганды по Димитрию".
                  1. Выдвинуть аргументы не относящиеся к делу. (В данном случае аппеляции к отзыву у банка лицензии ФАПСИ - вот банк напугается и сразу станети честным).
                  2. Подменить тему дискусии (очень Димитрий любит организационные меры и постояноо аппелирует к тому, что дырявая криптография и защита компенсируется оргмерами).
                  3. Обвинить противника во всех грехах (некомпетентности, нечистоплотности, предвзятости, ангажированности и т.д.)
                  4. Перевести разговор на личности, зачислить критиков в стан личных врагов.
                  5. Выпустить на следующий день после обнаружения дыры в продажу версию номер x.y.z., объявить ее окончательно защищенной, заметить по ходу дела, что взломанная версия вовсе и не продавалась, а так просто на "сайте лежала".

                  Цель простая - отвлечь внимание от истинной причины возникновения дискусии, которую в целом можно сформулировать так - "отсутствие технологически продуманной системы безопасности в системе iBank.

                  С уважением
                  Алексей Волчков.

                  P.S. Для прояснения ситуации с подписью - благодарю всех за присланные предложения по стандарту, считаю, что первым дополнением надо описать процедуру выбора параметров подписи, этим и займемся, надеюсь первые постинги по этой теме будут через неделю.

                  Комментарий


                  • #10
                    Уважаемая Наталья!

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

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

                    Теперь о тонких клиентах и неодходимости доверия клиента к банковскому ПО.

                    Неужели действительно специалисты по информационной безопасности (а не LeColonel'ы, Аналитики и пр.) на самом деле считают, что БЕЗ доверия клиента к предоставляемому банком ПО можно обойтись?!

                    Неужели для специалистов надо расжевывать, что любая система для Интерне-Банкинга, основанная к примеру на динамически формируемых HTML-страничках по определению требует доверия клиента к банковскому ПО, ибо HTML-странички являются первичным источником клиентской бизнес-логики?!

                    Именно в загружаемых клиенту HTML-старничках содержатся скрипты для вызова тех или ных функций из внешних установленных к клиенту СКЗИ. Именно в HTML-страничках содержатся HTML-формы, которые и представляют из себя отправляемый клиентом документ.

                    Неужели никто не понимает, что банк запросто может изменить логику в HTML-страничках, может отображать на экране одну HTML-форму, а подписывать через Local_Proxy_SSL (яркими представителями таких СКЗИ являются Сигнал-КОМовский Интер-Про, БССовский BS-Defender) совершенно другую (или модифицированную) HTML-форму?!

                    Или же изменить скрипт в HTML-страничке таким образом, что при вызове функции внешнего даже сертифицированного ФАПСИ СКЗИ (например CryptoPro CPS), будет подписываться совершенно другая платежка?!

                    Есть ли решение проблемы недоверия клиента банковскому софте?

                    Наверное есть. Как минимум установка толстого клиента, дистрибутив которой получен не от банка, а из доверенного источника. Запрет каких-бы то ни было автоматических обновлений, рассылаемых из банка (ведь даже простым изменением экранной формы документа можно достичь очень многого, не говоря уже о модификации бизнес-логики работы с документов).

                    Но такие неизменные, негибкие системы, без возможностей оперативно из банка разослать обновления клиентам, никому не нужны!!!

                    В случае тонкого клиента - возможно единственный выход - установка в браузер некоего плагина (или локального прокси). А также ЭЦП Банка под всеми загружаемыми в браузер клиента ресурсами (вне зависимости гифчик это, скриптик или html-страничка) и сохранение ВСЕХ загружаемых из банка ресурсов с ЭЦП банка в локальном Хранилище клиента, дабы в последствии можно было прямо по шагам восстановить работу клиента, восстановить что загружал клиент из банка.

                    Что в итоге получим? Получим толстого клиента. Во-первых плагин, который надо передавать клиенту из доверенного источника гарантированным путем, во-вторых - локальное Хранилище у клиента на жестком диске, которое будет прирастать на несколько мегабайт за каждый сеанс работы. И в-третьих - жуткие тормоза на банковской стороне, ибо каждый отдаваемый клиенту ресурс надо банку подписывать. А процедура формирования одной ЭЦП - процесс вычислительно ёмкий. Сервер же - приложение многопоточное, которое должно обслуживать не один десяток запросов в секунду и не от одного клиента.

                    Есть ли решение проблемы недоверия клеинта к банковскому ПО для случае систем на основе Java-апплета?

                    Тоже есть - загрузка html-страниц и Java-апплетов из доверенного источника (коим банк у нас уже не является). Кто будет этим источником? Разработчик? А может независимое Хранилище, не имеющее никаких подковёрных связей с банками и разработчиком?! Но где гарантия, что "выделываться" не начнет Хранилище???
                    С уважением, Репан Димитрий
                    Компания "БИФИТ" - www.bifit.com

                    Комментарий


                    • #11
                      Я рад что наконец-то подключился Волчков - без его очередных обвинений во всех смертных грехах и отдельно в черном пиаре было просто скучно

                      А то всё какие-то Аналитики....
                      С уважением, Репан Димитрий
                      Компания "БИФИТ" - www.bifit.com

                      Комментарий


                      • #12
                        Стремясь вести диалог в контруктивном русле предлагаю Алексею Волчкову ответить на вопрос:

                        Считает ли Вы, Алексей Вочлков, возможность банка самостоятельно определять используемые в системе для Интернет-Банкинга СКЗИ уязвимостью системы?

                        Прошу дать расширенный комментарий, почему эта фича, присутствующая во всех решениях К-Б и И-Б, вдруг стала уязвимостью.
                        С уважением, Репан Димитрий
                        Компания "БИФИТ" - www.bifit.com

                        Комментарий


                        • #13

                          Считает ли Вы, ..., возможность банка самостоятельно определять используемые в системе для Интернет-Банкинга СКЗИ уязвимостью системы?
                          Уважаемый форумяне.

                          Позволю себе несколько прояснить ситуацию.
                          В чём состояла суть обсуждаемой здесь проблемы iBank: в возможности банка(или его сотрудников) в любой момент без ведома и согласия пользователя менять используемую (заявленную при подключени к сервису) криптобиблиотеку независимого разработчика на свою собственную и обратно, не оставляя пользователю реальных шансов обнаружить подмену.
                          То есть клиент на самом деле мог незаметно для себя оказаться не пользователем заявленной (и приобретаемой, ведь регистрация стоит денег) криптобиблиотеки от Бифит или "Базис-Защита", а пользователем какого-то кода банка.
                          Разумеется банк вправе менять используемую СКЗИ на свою , но он не вправе делать это без ведома и согласия пользователя, тем более в процессе эксплуатации. Именно эту возможность предоставил банку iBank. Именно это я и счёл ошибкой.
                          Воспользуется ли банк ей или нет это уже дело третье.
                          *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
                          Дополнение:

                          Дмитрий же , как я понял, считает, что без безусловного доверия банку обойтись невозможно независимо от того разработано ПО сторонним разработчиком или нет,( причём никак это не отражает в документации).

                          Эту позицию я тоже считаю ошибочной.

                          Вообще-то, как же отмечалось на этом форуме в схеме безусловного доверия пользователя банку, схемы цифровой просто не нужны.

                          Может ли разработчик защитить пользователя от подобной проблемы. Может. Во-первых, по предложенной Дмитрием схеме защиты ПО, но она мягко говоря неоптимальна.

                          В рамках доверия современным технологиям цифровой подписи существует более простая схема:
                          1) Установка и обновление ПО (неважно толстый или тонкий это клиент, каждый имеет свои преимущества) производится с помощью подписанного ЭЦП приложения ( или приложения переданного по надёжным каналам с фиксацией его контрольной суммы общепринятым методом).
                          2) Каждое обновление, содержащее исполняемый код, также подписывается с помощью ключа разработчика и правильность документа проверяется инсталлятором.

                          Всё. Собственно говоря, именно эта схема и реализована в iBank.

                          Идея Дмитрия о возможности атаки ч/з HTML -конечно имеет право на существование, но это принципиальный недостаток тонких клиентов, устраняемый своевременным обновлением и грамотным выбором браузера.

                          В исправном браузере не содержащем известных ошибок средствами Javascript и HTML невозможно прочитать содержимое диска и соответственно секретный сключ.
                          Это по силам только подписанному апплету с привилегиями, включаемыми только с согласия пользователя, после проверки последним подписи разработчика.

                          Поэтому апплет или приложение не должны содержать "фич" , позволяющих подменить исполняемый в СКЗИ код.

                          При попытке-же подменить апплет пользватель получит предупреждение браузера содержащее данные об новом авторе апплета.

                          Последний раз редактировалось Komlin; 14.06.2002, 12:57.

                          Комментарий


                          • #14
                            отправил Комлин Александр
                            Идея Дмитрия о возможности атаки ч/з HTML -конечно имеет право на существование, но это принципиальный недостаток тонких клиентов, устраняемый своевременным обновлением и грамотным выбором браузера.
                            Александр, я совершенно не понимаю при чем здесь браузеры?! Да пусть будет самый что ни на есть идеальный браузер без каких-либо ошибок! Описанная мною атака вообще не использует багов бразуров.

                            Цель рассмотренной мною атаки через HTML-страницы не в том, чтобы похитить секретный ключ ЭЦП клиента, а в том, чтобы подписать документ от имени клиента, который клиент не желал подписывать.

                            Ведь конечная цель злоумышленника - похищение денег клиента, а не просто компроментация секретного ключа ЭЦП клиента.

                            Идея же атаки со стороны банковского автоматизатора строится на том, что HTML-страницы фактически содержат в себе код, исполняющий браузером.

                            Часть кода HTML-страницы (форматирование) отвечает за представление данных на экране пользователя.

                            Другая часть кода HTML-страницы - скрипты - отвечают:

                            - за взаимодействие с пользователем, за проверку введенных данных прямо на стороне клиента

                            - за формирование подписываемой последовательности на основе введенной клиентом информации в поля платежки

                            - за вызов из внешней криптобиблиотеки функции формирования ЭЦП клиента

                            - за передачу полученной подписанной последовательности на Web-сервер банка.

                            В случае же использования Local_Proxy_SSL скрипты из HTML-странички позволяют нелояльному банковскому IT-сотруднику подменить подписываемый документ, фактически подписать и отправить в банк левую платежку. Это задача даже не для студентов профильной специальности - это задачка для абитуриента

                            В обоих случаях платежки с нужными реквизитами получателя и необходимой суммой с корректной ЭЦП клиента вполне достаточно злоумышленнику. По этой платежке уплывут деньги клиента.

                            Далее клиент приедет в банк разбираться, а банк ему представит документ с корректной ЭЦП клиента, и пусть теперь клиент кричит и вопит, что он не формировал и не подписывал данный документ. Пусть приносит свои логи и показывает комиссии. Да, в клиентских логах нет записи о подписи платежки. Ну так ведь клиент мог подчистить логи (удалить запись)!

                            А вот банк свои контрольные архивы бережет. И в них, в банковских контрольных архивах платежка с ЭЦП клиента есть. Значит банк правильно поступил, совершив платеж со счета клиента, ибо документ с ЭЦП клиента ЕСТЬ.

                            Будем дальше раскладывать всё по полочкам, перейдя к КОНКРЕТНЫМ версиям КОНКРЕТНЫХ производителей К-Б и И-Б с КОНКРЕТНЫМИ СКЗИ? Будем дальше описывать направления атак, которые могут совершить банковские IT-сотрудники, а также установщики банков и компаний-разработчиков, которые катаются по банкам и клиентам и ставят весь клиент-банковский софт?!

                            А может лучше начнем с Шлюзов, которые осуществляют интеграцию фронт-энда (К-Б и И-Б) с АБС Банка?! А потом перейдем к самой АБС и ее АРМам. Там для банковских IT-сотрудников с определнными правами доступа непаханное поле для злоупотреблений! Или же лучше сразу к рейсам в РКЦ - там совсем другой уровень, бедных клиентов обижать не будем?
                            С уважением, Репан Димитрий
                            Компания "БИФИТ" - www.bifit.com

                            Комментарий


                            • #15
                              На этот раз Дмитрий Репан абсолютно прав. Банк вправе менять системы защиты, а как это производится - с предупреждением, без предупреждения - это оговаривается в договоре с клиентом. И если клиент не питает доверия к банку - вряд ли он пойдет на обслуживание в этот банк.
                              А вот господин Komlin не прав - банк не продает ПО криптозащиты своим клиентам (не банковская это услуга), поэтому клиента нельзя назвать владельцем ПО. Криптозащита - это составная часть инструмента продажи банковских услуг. А если инструмент модульный - то это только облегчает его ремонт и модернизацию.
                              Поэтому я бы не стал называть это ошибкой ПО - скорее действительно организационный вопрос конкретного банка. А у толкового автоматизатора есть еще мимллион возможностей по несанкционированному списанию денег с клиента - он должен просто их знать по роду своей деятельности, дабы противостоять таким угрозам.

                              Комментарий


                              • #16
                                2 Димитрий
                                Димитрий, я говорил о конкретном продукте: iBank. В нём HTML с сервера используется только для вызова апплета который и выполняет весь цикл действий по подписи документа и единственная реальная HTML-атака
                                представляет из себя использование ошибок браузера.

                                Вы же описываете какой-то другой продукт (Сигнал-КОМовский Интер-Про?, БССовский BS-Defender?) , мне пока не знакомый. Соответственно я ничего пока не могу сказать о его недостатках и возможных аттаках.
                                Может поделитесь ссылкой, на то о чём вы говорите?


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

                                Комментарий


                                • #17
                                  ИМХО, более справедливой была бы следущая новость:

                                  iBank повышает свою надежность!

                                  ООО Бифит в новой версии своей системы интернет-банкинга iBank наконец-то исправил уязвимость при подключения сторонних криптобиблиотек. О данной уязвимости систем ИБ и БК известно давно и она служила постоянным источником раздражения независимых экспертов по безопасности. Бифит свою систему исправил - очередь за остальными производителями российских систем ИБ и БК.

                                  Ну и еще можно о том, что забота о безопасности своего продукта с некоторых пор для Бифита стала первоочередной задачей... Похвально стремление Бифита при помощи независимых экспертов из Рускрипто сделать iBank на рынке ИБ в России самой безопасной системой. И т.д. и т.п.

                                  Комментарий


                                  • #18
                                    отправил Александр Комлин
                                    Вы же описываете какой-то другой продукт (Сигнал-КОМовский Интер-Про?, БССовский BS-Defender?) , мне пока не знакомый. Соответственно я ничего пока не могу сказать о его недостатках и возможных атаках. Может поделитесь ссылкой, на то о чём вы говорите?
                                    Всё, сдаю "конкурентов"

                                    Компания "Банк'с Софт Системс" - www.bssys.com

                                    Разработчик решений для Интернет-Банкинга и классического Банк-Клиента. Тонкий клиент на базе HTML-страниц. В качестве средства защиты в Интернет-Клиенте используется самостоятельно написанный модуль BS-Defender. Работает только под MSIE. Позволяет подключать внешние криптобиблиотеки. Устанавливается на стороне клеинта и на стороне банка. Работает между Web-браузером клиента и Web-сервером банка, шифруя трафик, проводя аутентификацию и подпись под HTML-формами. Реализует концепцию ProxySSL. Описания криптопротокола в открытой печати не обнаружено. Дистрибутив BS-Defender'а можно попросить у банков, использующих это решение (по последним заявлениям Дмитрия Барсукова таковых около 80 реально работающих). Есть демо-стенд, но без криптографии.


                                    Компания "ИНИСТ" - www.inist.ru

                                    Разработчик толстого Банк-Клиента и тонкого Интернет-Клиента. Интерфейс тонкого клиента на базе HTML-страниц. Для ЭЦП используется загружаемая к клиенту ActiveX-компонента. Работает только под MSIE. Есть демо-стенд.


                                    Компания "РФК" - www.rfc.ru

                                    Разработчик толстого Банк-Клиента. Пытается двигать Интернет-Банкинг. Решение на базе HTML-страниц. Для защиты трафика и ЭЦП документов используется продукт "Интер-Про" компании "Сигнал-КОМ" - www.signal-com.ru Продукт реализует концепцию ProxySSL - шифрование + ЭЦП под HTML-формами. В основе лежали разработки проекта Эрика Янга SSLeay. Отличительная особенность - реализует протокол SSL v.2 (может я чуть отстал от жизни и сейчас уже v.3) с возможностью использования в качестве алгоритма шифрования советский ГОСТ 28147-89. ЭЦП - российский ГОСТ Р34.10-94. На СКЗИ есть сертификат ГТК.

                                    На СКЗИ от Сигнал-КОМа есть и другие проекты - у Диасофта, Степапа. Знаменитая "Северная Казна" также работает на Интер-Про от СигналКОМа.

                                    Более детально о разработчиках - http://www.ifin.ru/banking/creaters.stm
                                    С уважением, Репан Димитрий
                                    Компания "БИФИТ" - www.bifit.com

                                    Комментарий


                                    • #19
                                      Димитрий

                                      Считает ли Вы, Алексей Вочлков, возможность банка самостоятельно определять используемые в системе для Интернет-Банкинга СКЗИ уязвимостью системы?

                                      В прниципе да - считаю. Это собственно ответ краткий, далее ответ развернутый.
                                      В свое время лет этак 10 назад появился вирус "Турбо Криптон", даже не вирус, а троян. Всех кто использовал плату Криптон раздражала крайне низкая скорость шифрования. Программа "Турбо криптон" "ускоряла работу в 5-7 раз. Правда при этом ничего не шифровалось, а ксорировалось с фиксированной гаммой. Плата вызывалась из облочки фирмы "Анкад" через прерывание, достаточно было на него "повеситься" и вот вам результат пользователь думает что шифрует информацию, а реально ничего не происходит.
                                      Тогда этот случай навел на мысли о том, что "криптография" должна быть "крепко прикручена" к приложению. В остальных системах этот принцип также справедлив.
                                      Естественно возникает конфликт между требованием "стандартизации" и требованием "прикрученности". Здесь можно использовать несколько приемов (разнесение функйций контроля целостности между модулем криптографии и главным модулем и т.д. и т.п.). В том же случае, когда в приложении остаются "открытые интрефейсы" для подключения внешней криптографии в этом случае возникает ситуация когда между приложением и "крипотграфией" можно поставить прокладку или заглушку. Поэтому функции контроля целостности необходимы.
                                      Понятно, что панацеи нет, но как писал один из великих "криптография позволяет оставаться большинству честных людей честными". Поэтому "приглашение к мошенничеству" в виде открытого интерфейса это "не есть хорошо".
                                      Вы Димитрий правильно подметили, что слабость характерна для многих систем, именно поэтому вопросам грамотного встаривания криптографии в приложения столь много времени уделяется специалистами. Вам как, лицензиату ФАПСИ, "на встраивание чегото-там" это надо знать. Я могу понять ребят из ФАПСИ - им платишь деньги и "вот она лицензия", далее хоть трава не расти, всем понятно, что лицензия это просто свидетельство об уплате определнной суммы в карман лицензиаторов и сертификаторов. Но Вы позиционируете себя как специалист по безопасности - посмотрите как сделана "защита" от злонамеренного сотрудника в иных системах, нежели те, что Вы перечисляли, Вы найдете много нового.
                                      Проблематикой "правильного встраивания криптографии" в приложения много занимаются в ГЦБИ республики Беларусь, был доклад на РусКрипто 2002, тезисы к сожалению ребята не дали.

                                      Алексей.

                                      Комментарий


                                      • #20
                                        Димитрий

                                        О компания "РФК"

                                        Димитрий, я имею опыт работы с продуктами этой компании и хочу сказать Вам, что Ваши утверждения о возможности тайной подмены СКЗИ или HTML-страниц( точнее их форм) в этом конкретном случае необоснованны.

                                        Не знаю, как обстоит дело в других продуктах, но надеюсь, что и там также имеются методы защиты от очевидных атак.
                                        ИМХО, не стоит защищать свой продукт обвиняя другие.

                                        Начнём по порядку.
                                        а) Подмена СКЗИ.

                                        В качестве СКЗИ используется "Интер-Про" от компании "Сигнал-КОМ". Это прокси сервер с поддержкой средств ЭЦП. Он представляет собой стабильную программу, передаваемую клиенту установленным образом со всеми необходимыми формальностями.
                                        Его исполняемый код не содержит банковской специфики и не нуждается в постоянном обновлении (Настройки конкретного банка (его ip-адрес и порт) прописываются в ini файлах и при необходимости (которая на моей памяти не возникала) могут быть изменены пользователем). Если клиент по каким-то причинам желает получить новую версию программы он может сделать это установленным образом.

                                        Остальная часть продукта представляет собой HTML -формы обрабатываемые в Internet Explorer или в Netscape Navigator никак не влияющие на выбор СКЗИ и не имеющие доступа к диску.
                                        Поэтому не существует возможности тайной и недоказуемой подмены СКЗИ аналогичной имевшейся в iBank.

                                        б) Подмена подписываемого текста (формы).

                                        При обнаружении в пересылаемом HTML требующей подписи формы InterPro выводит окно с подписываемым текстом на экран и требует согласия пользователя на подпись. Поэтому описанная Вами идея тайной подмены страниц(форм) также бесполезна.

                                        Наталья.

                                        Комментарий


                                        • #21
                                          Я бы на месте РФК на iBank сильно обиделся.
                                          Мало того, что своё нормально сделать не могут, так ещё и чужое об...ли .

                                          Комментарий


                                          • #22

                                            Экспертик

                                            б) Подмена подписываемого текста (формы).

                                            При обнаружении в пересылаемом HTML требующей подписи формы InterPro выводит окно с подписываемым текстом на экран и требует согласия пользователя на подпись. Поэтому описанная Вами идея тайной подмены страниц(форм) также бесполезна.
                                            Наталья, Вы ничего не путаете? InterPro - просто прокси-сервер, он тихо делает свое дело, а окно с текстом и запросом подтверждения, скорее всего, выводится кодом странички. Или у Вас какая-то специальная версия InterPro, отличающаяся от стандартной?
                                            Earl Vlad Drakula. ///

                                            Комментарий


                                            • #23
                                              Димитрий
                                              На СКЗИ есть сертификат ГТК
                                              Дмитрий, а вот такие проколы - не допустимы.
                                              InterPro действительно имеет сертификат ГТК как межсетевой экран. Но к СКЗИ это никакого отношения не имеет. Зато сертификат ФАПСИ имеет используемая в нем СКЗИ - "КриптоКом 3.0". Не вводите, пожалуйста, публику в заблуждение, тут народ самостоятельно неплохо запутается
                                              Earl Vlad Drakula. ///

                                              Комментарий


                                              • #24
                                                hugevlad
                                                Нет здесь ничего не напутано. Это просто Сигнал-Ком в свое время извратился с технологией.
                                                Суть - нужно было сделать шифрование и подпись на "канальном уровне" - читай SSL. Проблема - отсутствие возможности у разработчика написать протоколы нижнего уровня. Решение - пишется прокси сервер, который устанавливается на клиентское место, в настройках браузера указывается - работать через данный прокси, все ключи загружаются в прокси, шифрование и подпись происходит в нем (предусмотрена некоторая защита от загрузки на прокси всякой левоты, но детальную проверку надежности защиты о которой пишет Наталья никто не проводил). Сертифицирован в ГТК, как межсетевой экран, потому как сертификата ФАПСИ на комплекс получить не удалось, вставили "КриптоКом" - и вот Вам чудо-юдо Прокси сервер с шифрованием, сертифицированный как межсетевой экран.


                                                Алексей.

                                                Комментарий


                                                • #25
                                                  Alexei Volchkov
                                                  Нет здесь ничего не напутано. Это просто Сигнал-Ком в свое время извратился с технологией.
                                                  Суть - нужно было сделать шифрование и подпись на "канальном уровне" - читай SSL.
                                                  Как работает продукт и что он делает я приблизительно представляю, потому как пользуюсь. Впрочем, как выяснилось, RTFM полезно Только что залез в доку, действительно в InterPro есть такая фича, как выбрасывание окошка с запросом. Просто оно у меня выключено в ini-файле... Так что вопрос про ошибку снимается

                                                  Кстати, а чем Вам не нравится использованная в InterPro технология? В чем ее извратность?
                                                  Earl Vlad Drakula. ///

                                                  Комментарий


                                                  • #26
                                                    hugevlad
                                                    Я не сказал, что она мне не нравится, я просто заметил, что она действительно "вычурная". На мой взгляд не надо городить огород вокруг прокси сервера, для выполнения функционала, заложенного в InterPro, достаточно иметь ssl/tls и подпись транзакций, все это гораздо более изящно решается на уровне драйверов, или в крайнем случае на уровне "тунелирования" пакетов. Решение c прокси сервером возникает в том случае, когда написать более изящную программу не представлялось возможным (насколько мне известно из-за квалификации разработчика), ровно об этом и речь. С другой стороны поддерживаю Димитрия, в том, что возможность "отчуждения" приложения от криптографии здесь также достаточно высока, хотя (еще раз повторюсь) InterPro не анализировали.

                                                    Алексей.

                                                    Комментарий


                                                    • #27
                                                      С удивлением прочитали высказывания г-на Волчкова в части касающейся компании Сигнал-КОМ, ее продуктов и разработчиков. Обращает на себя внимание тон высказываний, направленный не на конструктивное обсуждение каких-либо проблем, а на попытку дискредитации нашей компании. Это тем более удивительно, так как мы никогда не контактировали с данным г-ном и, более того, никогда ничего не слышали о его собственных разработках, что могло бы хоть как-то пролить свет на его квалификацию и позволило бы судить о компетентности его высказываний в отношении обсуждаемых им программных продуктов. По его собственным словам он не занимался анализом Inter-PRO, скорее всего, незнаком и ни с какой другой продукцией Сигнал-КОМ, но, тем не менее, позволяет себе оскорбительные замечания, касающиеся квалификации разработчиков компании. К слову сказать, г-н Волчков не в первый раз проявляет непорядочность и использует заведомую ложь по отношению к нашей компании, вводя многих в заблуждение. Примером могут служить материалы с последней конференции РусКрипто 2002, где он в своей безапелляционной манере утверждал, что, оказывается, управление ключами по протоколу Диффи-Хеллмана для телефона Voice Coder - 2400, выпускаемого Сигнал-КОМ, разрабатывала компания ЛАН Крипто. Большей глупости трудно себе представить. Надеемся, что это заявление было сделано без ведома руководства ЛАН Крипто.
                                                      В компании Сигнал-КОМ работают высоко-квалифицированные специалисты, о чем свидетельствуют многочисленные проекты, реализованные за 12 лет существования фирмы более, чем в 160 банках и других организациях. Предлагаем г-ну Волчкову поближе ознакомится с продукцией компании, т.к. среди наших разработок имеются и средства защиты персонального IP-трафика пользователя на базе клиентского криптографического драйвера IPSafe-PRO Client for Windows 2000>, и шифраторы IP-трафика на базе протокола ESP (Encapsulated Security Payload, RFC 2406) в туннельном режиме, и криптобиблиотеки для реализации SSL/TLS на базе сертифицированного СКЗИ, и многое другое. Все это, надо полагать, свидетельствует о достаточно высокой квалификации специалистов Сигнал-КОМ.
                                                      Что касается продукта Inter-PRO: Его разработка началась в 1995-96 году и обеспечивала снятие действовавших тогда экспортных ограничений на длину криптографических ключей и расширение перечня алгоритмов шифрования отечественным ГОСТ 2814789 при работе по протоколу SSL в HTTP-приложениях, использующих зарубежные браузеры и Web-серверы. В рамках SSL была также реализована возможность формирования/проверки цифровой подписи под электронными формами, что позволило Inter-PRO стать первым продуктом на российском рынке, предоставившим клиентам возможность безопасной работы через Интернет с системами электронной коммерции, банкинга и другими Web-приложениями. И именно Proxy-технология, о которой так презрительно отзывается г-н Волчков, позволила тогда банкам и клиентам с минимальными затратами получить стойкую криптографию и организовать защищенный документооборот на базе имеющихся стандартных браузеров и Web-серверов зарубежных производителей. С тех пор прошло уже 6 лет эксплуатации Inter-PRO и то, что в 2002 году этот продукт все еще используется и активно обсуждается, свидетельствует о правильности выбранного нами тогда направления. На базе Inter-PRO построили свои системы несколько десятков российских банков и корпораций.
                                                      Сейчас наша компания предлагает новые решения на основе COM-объектов, а в четвертом квартале планируется завершение разработки собственного криптопровайдера (CSP). Все это выполняется на основе сертифицированного СКЗИ "Крипто-КОМ 3.0" и поддерживаются удостоверяющим центром нашей разработки - Notary-PRO (X.509 v.3). В настоящее время на сертификации находится новая версия СКЗИ Крипто-КОМ 3.1, включающая реализацию нового ГОСТ Р 34.10-2001, основанного на эллиптических кривых.
                                                      Хотелось бы пожелать г-ну Волчкову и всем участникам уважаемого форума более ответственно относится к своим заявлениям, когда речь идет о качестве какого-либо программного продукта, не совсем им знакомого или не совсем понятного.

                                                      С уважением,
                                                      В.Смирнов (Сигнал-КОМ)

                                                      Комментарий


                                                      • #28
                                                        Как пользователь InterPro, полностью поддерживаю выступление г. Смирнова относительно качества продкции InterPro. При грамотной реализации эти решения столь же стойки как любые другие.

                                                        Предлагаю гг Д. Репану и А. Волчкову извиниться (как сделал это HugeVlad)за поспешные утверждения о нестойкости решений на основе продуктов на InterPro.

                                                        ИМХО, в сложившейся ситуации виноват не столько А. Волчков, на деле лишь повторивший заявления Д. Репана. Сыр-бор разгорелся в первую очередь из-за утвержения Димитрия о лёгкой подмене подписываемой информации в решения с proxy-sll.

                                                        ИМХО, все обвинения делаемые в адрес какого-то продукта следует подтверждать фактами (хотя бы спорными) как это делает Комлин.

                                                        От себя хотела бы добавить следующее.

                                                        Прокси-сервер -есть одно из наиболее общеприятых решений в интернет вообще и хорошо именно своей независимостью от браузеров и совместимостью с файреволами.

                                                        Наталья.

                                                        P. S. Предлагаю также вернуться к главной теме спора.
                                                        Допустима ли в ПО с поддержкой ЭЦП возможность атаки банка на клиента?
                                                        Какой смысл в применении продуктов с цифровой подписью в этом случае по сравнению с более дешевыми решениями на основе длинных паролей?

                                                        Комментарий


                                                        • #29
                                                          Alexei Volchkov
                                                          Я не сказал, что она мне не нравится, я просто заметил, что она действительно "вычурная". На мой взгляд не надо городить огород вокруг прокси сервера, для выполнения функционала, заложенного в InterPro, достаточно иметь ssl/tls и подпись транзакций, все это гораздо более изящно решается на уровне драйверов,
                                                          Смешно, право слово. Приложение, основное назначение которого файловые операции, тоже в виде драйвера реализовывать? По молодости лет для разминки мозгов я писал на ассемблере дисковый редактор, который не пользовался функциями ОС, только BIOS. Но это было чистой воды эстетство, ибо diskedit от Нортона все-таки был удобней. Может быть все-таки задумаемся, зачем была придумана 7-уровневая модель OSI, уж не для разделения ли функций? Именно потому, что в этой ситуации нужен SSL, это и было реализовано в виде прокси-сервера, а не опущено на уровень драйверов. "Изящность" решения с драйвером - просто потрясающая. Мало того, что его нужно инсталлировать (InterPro просто запускается на исполнение), так решение еще и непреносимо между платформами (точнее, переносимо, конечно, ценой написания большого количества строк "индивидуального" кода под каждую ОС). Вобщем, мне несколько странно слышать от Вас такие речи... Хотя, Вы ведь не в банке работаете, можете не знать тонкостей эксплуатации подобных систем...
                                                          Earl Vlad Drakula. ///

                                                          Комментарий


                                                          • #30
                                                            Экспертик
                                                            извиниться (как сделал это HugeVlad)
                                                            А я разве кого-то оскорблял, чтобы извиняться? Мне проще было стереть сообщение, просто раз уж лопухнулся прилюдно, надо это и признать прилюдно.
                                                            BTW, с включенным режимом подтверждения подписи форм интенсивная работа может стать маленьким кошмаром. Впрочем, это закономерно: удобство и безопасность вещи "обратнопропорциональные"...

                                                            P. S. Предлагаю также вернуться к главной теме спора.
                                                            Допустима ли в ПО с поддержкой ЭЦП возможность атаки банка на клиента?
                                                            Какой смысл в применении продуктов с цифровой подписью в этом случае по сравнению с более дешевыми решениями на основе длинных паролей?
                                                            Мне кажется, такая постановка некорректна - она напоминает мне формулировку референдума перестроечных времен, когда вопрос был сформулирован так, что ответить на него отрицательно мог только полный отморозок. По идее, любое ПО в любой системе не должно давать возможность безнаказанно и незаметно осуществлять атаку одного участника обмена на другого. Но так мы плавненько дойдем до абсурда: кто возьмется утверждать, что в конкретном продукте (с учетом условий его реальной эксплуатации на конкретной ОС и компьютере) возможность осуществить атаку отсутствует? Наличие такой возможности может показать эксперт, а вот отсутствие... В одном, наверное, расхождений не будет: если возможность найдена, разработчик должен немедленно принять все меры по ее устранению. Кстати, буржуи начали разработку процедуры, которая стандартизовала бы отношения сторон (эксперт, разработчик, пользователи и остальная общественность) в процессе обнаружения ошибки. Там будут оговорены формы извещения, сроки, выделяемые на устранение (мораторий на публикацию) и механизмы извещения заинтересованных сторон о результатах. Похоже, у нас необходимость такой бумаги тоже давно назрела, т.к. процесс поиска ошибок с удручающим постоянством плавно переходит в скандалы.

                                                            Earl Vlad Drakula. ///

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X