Bankir.Ru
4 декабря, воскресенье 19:17

Объявление

Свернуть
Показать больше
Показать меньше

Сравнение Web и Java технологий. Защищенность.

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

  • Сравнение Web и Java технологий. Защищенность.

    А сильно Вас, Димитрий, задела описанная Анатолием Сапрыкиным возможность вскрытия iBank. Много разного флема было. Значит, прав он. All может подробно почитать данную возможность в разделе "О юридической значимости протокола SSL".

    Если по существу, то прокомментирую две Ваши фразы:

    цитата:
    --------------------------
    Гарантированную защиту от такого рода атак как раз и обеспечивает протокол SSL. Естественно при соблюдении условия, что либо Сертификат честно получен банком в VeriSign или Thawte, или же передан клиенту гарантированным путем на дискете и инсталлирован в БД сертификатов Web-браузера (как это делается во всех банках в случае с передачей открытого ключа банка в обычном К-Б, или в других И-Б, где открытый ключ банка или сертификат, передается на дискете).
    --------------------------
    Верно, Димитрий. ЕСЛИ ПЕРЕДАН КЛИЕНТУ ГАРАНТИРОВАННЫМ ПУТЕМ НА ДИСКЕТЕ И ИНСТАЛЛИРОВАН В БД СЕРТИФИКАТОВ web-браузера.
    Однако, много у кого на сайте я видел предложение "скачать и зарегистрировать" сертификат банка. ЭТО БЫЛА РЕКОМЕНДАЦИЯ. Зачем же рекомендовать, если сертификат НЕПРЕМЕННО дается на дискете.
    И ПОТОМ, А ЕСЛИ клиент (ОН НЕ ОБЯЗАН ЭТО ЗНАТЬ - ПРОГРАММА ДОЛЖНА БЫТЬ ЗАЩИЩЕНА ОТ ДУРАКА. БУХГАЛТЕР - КАК ПРАВИЛО ДУРАК. Не обижайтесь, это касается ТОЛЬКО компьютерной грамотности) не инсталлировал сертификат, в интернет-кафе, например, ЧТО ТОГДА. А тогда, пиши пропала, украли его ключики, а, значит и денежки. Задумайтесь, господа Банкиры, ВАМ ЭТО НАДО, сидеть на пороховой бочке?!

    цитата
    ----------------------
    Что касается компетентности бухгалтера, то если он не понимает, что вообще делает, то такому бухгалтеру даже каркулятор доверить нельзя, не то, что Банк-Клиент, и уж тем более Интернет-Банкинг. Иначе из-за своей невнимательности он, случаем, отошлет деньги компании-работодаделя на свой личный счет в Швейцарии, или того хуже...
    ----------------------
    Повторюсь. ОН НЕ ОБЯЗАН ЭТО ЗНАТЬ - ПРОГРАММА ДОЛЖНА БЫТЬ ЗАЩИЩЕНА ОТ ДУРАКА. БУХГАЛТЕР - КАК ПРАВИЛО ДУРАК. Не обижайтесь, это касается ТОЛЬКО компьютерной грамотности. Бухгалтер знает одно - "береги дискету с ключами". И бережет их. А ключики и денежки все одно крадут.
    Задумайтесь, господа Банкиры, ВАМ ЭТО НАДО, сидеть на пороховой бочке?!

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

    В BS-Client ничего подобного невозможно. ЛЮБОЙ сеанс связи с банком возможен ТОЛЬКО при наличии дискеты с ключами у клиента. Ничего клиент знать и замечать не обязан - береги дискету с ключами и все тут. Прямо как в толстом БК.

    С Уважением,
    Барсуков Дмитрий,
    начальник отдела продаж
    Компании "Банк'с Софт Системс".


  • #2
    сразу вопрос:

    Реальная конфликтная ситуация: клиент отправил платеж по системе
    BS-Client на сумму X. А платеж не ушел вовремя из банка
    (попросту был потерян). Клиент попадает на штраф Y.
    Вопрос: с чем клиент придет в суд, отстаивать свою позицию?

    WBR
    serg

    Комментарий


    • #3
      BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>отправил Барсуков Дмитрий А сильно Вас, Димитрий, задела описанная Анатолием Сапрыкиным возможность вскрытия iBank.
      Много разного флема было. Значит, прав он. All может подробно почитать данную возможность в разделе "О юридической значимости протокола SSL".[/b][/quote]

      То, что написал Анатолий Сапрыкин, по всей видимости "главный эксперт компании БСС по вопросам безопаcности", эту в общем-то "писанину", я еще читал в ноябре месяце, периодически получая ее в течение двух месяцев от банков с просьбой прокомментировать.

      Я специально поместил свой ответ в отдельный топик - www.bankir.ru/ubb/Forum11/HTML/000090.html и настоятельно бы хотел увидеть там квалифицированный ответ от Анатолия Сапрыкина, а не Ваше "искреннее признание" и Ваши призывы "замять гнилой базар".

      BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Если по существу, то прокомментирую две Ваши фразы:[/quote]

      Значит теперь Вы выступаете в роли главного специалиста по безопасности? Отлично. Пройдемся по существу вопроса.

      BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Гарантированную защиту от такого рода атак как раз и обеспечивает протокол SSL. Естественно при соблюдении условия, что либо Сертификат честно получен банком в VeriSign или Thawte, или же передан клиенту гарантированным путем на дискете и инсталлирован в БД сертификатов Web-браузера (как это делается во всех банках в случае с передачей открытого ключа банка в обычном К-Б, или в других И-Б, где открытый ключ банка или сертификат, передается на дискете).
      --------------------------
      Верно, Димитрий. ЕСЛИ ПЕРЕДАН КЛИЕНТУ ГАРАНТИРОВАННЫМ ПУТЕМ НА ДИСКЕТЕ И ИНСТАЛЛИРОВАН В БД СЕРТИФИКАТОВ web-браузера.[/quote]

      Повторяюсь - ДВА ВАРИАНТА. Первый - честно полученный сертификат. Второй - передача клиенту самодельного сертификата на дискете. Вы хотите рассмотреть второй вариант? Давайте.

      BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Однако, много у кого на сайте я видел предложение "скачать и зарегистрировать" сертификат банка. ЭТО БЫЛА РЕКОМЕНДАЦИЯ. Зачем же рекомендовать, если сертификат НЕПРЕМЕННО дается на дискете.[/quote]

      "Много" это "сколько"? У каких конкретно банков? Вы с ними общались? Выясняли КАК эти банки РЕАЛЬНО подключают клиентов? Или Вы просто сами решили додумать и сделали выдоды? Так вот, перед тем, как делать выводы, сначала возьмите и откройте расчетный счет в каком-нибудь банке, где стоит iBank. А потом подключитесь к iBank'у. И уже потом выдавайте на гора Ваши мудрые мысли.

      BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>И ПОТОМ, А ЕСЛИ клиент (ОН НЕ ОБЯЗАН ЭТО ЗНАТЬ - ПРОГРАММА ДОЛЖНА БЫТЬ ЗАЩИЩЕНА ОТ ДУРАКА. БУХГАЛТЕР - КАК ПРАВИЛО ДУРАК. Не обижайтесь, это касается ТОЛЬКО компьютерной грамотности) не инсталлировал сертификат, в интернет-кафе, например, ЧТО ТОГДА.[/quote]

      Да банки, использующие свой сертификат, передают клиент его на дискете. На ней же клиент хранит свой ключ ЭЦП (который в отличие от Вашего решения клиент генерирует сам!). Вот с этой дискетой клиент и ездит по интернет-кафе. И прежде чем начать работу - инсталлирует в Web-браузер Сертификат банка. До такой элементарной схемы Вы додуматься могли?

      BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>А тогда, пиши пропала, украли его ключики, а, значит и денежки. Задумайтесь, господа Банкиры, ВАМ ЭТО НАДО, сидеть на пороховой бочке?![/quote]

      Уже тошнит от таких "конструктивных" заявлений. Вы же сами призываете к лаконичности и "только по делу". И сами же пускаете сопли.

      BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>В BS-Client ничего подобного невозможно. ЛЮБОЙ сеанс связи с банком возможен ТОЛЬКО при наличии дискеты с ключами у клиента. Ничего клиент знать и замечать не обязан - береги дискету с ключами и все тут. Прямо как в толстом БК.[/quote]

      Представляю самый элементарный сценарий взлома системы "BS-Cleint" при условии тупости бухгалтера, который "ПОЛНЫЙ ДУРАК" (со слов Барсукова Дмитрия) и ничего не понимает в компьютерах.

      1. Вычисляем клиента.

      2. Из-за тупости бухгалтера, загружаем ему на компьютер и запускаем исполняемый модуль (exe-шник, java-апплет, html-страницу с javascript'ом, очередной "I Love You", или прислали письмо с вордовским файлом с приатаченным вирусом - в общем с загружаем и запускаем программу закладку).

      3. Закладка модернизирует установленную систему "BS-Defender", либо в случае толстого клиента BS-Cleint, таким образом, что при очередном штатном обращении к ключам, ключи считываются и по IP (сразу или с задержкой) отправляются злоумышленнику.

      BS-Defender и BS-Client взломаны вчистую (как впрочем и любой установленный толстый К-Б). И что можно противопоставить такой тупости пользователя-бухгалтера, не понимающего ничего в компьютерах и допустившего исполнение программной закладки?!

      Ок. Давайте пойдем дальше и рассмотрим вариант использования смарт-карт, к примеру GPK-8000, в которых хранятся секретные ключи ЭЦП, которые никому и никогда не отдают эти секретные ключи ЭЦП, а сами смарт-карты осуществляют подпись под переданным ей сообщением. Всё бы вроде хорошо, но кроме атаки на похищение секретного ключа ЭЦП, существует атака на модификацию документа, который реально передается смарткарточке для подписи. Здесь возникает вопрос целостности используемого ПО. Так вот, в случае когда ПО каждый раз загружается с сайта, провести атаку по модификации этого ПО на порядок сложнее, чем провести атаку на установленное у клиента ПО. Это к слову об идеальной защищенности решений, предполагающих установку у клиента спецПО. Именно это установленное спецПО является идеальной мешенью для атаки. И особенно из Интернета. В случае iBank'а - модифицировать нечего.

      В заключении я всё-таки настаиваю на конструктивном ответе Анатолия Сапрыкина на следующие вопросы.

      1. Откуда была взята цифра 900$ за Сертификат от VeriSign? А почему на 9тыс.$? Это Вы так спекулируете сертификатами? Или эта цифра от элементарного незнания сути вопроса?

      2. О простоте получения Сертификата Разработчика. Проходил ли Анатолий Сапрыкин процедуру получения Сертификата Разработчика, например в Thawte Consulting cc (ЮАР), или VeriSign Inc. (США)? Оформлял ли все соответствующие документы и заверял их в минюсте России?

      3. Писал ли кто-то из Вас Java-апплеты, которые запрашивают расширенные привилегии у Web-браузера и умеют обращаться к дисковым накопителям? Как и каким ПО необходимо создавать и подписывать CAB или JAR-архивы? В каких форматах храняться секретные ключи, запросы на сертификаты, сертификаты?

      4. Проводили ли Вы лично (в целях хотя бы контрольных мероприятий) атаки на DNS-сервера по подмене доменных имен? Или Вы только начитались умных переведенных буржуйских книжек типа "Секреты хакера" и "Как вломать Пентагон и начать 3-тью мировую войну"?

      5. Удавалось ли Вам корректно, с использованием третих средств модернизировать базу Сертификато MS IE или Netscape, вставив туда левый сертификат?

      6. Или давайте возьмем самое элементарное. Проводили ли Вы реверс-инжиниринг Java-апплетов и Серверов Приложений iBank'а? Какой версии? Знаете ли формат хранения секретных ключей? Смотрели как вычисляются секретные ключи ЭЦП клиента?

      7. Знакомы хоть с работой протокола SSL? С процедурой хендшекинга? Процедурой передачи и проверки Сертификата Web-сервера? С методами выбора криптографических алгоритмов? С методом формирования preMasterKey, MasterKey, KeyBlocks? Как формируются сеансовые ключи шифрования? Как согласовываются режимы работы выбранных криптографических алгоритмов? Как вычисляется стартовый вектор для вычисления хеш-функций для обеспечения целостности передаваемых данных? Знакомы с механизмом строгой аутентификации при использовании клиентских сертификатов? А с процедурой упрощенного хендшекинга, когда используются параметры предыдущей сессии? Да элементарный вопрос - как часто происходит новые согласования сеансовых ключей при передаче через SSL большого объема данных?

      8. Вы знаете КАК работает криптографический аглоритм DES? Вы знаете какие режимы работы бывают у DES'а? Вы знаете что значит 40-битные ключи при использовании протокола DES или RC4? Вы знакомы с методами взлома симметричных криптографических алгоритмов? Вы имели практику ломать хотя бы один блок данных, зашифрованный на 40-битных ключах по протоколу RC4? На какой платформе Вы это делали? Какое спецоборудование Вы использовали? На FPGA или ASIC?

      Господа Анатолий Сапрыкин и Дмитрий Барсуков! Дай Бог если Вы хотя бы читали действительно умные книги и знакомы с работами Кнута. Боюсь, что Ваше обучение основано только на чтении PC Week, Мира ПК и новостных сайтов.

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

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

      Комментарий


      • #4
        Уважаемый Димитрий.
        Своей реакцией на мое письмо Вы еще раз подтверждаете мне и all полную жизнеспособность методики вскрытия iBank, предложенной Анатолием Сапрыкиным.

        У человека, которому четко и ясно указали на его недостатки, есть два пути:
        - Правильный - промолчать и поправить эти самые недостатки.
        - Неправильный - начать сильно нервничать, нести в ответ откровенную чушь (ведь корректных аргументов-то нет) и пытаться всеми правдами и неправдами отмыться.
        Вы выбрали второй, тем самым только подтверждая правоту аргументов Анатолия. Это из психологии. Ну да ладно, постараюсь по существу (хотя его самого в Вашем ответе почти совсем и нет).

        Перечислю свои мысли тезисно:

        1. Если банк имеет честно полученный сертификат, предложенная методика вскрытия iBank не работает.

        2. Если банк раздает свой собственно выданный сертификат клиентам на дискетах, это требует повышенной внимательности клиента (предупреждения браузера как правило носят ТОЛЬКО рекомендательный характер и, вдобавок, довольно часто англоязычны). Таким образом, методика вскрытия работает с учетом простого человеческого фактора невнимательности (НЕ ПУТАТЬ С ВСКРЫТИЕМ ТОЛСТОГО БК - ТАМ НЕВНИМАТЕЛЬНОСТИ НАДО КУДА БОЛЬШЕ). Однако, если все-таки клиент внимателен и корректно инсталлирует каждый раз в браузер сертификат, то и в этом случае методика вкрытия не работает.

        3. Однако, выдача клиентам дискет с сертификатом банка все-таки вызывает у меня БОЛЬШИЕ сомнения:
        - На Вашем сайте www.bifit.com/a-work.html об этом ну ничего не сказано
        - Зачем, спрашивается, Ваши банки предлагают клиенту скачать с их сайта и инсталлировать свой сертификат в браузер клиента? Зачем, если этот самый сертификат выдается на дискете? Чтобы ввести бедного клиента в еще большее заблуждение? Вряд ли.
        А все дело, Димитрий, в том, что это Вы должны предложить своим банкам такую методику, чтобы проблем с секьюрити у них не было.

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

        5. Конкретный банк Ваш я называть не буду - не пытайтесь втравить меня в противостояние с банкирами. Если all захочет, то войдет на Ваш сайт в список Ваших клиентов и все увидит сам.

        6. Вы правильно сказали - вскрыть BS-Client и BS-Defender - это то же самое, что вскрыть толстый БК. Комментарии излишни. Далее Вам останется только привести пример с физическим отъемом дискеты с ключами у бухгалтера.

        7. Теперь Ваши вопросы 1 и 2. Сообщаю Вам и all, что Компания "Банк'с Софт Системс" в 2001 году ПОЛУЧИЛА сертификат разработчика от Thawte. Уверяю Вас, что сделать ту же самую процедуру для компании, открытой в Махачкале на несуществующего г-на Пупкина в Российских условиях труда не составит (не забывайте, Димитрий, мы в России). А годовой сертификат разработчика от VeriSign стоит действительно $900. Всю более подробную информацию на этот счет смогу предоставить в понедельник - получением сертификата занимался другой человек.

        И самое интересное - Ваши вопросы 3-8.
        Как вы заметили, предложенная методика вскрытия не подразумевала СПЕЦИАЛЬНЫХ знаний по секьюрити и уж, тем более, умения программировать на java - только элементарная логика.

        Знаете, ответ на все вопросы один - Я НЕ УМЕЮ ПИСАТЬ java-апплеты и всего другого перечисленного. И что самое главное - УМЕТЬ НЕ СОБИРАЮСЬ И НЕ ХОЧУ. У меня другая работа (см. подпись в конце письма). То, что Вы задаете такие вопросы начальнику отдела продаж, говорит о полном Вашем непонимании основ менеджмента (с таким же успехом Вы можете задать эти же вопросы большинству руководителям IT-департамента среднего и выше банка). Компании, построенные на одной личности, которая и маркетингом занимается, и в банки ездит демонстрировать программу, и задачи ставит, и программирует, НЕ МОГУТ РАЗВИВАТЬСЯ (снова комплимент Вам). Серьезная Компания может существовать только опираясь не на личность, а на построенный менеджмент, на структуру, в которой КАЖДЫЙ ЗАНИМАЕТСЯ СВОИМ ДЕЛОМ. Наши разработчики занимаюся разработкой, кодированием и вопросами секьюрити и не будут тратить свое время на переписку с Вами. Это не их задачи. Я же занимаюсь маркетингом и PR, поэтому и переписываюсь здесь с Вами, по-моему, успешно. Для всего этого моих знаний в предметной области вполне хватает.
        А Вам, Димитрий, я бы посоветовал срочно начать изучение основ менеджмента и психологии, иначе, боюсь, Вы не сможете развивать свою Компанию.

        С Уважением,
        Барсуков Дмитрий,
        начальник отдела продаж
        Компании "Банк'с Софт Системс".


        Комментарий


        • #5
          Коллеги, понимая всю важность данной дискуссии, я предлагаю все же воздержаться от личных негативных выпадов в адрес друг друга. Кому это нужно? Никому. Давайте работать в конструктивном русле.

          Также, хочу развить мысль Димитрия Репана о том, что обсуждение подобных проблем необходимо в открытой форме и на исключительно независимых дискуссионных форумах: либо в соответствующих эхах ФИДО (к сожалению, их все меньше и меньше читают) либо на форумах Банкир.Ру. В рамках этих дискуссий любая компания, работающая на рынке i-banking'а, может включится в диалог и рассказать о своих наработках. Кроме того, друзья, ваши конструктивные рассуждения, затрагивающие все аспекты систем и-банкинга - от юридической до систем безопастности, существенно помогают в выборе тех или иных конкретных решений конечным потребителям данных продуктов. В России свыше 1000 банков, а реально использующих в своем бизнесе системы дистанционного банковского интернет-обслуживания, не так уж и много. Думаю, этот год многое изменит.

          Поддерживания Дмитрия Барсукова, хочу присоединится к его словам -"Каждый должен заниматься своим делом". Поэтому, думаю, на профессиональные вопросы Димитрия Репана с удовольствием ответят разработчики компании "Банк'c Софт Систем". И наоборот.

          Комментарий


          • #6
            Уважаемый Большой Специалист в психологии и управлении производством!

            Я предоставил четкие и вразумительные ответы на описание "атаки" от Анатолия Сапрыкина. Если Вы не можете их понять - это не значит, что ответа нет. И если резюмировать мой ответ, то атака на подмену ресурса возможна при некорректном использовании протокола SSL.

            Специально для Вас, Барсуков Димитрий, с учетом Ваших совершенно поверхностных знаний (Вы сами в этом признались) в области информационной безопасности, но рассуждающего минимум как Доктор технических наук, и видать читающего лекции в Академии ФСБ самим ФАПСИшникам, расшифровываю: "Если банк использует самостоятельно выданный самому себе сертификат, этот сертификат должен быть передан клиенту гарантированным путем".

            Если же банк или клиент не соблюдают элементарных правил работы, то есть:

            - выкладывают на всеобщее обозрение секретные ключи вместе с паролями;

            - допускают исполнение на критически важном оборудовании непроверенных программ;

            - не обеспечивают защищенность средствами Firewall Сервера iBank, Сервера БД iBank'а, Сервера АБС, и т.д., оставляя доступ из Интернет к критически важным ресурсам;

            - некорректно используют другие средства защиты информации, в том числе и криптографические протоколы (не важно какие - SSL, WTLS, PCT, SKIP, IPsec и пр.);

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

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

            Извольте, Барсуков Дмитрий, предоставить слово в данном топике квалифицированным сотрудникам компании БСС, действительно разбирающихся в вопросах информационной безопасности. И впредь не обсуждать темы, в которых Вы совершенно не разбираетесь.

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

            Комментарий


            • #7
              Еще пару заметок в догонку, так сказать для полноты картины.

              1. Анатолий Сапрыкин, по всей видимости сотрудник компании "Банк'с Софт Системс", так как именно он начал цитирование в топике www.bankir.ru/ubb/Forum11/HTML/000058.html ранее разсылаемого опуса, утверждает следующее:

              BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Многие из клиентов Компании "Бифит" (www.bifit.com/c-clients.html) не приобретают сертификаты мировых сертификационных центров, а используют самим себе выданные сертификаты. Оно и понятно - сертификат, например, Verisign, стоит $900 в год - именно на такую сумму, даже без учета временных и организационных затрат на получение сертификата, возрастет стоимость владения iBank.[/quote]

              Далее Барсуков Дмитрий, по его заявлению являющийся руководителем отдела продаж компании "Банк'с Софт Системс", уже в текущем топике говорит, что:

              BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR> годовой сертификат разработчика от VeriSign стоит действительно $900[/quote]

              Простите, уважаемые господа из компании "Банк'с Софт Системс", но ни это ли еще одно подтверждение Вашего передергивания фактов, Вашего "честного" стиля маркетинга? Или это всё-таки так нелюбимый Вами вопрос о Вашей квалификации и компетентности?

              Сначала в документе от "Банк'с Софт Системс", цитируемый Анатолием Сапрыкиным, утверждается что 900$ надо потратить банку на приобретение Сертификата X.509 для банковского Web-сервера, а потом выясняется, что у VeriSign 900$ стоит не Сертификат для Web-сервера, а Сертификат разработчика!!! Кстати, что это за такой Сертификат разработчика, полученный компанией БСС у компании VeriSign Inc. за 900$?!

              На сколько мне известно, существуют следующие Сертификаты разработчиков:
              - Microsoft Authenticode Digital ID
              - Netscape Object Signing Digital ID
              - Microsoft Office 2000 and VBA Signing Digital ID
              - Marimba Digital ID
              - Macromedia Shockwave Digital ID
              выдаваемые компанией VeriSign сроком действия на один год. Стоят они по 400$ каждый. Откуда 900$ ??? Или компания "Банк'с Софт Системс" сумела договориться с VeriSign inc. об эксклюзивных ценах ?!

              Для справки, Сертификат для Web-сервера, выдаваемый компанией VeriSign сроком на один год, стоит 295$.

              2. Барсуков Дмитрий в пылу дискуссии, уже не зная что отвечать, начал аппелировать к размеру компании, к менеджемнту в компании, к количеству сотрудников в штате компании, к психологии. В свете затронутых вопросов хотел бы отметить, что компания "Банк'с Софт Системс" достаточно сильно диверсифицирует свой бизнес, выходя на всё новые рынки и начинает работать по всё новым, не свойственным ранее ей, направлениям. Естественно, что при такой стратегии развития компании, штат сотрудников непомерно вырастает, и компания становится тяжело управляемой (о чем собственно и сообщал Барсуков Дмитрий), и практически начинает превращаться в холдинг.

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

              Затрагивая эти вопросы, я очень хотел бы узнать у Барсукова Дмитрия, сколько сотрудников компании "Банк'с Софт Системс" занимается проектирование, разработкой, кодированием, тестированием и сопровождением конкретно Вашего продукта "Интернет-Клиент"? Каково ядро конкретно этой команды? Только не надо сюда приплюсовывать всех тех сотрудников, которые в дополнение занимаются еще и толстым BS-Client'ом, телефонным банкингом, проектом с автоматизацией казначейства и пр., а также весь отдел маркетинга и продаж, бухгалтерию и т.д.

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

              Комментарий


              • #8
                Уважаемый sharpcat.
                В пылу дискуссии чуть не пропустил Ваш вопрос.
                ------------------------------
                Реальная конфликтная ситуация: клиент отправил платеж по системе
                BS-Client на сумму X. А платеж не ушел вовремя из банка
                (попросту был потерян). Клиент попадает на штраф Y.
                Вопрос: с чем клиент придет в суд, отстаивать свою позицию?
                ------------------------------
                Отвечаю.

                Есть два вида работы "тонкого" клиента в BS-Client - на стороне клиента ведутся логи или не ведутся. Устанавливается опционально, как настройками самого банка в дистрибутивах "по умолчанию", так и в дальнейшем самим клиентом. Определяется договором банка и клиента. В любом варианте разрешение конфликтной ситуации построено на следующем:
                1. BS-Defender как в банке, так и у клиента подписывает и шифрует средствами внешней строгой криптографии (хоть Верба-OW) каждую html-страницу и html-запрос.
                2. BS-Defender в логах (либо только в банке, либо еще и у клиента - см. Выше) хранит всю историю обмена подписанными и защифрованными html-страницами и html-запросами между банком и клиентом.
                3. Каждый свой документ клиент отдельно подписывает своей ЭЦП (как в толстом БК).
                4. Юридически значимым является ЛЮБОЙ целостный фрагмент информации, подписанный ЭЦП абонента. Это относится как к собственно документу, так и к html-странице и html-запросу. Данное положение фиксируется в договоре клиента с банком.
                Взаимодействие банка и клиента в системе "интернет-клиент" при подготовке клиентом документа в банк выглядит следующим образом (для уменьшения информации рассматриваю специально только фрагмент подготовки и отправки документа):
                1. В браузере клиент подписывает документ средствами ЭЦП (любой внешней, поставляется с BS-Defender-ом), затем передает в банк подписанную и защифрованную (BS-Defender) html-страницу, содержащую подписанный документ.
                2. Банк, проверив под страницей подпись и расшифровав ее (BS-Defender), интеллектуально разбирает содержимое страницы, затем в "сервере ДБО" под собственно документом проверяется ЭЦП.
                3. При успешной проверке ЭЦП и прочих проверках (коррестность заполнения и др.) банк передает клиенту ответную html-страницу, содержащую изменение статуса данного документа на "принят".
                4. Соответственно, в банке фиксируются времена происхождения следующих фактов - получения от клиента html-страницы с документом, проверка документа (и его ЭЦП) в "сервере ДБО" в банке, отправка клиенту html-страницы, содержащей изменение статуса документа на "принят".
                5. У клиента (если включена журнализация), фиксируются моменты отправки в банк html-страницы с документом и получение из банка html страницы со статусом документа "принят".
                Поскольку все описанные в п.4 и 5 объекты информации (html-страницы и сам документ) хранятся в логах вместе с наложенными ЭЦП формирующей стороны (то есть, по условиям договора являются юридически значимыми), эти самые объекты информации и будут являться доказательным материалом в суде.
                Если банк, как неоднократно указывал Димитрий Репан, сознательно не шлет клиенту подтверждение на документ (допускаю, хотя и с трудом, что в случае серьезной подготовки администратора в BS-Client это возможно), то клиент визуально видит отсутствие изменения статуса документа. Если документ ему действительно важен, он это отследит, а на рассказы банка и сбоях в системе отреагирует соответственно, например, привезет в банк документ ногами и сделает соответствующие выводы.
                А вот если банк прислал клиенту подтверждение, но документ не провел, клиент может смело идти в суд с логами. Если клиент боится, что банк свои логи может уничтожить, он ведет собственные логи, содержащии документы с ЭЦП банка, кои и будут доказательствами в суде.

                Про сертификаты. Репану Димитрию.
                Для того, чтобы клиент банка, эксплуатирующего iBank, мог корректно использовать криптографический протокол SSL (без угрозы вскрытия из-за невнимательности), банку необходимо преобрести SSL-сертификат одного из мировых сертификационных центров, например, Verisign. А 128-битный SSL-сертификат SecureSite Pro в Verisign стоит $895/год. Причем угроза вскрытия из-за невнимательности все равно остается, хотя и делается менее серьезной.
                Что же касается Компании БСС, то, настоятельно Вам, Димитрий, рекомендую хотя бы внимательно читать письма, на которые Вы отвечаете. М.б., флейма будет меньше (хотя в Вашем случае и сомневаюсь). Компания "БСС" получила сертификат разработчика (еще раз повторю), Thawte. Это сертификат Microsoft Authenticode Digital ID.

                Про штат Компании ╚Банк▓с Софт Системс╩.
                Поскольку система ╚Интернет-клиент╩ не работает без сервера ДБО, приведу всю группу разработки и поддержки конкретно по проекту BS-Client:
                ╥ Департамент разработки (кодирование, техническая и частично аналитическая постановка задач) √ 15 человек, из них именно интернет-проект (без сервера ДБО) √ 7 человек.
                ╥ Департамент эксплуатации (сборки, прикладное кодирование √ BS-Script, внедрение, сопровождение, частично аналитическая постановка задач) √ 29 человек.
                Маркетинг, бухгалтерия, административно-хозяйственная части и руководство не включены.

                На Ваш, Димитрий, выпад о нашей ╚закрытости╩ сообщаю all и Вам, что месяц назад мы сделали рассылку по всем без исключения банкам описания системы и ДЕМОНСТРАЦИОННОЙ ВЕРСИИ (реальная версия на 2 клиента, в том числе и интренет-клиента). Так что, all, смотрите, щупайте, задавайте вопросы. У нас секретов нет. Если до кого почта не дошла, запросите материалы, мы найдем способ передать их Вам.

                И последнее. Димитрий, общаясь с Вами, я просто горжусь собственной выдержкой. И как бы мне это ни было приятно, все же всему есть предел. Мы не на базаре. Поэтому я дискуссию буду продолжать только по существу. Любые личные претензии как ко мне лично, так и к компании БСС в целом прошу передавать мылом.

                С Уважением,
                Барсуков Дмитрий,
                начальник отдела продаж
                Компании "Банк'с Софт Системс".

                Комментарий


                • #9
                  Уважаемый Барсуков Дмитрий!

                  Следуя Вашему призыву вести максимально конструктивную полемику, и не допускать впредь выпадов в отношении компаний и друг друга, предлагаю Вам или техническим специалистам компании БСС, предоставить подробное техническое описание алгоритма работы BS-Defender. Как на стороне Web-сервера, так и на стороне Web-браузера. Ваше последнее сообщение только породила массу вопросов.

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

                  В принципе, если у Вас нет публичного технического описания работы BS-Defender - ничего страшного. Главное желание. Вполне разумно в таком случае построить наше общение по принципу вопрос-ответ, и уже потом, на основе полученого FAQ'а, Вам будет на порядок легче сформировать ТО. Со своей стороны, я постараюсь быть максимально корректным и не задавать вопросов, провоцирующих какой-либо флейм.

                  1. В общем случае, существует два варианта реализации защиты. Первый - Ваш механизм работает поверх HTTP. Второй - Ваш механизм работает по аналогии с SSL, то есть в виде прослойки между HTTP и TCP.

                  В Вашем письме Вы четко указываете, что BS-Defender "...как в банке, так и у клиента подписывает и шифрует ... каждую html-страницу и html-запрос". Следовательно всё-таки первый вариант - "поверх HTTP".

                  Тогда давайте по порядку.

                  1. Как работает BS-Defender со стороны Web-браузера? При беглом ознакомлении в одном из банков, где стоял BS-Defender - работает как локальный прокси-сервер. То есть Web-браузер настраивается на работу через IP-адрес типа 127.0.0.1 и какой-то определенный порт.

                  1.1. Как осуществляется подпись HTTP-запроса типа GET и POST и передаваемых в запросе данных(в заголовке для GET, в теле самого запроса для POST)? Для запроса POST подписываются только содержание полей, или и наименования полей HTML-формы?

                  1.2. Как передается сама ЭЦП и идентификатор ключа, которым был подписан HTTP-запрос?

                  1.3. Добавляете ли Вы в заголовок HTTP-запроса какой-то уникальный идентификатор для каждого запроса (с целью защиты от навязывания злоумышленником ложной HTML-страницы)?

                  1.4. Как осуществляется шифрование http-запроса?

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

                  1.6. Что конкретно шифруется? Вообще весь HTTP-запрос? Только данные в запросе? Или еще и заголовок?

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

                  1.8. Как передается клиенту открытый ключ шифрования? На дискете вместе с ПО BS-Defender? Как происходит обновление этого ключа?

                  1.9. Сохраняются ли у Клиента в журнале, все отосланные и подписанные HTTP-запросы?

                  2. HTML-страницы формируются исключительно Web-приложением. Web-сервер же через протокол HTTP передает HTML-страницу клиенту. Соответственно BS-Defender должен непосредственно участвовать в формировании HTML-страницы, фактически выполняя на последней стадии ее формирование следующие задачи - ЭЦП и шифрование страницы, и в таком виде отдает Web-серверу. А уже Web-сервер по обычному протоколу HTTP передает Web-браузеру. Или же на серверной стороне BS-Defender также работает как прокси сервер? Тогда как при проверке подписи клиента передаются Web-приложению параметры подписи (сама ЭЦП и идентификатор ключа)? Передается ли Web-приложению через какую-то переменную список полей из html-формы в http-запросе, которые были подписаны на стороне клиента?

                  В общем вопросов на самом деле масса - они только начались
                  Получив хоть какую-то часть однозначных ответов, уже можно понять алгоритм работы BS-Defender'а. Допускаю также, что мои вопросы не имеют ничего общего с действительностью и всё устроено совершенно по-другому. Тогда уж сами попробуйте рассказать, как работает BS-Defender.

                  И еще одно замечание. Уверен, что лучше чем коллеги-конкуренты, которые будут "носом рыть землю" в поисках прорех в продуктах конкурентов, которые имеют максимальную мотивацию , которые готовы привлекать и финансировать внешних экспертов, никакое спецведомство или акадимический институт с тридцатью Лицензиями и Сертификатами, не проведет такой детальный и тщательный анализ. Разве что на подобное способны еще страховые компании, которые берутся страховать риски при использовании того или иного решения.

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

                  Комментарий


                  • #10
                    Рад, Димитрий, что что мы перешли на конструктивный диалог. Считаю, что это поможет нам в развитии своих технологий и, в то же время, сделает наши с Вами технологии более открытыми для потенциальных пользователей.

                    Итак, ответы.
                    1. Как работает BS-Defender со стороны Web-браузера? При беглом ознакомлении в одном из банков, где стоял
                    BS-Defender - работает как локальный прокси-сервер. То есть Web-браузер настраивается на работу через
                    IP-адрес типа 127.0.0.1 и какой-то определенный порт.

                    Действительно BS-Defender является локальным прокси-сервером.

                    1.1. Как осуществляется подпись HTTP-запроса типа GET и POST и передаваемых в запросе данных(в заголовке
                    для GET, в теле самого запроса для POST)? Для запроса POST подписываются только содержание полей,
                    или и наименования полей HTML-формы?

                    В обоих случаях подписывается и шифруется тело HTTP-запроса полностью.

                    1.2. Как передается сама ЭЦП и идентификатор ключа, которым был подписан HTTP-запрос?

                    ЭЦП и идентификатор ключа передаются в теле запроса в зашифрованном виде.

                    1.3. Добавляете ли Вы в заголовок HTTP-запроса какой-то уникальный идентификатор для каждого запроса
                    (с целью защиты от навязывания злоумышленником ложной HTML-страницы)?

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

                    1.4. Как осуществляется шифрование http-запроса?

                    Шифруется тело HTTP-запроса и уникальный идентификатор запроса cредствами выбранной криптобиблиотеки (той же Вербы или другой) на открытом ключе адресата.

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

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

                    1.6. Что конкретно шифруется? Вообще весь HTTP-запрос? Только данные в запросе? Или еще и заголовок?

                    Шифруются только передаваемые данные - тело HTTP-запроса. Шифруются как HTTP-запросы так и HTTP-ответы.

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

                    Не используется.

                    1.8. Как передается клиенту открытый ключ шифрования? На дискете вместе с ПО BS-Defender? Как происходит обновление
                    этого ключа?

                    Первый раз на дискете. Перегенерация ключей описана в п.1.5.

                    1.9. Сохраняются ли у Клиента в журнале, все отосланные и подписанные HTTP-запросы?

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

                    2. HTML-страницы формируются исключительно Web-приложением. Web-сервер же через протокол HTTP передает HTML-страницу клиенту.
                    Соответственно BS-Defender должен непосредственно участвовать в формировании HTML-страницы, фактически выполняя на
                    последней стадии ее формирование следующие задачи - ЭЦП и шифрование страницы, и в таком виде отдает Web-серверу.
                    А уже Web-сервер по обычному протоколу HTTP передает Web-браузеру. Или же на серверной стороне BS-Defender также работает
                    как прокси сервер? Тогда как при проверке подписи клиента передаются Web-приложению параметры подписи (сама ЭЦП и идентификатор
                    ключа)? Передается ли Web-приложению через какую-то переменную список полей из html-формы в http-запросе, которые были
                    подписаны на стороне клиента?

                    На серверной стороне BS-Defender также работает как Proxy-сервер. Однако стоит различать подпись HTTP-страницы
                    и документа, например, платежки. Подпись платежки осуществляется с помощью ActiveX на клиенте. Проверка подписи
                    под документом осуществляется сервером ДБО в банке. После прохождения BS-Defender-а и web-приложения в банке
                    документ с ЭЦП клиента попадает в сервер ДБО, где эта ЭЦП и проверяется. Сама подпись является одним из полей документа.
                    Web-приложению и, далее, серверу ДБО, передается идентификатор ключа полученный из операции проверки подписи
                    HTTP-запроса.

                    С Уважением,
                    Барсуков Дмитрий,
                    начальник отдела продаж
                    Компании "Банк'с Софт Системс".

                    Комментарий


                    • #11
                      Хммм, уважаемый Дмитрий Барсуков хороший совет на будущее - прежде чем писать что-либо про криптографию ознакомьтесь хотя б с этой замечательной книжкой :
                      Брюс Шнайер "Прикладная криптография". http://ziss.stup.ac.ru/wmaster/books...o/3/index.html
                      C уважением,
                      Руководитель Управления перспективных разработок компании "БИФИТ"
                      Михаил Дударев.

                      Комментарий


                      • #12
                        Уважаемый Барсуков Дмитрий!

                        Я даже не знаю с какой стороны подойти к Вашим ответам на мои вопросы о принципах внутренней работы BS-Defender'а. Было бы правильнее во всех смыслах всё же подключить к ответам Ваших технических специалистов. Уверен, что многие, как бы помягче сказать, некорректности в Ваших ответах, были бы устранены и общая картина получилась бы максимально приближенной к действительности.

                        С уважением, Репан Димитрий
                        Компания "БИФИТ"

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

                        Комментарий


                        • #13
                          Господа, приглашаю посетить сайт компании разработчика систем автоматизации предприятий различной финансовой направленности "Проект Р5. На сайте имеется информация о разработках интересных автоматизированных систем. Многие из них успешно работают в крупных компаниях и банках уже достаточно давно. Адрес сайта www.r5pro.ru

                          Комментарий

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

                          Свернуть

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

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