Bankir.Ru
5 декабря, понедельник 21:42

Объявление

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

Безопасность Интернет-банков от Александра Герасимова

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

  • Безопасность Интернет-банков от Александра Герасимова

    Несколько вопросов. Насколько я понял, у клиента есть цифровой сертификат (digital ID), который он использует для SSL соединения в режиме взаимной аутентификации сервера и клиента. Кроме того, для аутентификации клиента используется пароль, SHA от которого хранится в банке. А платежное требование подписывает цифровой подписью при помощи того же ключа, который используется для аутентификации клиента.
    Вопросы:
    1.Зачем использовать для аутентификации клиента и пароль и сертификат?
    2.Вы сами заверяете сертификаты клиентов (ну не в VeriSign же их гнать) ?
    3.Не боитесь ли вы держать базу прохешированных паролей. Атаку по словарю еще никто не отменял, не лучше ли хранить HMACи от паролей, вычисленные на секретном ключе.
    4.Что за софт реализует на клиенте цифровую подпись. В стандартном IE до сих пор нет функции для подписи параметров HTTP запроса.

  • #2
    Здравствуйте, Максим!
    Я в статье описал технологию работы без конкретностей! Но я могу объяснить как работает реальная система и отвечу на Ваши вопросы:
    1. Пароль и сертификат используется для более надежной защиты (в стадии верификации клиента), не более того! Что на самом деле подтверждает сертификат? Он только факт, что это именно то ПО, которое было выдано банком. Т.е. прошла идентификация грубо говоря файлов. А еще нужна идентификация личности клиента, для этого и используется пароль.
    2. Да, сертификаты заверяются в банке. Однако для этой процедуры необходима верификация 3-ей стороны (например VeriSign) либо установленное в банке специализированное ПО (например от СигналКома).
    3. Не понимаю вопроса! Верификация клиента происходит по 2-м составляющим: сертификату и паролю. При этом пароль хранится в базе данных банка в зашифрованном виде - шифр длиной 160 битов создается с помощью алгоритма SHA, таким образом, что никто кроме клиента не знает пароля, поскольку он нигде не хранится в явном виде!!!
    4. ЭЦП формируется при помощи специализированного ПО от компании Сигнал Ком. Это ПО обеспечивает:
    - аутентификацию клиента,
    - защиту потока информации между клиентом и сервером,
    - формирование электронной цифровой подписи (ЭЦП) под электронными документами, обрабатываемыми в системе.

    Александр

    Комментарий


    • #3
      Добрый день!
      После прочтения статьи хотел бы уточнить у участников Форума пару вопросов, достаточно весомых на мой взгляд для использования Интернет √ технологий в банковской области.
      1. В стандартных браузерах функция ЭЦП не реализована, т.е. для соответствия электронного документа требованиям ЦБ эту функцию придется реализовывать в ╚специальном ПО╩, закачиваемом в виде апплета либо используя plug-in▓ы. Каким образом при использовании SSL-протокола для скачивания апплета с сайта банка (как, например, это сделано в обсуждаемой здесь системе iBank)осуществляется протоколирование того, что происходит в рамках сессии, в том числе и при закачке этого ╚спец ПО╩, что немаловажно при разборе конфликтных ситуаций между банком и клиентом? Иными словами, как при этом банку обезопасить себя от необоснованных претензий со стороны клиента о ╚троянском╩ апплете. Да, апплет подписан разработчиком, но клиент говорит √ ╚в предыдущем сеансе я скачал апплет, забил платежку, подписал, потом выяснилось, что я подписал ╚троянские╩ реквизиты получателя. В текущем сеансе я скачал новый апплет и Вы можете проверить на нем подпись разработчика. Но предыдущего-то апплета уже нет.╩ Как при этом банку доказать, что клиент говорит неправду и как это можно отразить в заключаемом между банком и клиентом договоре?
      2. Насколько уместно присутствие третьего лица, выдающего сертификат (типа VeriSign), во взаимоотношениях банка и клиента. Поясню. В случае электронной коммерции банк при оплате по кредитным картам никак не может заранее знать плательщиков, поэтому присутствие третьей сертифицирующей стороны необходимо. В действительности же, присутствие такой стороны в случае, когда банк и клиент прекрасно знают друг друга (как минимум при составлении договора на открытие счета и/или передаче банковских карточек) и могут официально обменяться открытыми ключами при встрече, только увеличивает риск утечки или фальсификации информации.
      С уважением, Анатолий
      a2000_S@mail.ru

      Комментарий


      • #4
        Здравствуйте, Анатолий!
        Я позволю себе высказать свои соображения по Вашему вопросу относительно ╚специального ПО╩. Я бы писал в договоре, что клиент сам идет в магазин, покупает там любой понравившейся ему апплет, реализующий конкретные алгоритмы цифровой подписи и представляющий результат в стандартном формате, например в pkcs#7. Проблема соответствия ПО декларированным функциям должна решаться без участия Банка. Все остальное, на мой взгляд, не серьезно. Ну а как бывает на самом деле, думаю, всем известно. Наиболее болезненно встает эта проблема при разрешении споров по подводу цифровой подписи. В договоре обычно пишется некий бред про гипотетическое ╚эталонное ПО╩, которое ╚очень хорошо╩ умеет проверять подпись ну и т.д.
        В действительности же, разработчик имеет все возможности для злоупотреблений, а риски делят между собой банк и клиент, в удобной банку пропорции.

        Комментарий


        • #5
          Здравствуйте, Анатолий!

          Здесь, а именно в моей статье, описана НИКАК НЕ система iBank от Бифита (разработчик Репан Дмитрий).
          В этой статье я описывал технологию защиты в системе "ИНТЕРНЕТ-БАНК" (совместного проекта банка "Северная Казна"(г.Екатеринбург) и компании CSBI EE(г.С.-Петербург)), которую в данный момент продвигают на рынок компании Хост (г.Екатеринбург) и CSBI EE. Поэтому никакого аплета наш софт не скачивает с сервера, что исключает возможность фальсификации подписи. Как я уже упоминал, наш программный продукт использует решение от Сигнал-КОМ ("Inter-PRO"), которое состоит из 2-х программных модулей:
          1. "Inter-PRO Server" √ размещается в банке на стороне Web-сервера системы,
          2. "Inter-PRO Client" √ размещается на стороне Web-браузера клиента.

          Защищенное взаимодействие клиента с сервером банка через сеть Интернет осуществляется посредством модуля "Inter-PRO Client", который устанавливает с модулем "Inter-PRO Server" соединение (поддерживаемое протоколом SSL) обеспечивающее:
          1. аутентификацию сервера банка на стороне клиента с помощью сертификата открытого ключа Web-сервера;
          2. аутентификацию клиентов на стороне банка с помощью сертификатов открытых ключей пользователей;
          3. шифрование трафика между клиентом и банком на базе криптографических алгоритмов без экспортных ограничений (зарубежные алгоритмы шифрования с длиной ключа 128 бит и отечественный алгоритм ГОСТ 28147-89/3/4 с длиной ключа 256 бит);
          4. формирование модулем "Inter-PRO Client" ЭЦП под электронными формами документов, заполняемыми пользователями (алгоритм RSA без экспортных ограничений на длину ключа);
          5. автоматическую проверку ЭЦП модулем "Inter-PRO Server".
          В системе "Inter-PRO" формирование секретного и открытого ключей клиента или сервера осуществляется с помощью встроенной, соответственно в клиентский или серверный модули, процедуры генерации ключей. На основе открытого ключа формируется запрос сертификата, который передается Сертификационному Авторитету (СА) в Сертификационный Центр. В роли Сертификационного Центра может выступать Сертификационный Центр банка, организованный на базе программного обеспечения "Notary-PRO". Сертификационный Центр "Notary-PRO" представляет собой программный комплекс, работающий под управлением Windows 95/NT и предназначенный для регистрации, хранения и выдачи сертификатов абонентам-участникам защищенных систем передачи данных (включая Интернет/Интранет), построенных на основе криптографических процедур с открытым распределением ключей. Форматы сертификатов открытых ключей соответствуют Рекомендациям ITU X.509.
          С помощью Сертификационного Центра банк может самостоятельно формировать необходимое количество клиентских и серверных сертификатов. При этом важно, что банку не придется обращаться к сторонним сертификационным центрам, и ВСЯ ИНФОРМАЦИЯ о сертификатах будет храниться в банке и будет недоступна третьим лицам. Сертификаты, выпускаемые "Notary-PRO", могут быть использованы как с программными продуктами защиты Интернет/Интранет-приложений разработки Сигнал-КОМ, так и с продуктами независимых (в т.ч. зарубежных) производителей.

          Думаю этот ответ снимет вопросы по моему программному продукту. Теперь давайте посмотрим, что ответит Репан Дмитрий по поводу защиты в его системе от ╚троянского╩ апплета??? Мне и самому это интересно!

          Герасимов Александр
          Нач.отдела банковских
          технологий компании Хост
          A.Gerasimov@hostco.ru

          [Сообщение отредактировал Alexander (исправлено 14-09-2000).]

          Комментарий


          • #6
            День добрый,Александр!
            Прошу прощения за неточность - "здесь" относилось не к статье,а к форуму Расчеты/Internet-Banking в целом .Т.е. я совершенно не против того, чтобы на машине клиента что-то устанавливалось, особенно если этому ПО достаточно настоек прописанных Банком по умолчанию, вопрос в первую очередь относится именно к тем системам, в результате деятельности которых на клиентской машине вообще ничего не остается.
            С уважением, Анатолий Сапрыкин
            a2000_S@mail.ru

            Комментарий


            • #7
              "Дайте мне точку опоры и я переверну мир!" Древняя и бородатая фраза.
              Уважаемое сообщество поправит меня, если я заблуждаюсь, но хочу обратить внимание на несколько, как мне кажется существенных, моментов. Исходные предпосылки:
              1. При совершении значимых, в том числе и юридически значимых операций в Интернет (или других компьютерных сетях, в том числе и корпоративных)пользователь использут специализированное ПО, которое создает на компьютере пользвателя предметно ориентированную среду. Как это ПО туда попадает - вопрос технологии.
              2. Пользователь не имеет профессиональных знаний в областях защиты информации, программирования, юридических. Он доверяет профессионалам в соответтвующих областях часто не фиксируя уровень этого доверия в материальном исчислении. Пользователь неспособен определить качество и состояние используемого ПО.
              3. Открытые и корпоративные системы (в том числе и платежные) содержат элементы недоступные для контроля администратору сети. Я не говорю про закрытые корпоративные сети, в которых при помощи НСД создается доверенная программно-аппаратная среда.

              Что из этого вытекает? А прежде всего то, что ВСЕ системы Internet-Banking (и не только они) опираются на доверие к некоторым элементам системы. Прежде всего к тому, что установлено на стороне клиентаи не может быть полность контролируемо администратором безопасности. Это и есть та самая "точка опоры". Независимо от технологии мы опираемся на софт, уже имеющийся на стороне клиента откуда-то полученный и кем-то поставленный. Будь-то "толстый клиент" из Банка или Explorer от поставщика компьютера. Кроме того, есть возможность воздействия на эту "точку опоры" без ведома клиента как работников той же организации, так и посторонних лиц через коммуникации. Ведь компьютер, на котором работает клиент, используется не только для проведения платежей. И кто может гарантировать, что Explorer после просмотра очередного сайта (например, этой конференции ) все еще тот самый Explorer, который был до этого? А ведь на это опирается проверка загружаемого софта. Например, Java технология подразумевает "правильность" java-машины, корректность реалиации SSL в браузере... Ну и наконец, что все это корректно работает в конкретном программно-аппаратном окружении. И это при всех разновидностях и ServicePack-ах. Не примите за наезд на конкретную технологию. Это касается и PlugIn, и ActiveX...
              Рискуя прослыть консерватором, высказваю мнение о том, что больший уровень доверия заслуживают программы, разработанные специально для создания предметно ориентированной среды и использующие как можно меньше стандартных модулей на стороне клиента. Конечно, никто не защитится от BackDoor, сделанных разработчиками продукта. Это тоже надо учитывать и, может быть, ориентироваться в первую очередь на разработчиков, работающих на рынке достаточно давно. И чем более публично использование продукта, тем больше возможностей у разработчика "напакостить" пользователям своего ПО. Поэтому и вызывают подозрения интернет-приложения, ориентированные на реализацию реальных бизнес поцессов, раздаваемые бесплатно всем желающим. Ориентация на то, что русский IT-специалист мимо халявы не пройдет.
              Идеал - "голое железо" с доверенной ПЗУ удаленной загрузки на стороне клиента. В реале используются 2 варианта:
              - на сторону клиента внедряется (самоустанавливается) некоторое ядро безопасности, которое и обеспечивает в дальнейшем доверие ко всему загружаемому извне;
              - используется то, что представляется Explorer-ом (или другим браузером) и правдоподобно откликается на соответствующие запросы.
              В первом случае уровень доверия определяется качеством устанавливаемого софта, его способностям противостоять (или хотя бы определять) несанкционированным модификациям и контролировать состояние программного окружения. Во втором случае, опираясь на набор правдоподобных (или нет) ответов делается вывод о возможности работы загружаемого софта. Вывод о достоверности загружаемого делается не доверенным софтом, а тем, который правильно реагирует на запросы.
              Однако при выборе тех или иных систем, как мне кажется, следует рководствоваться не только вопросами безопасности, а во главу угла ставить экономическую целесообразность внедрения системы. Опираясь на приведенные в начале предпосылки можно найти много вариантов "обхода" рисков эксплуатации системы. Самый простой вариант - построить договор с клиентом так, что банк всегда прав. Для массового клиента это пройдет. Другой вариант - "запрещать и недопущать". Т.е. сформировать жесткие требования по безопасности и создать доверенную среду на стороне клиента. Конечно,это потеря мобильности и некоторое усложнение внедрения и сопровождения. Однако это с лихвой окупается существенным снижением рисков тем более, что практика оказывает, что более 80% клиентов, которые приносят реальные доходы банку,квазистационарны, т.е. работают с фиксированного перечня компьютеров. Еще вариант - страхование ответственности участников системы, в том числе и производителя. А, также, проведение независимых экспертиз и сертификаций (не путать с сертификацией ФАПСИ и др.!). Здесь можно установить баланс мобильность-доходность с учетом реальных условий эксплуатации системы. При отсутствии соответствующего законодательства федерального уровня этот вариант возможен только для корпоративных систем e-commerce, но вполне подходящ для платежных систем банков.

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

              ------------------
              С уважением,
              Митричев Илья
              ilya@rfc.ru, ilya@mail.transit.ru
              ICQ 13530413
              С уважением,
              Митричев Илья
              ilya@rfc.ru, ilya@mail.transit.ru
              ICQ 13530413

              Комментарий


              • #8
                Браво, Илья, Браво!!! Самый трезвый взгляд на жизнь!!! :-))

                Вы совершенно верно разбили разработчиков таких систем на 2 лагеря. Одни используют специализированное ПО, другие пишут нечто свое (java-апплеты) для защиты системы от несанкционированного доступа. Тут, как говорится, палка о двух концах, одно в угоду другому! Но я все же счтаю, что безопасность системы куда важнее мобильности и еще чего либо!!!

                p.s. кстати мне эта идея раздачи бесплатного iBanka тоже сразу не понравилась! Доверяй, но проверяй! :-))

                Александр

                Комментарий


                • #9
                  Не рискну говорить от имени всего уважаемого сообщества, но от своего имени постараюсь критически проанализировать реплику Ильи Митричева. Жанр ╚рассуждения о безопасности e-business╩ того требует. Даже в самых трезвых и логичных взглядах полезно поискать слабые места. Итак, поехали:
                  ╚┘больший уровень доверия заслуживают программы, разработанные специально для создания предметно ориентированной среды и использующие как можно меньше стандартных модулей на стороне клиента ┘ Идеал - "голое железо" с доверенной ПЗУ удаленной загрузки на стороне клиента■
                  Голос за кадром: Корпоративные информационные системы (КИСы) и мэйнфреймы, всемирная история, Банки не сумевшие войти в Интернет.
                  При чем здесь КИСы скажу чуть позже, давай те поразбираемся с Интернет. Что такое Интернет? Я вполне серьезно спрашиваю, господа. Кто-нибудь помнит определение Интернет? :-) Берем rfc2026, читаем: ⌠Internet это свободно организованное, международное сообщество автономных взаимосвязанных сетей, обеспечивающих host-to-host взаимодействие, в силу добровольного, строгого соблюдения открытых протоколов и процедур, зафиксированных в стандартах Интернет (собственно в RFC)■. Почувствуйте главное: автономные сети, предоставляют своим участникам возможность взаимодействовать друг с другом только потому, что поддерживают одинаковые протоколы и форматы. Никто не спрашивает у партнера по взаимодействию: ╚какая у тебя операционная система, дружок?╩, ╚какой софт ты используешь: PGP или Вербу-О╩. Никто не приходит к тебе и не говорит ╚подвинься глупый юзер, пришли мы √ высокие профессионалы, сейчас мы создадим на твоем компьютере правильную предметно ориентированную среду╩. Только жесточайшее следование правилу: ╚всем должно быть наплевать, какой у меня компьютер, ОС, прикладной софт главное, что я строго поддерживаю стандартные протоколы взаимодействия╩ позволяют строить такие большие сети как Internet. Иначе, есть дорога, ведущая только назад, в кошмар корпоративных систем. Существенные моменты систем в этой парадигме:
                  1.Внедренное однажды √ работает вечно. (Большинство таких систем √ мертвые системы. Пользовать не может развивать их самостоятельно, их практически невозможно апгрейдить, т.к. делать это надо единовременно для всех клиентов. Вы не можете отдать внедрение и сопровождение таких систем на аутсорсинг, ну и т.д.)
                  2.Система хороша для всех пользователей в целом, но не отвечает требованиям ни кого конкретно. (разработчик закладывался на dial-up, а у вас выделенка; это у вашего соседа 80386 и Win3.0, но у вас-то давно W2K и т.д. Ни фига, разработчик сказал, что минимальные требования IE3.0 и никогда не увидите вы в его программе фич от Ie5.5).
                  3.Безопасность √ проблема администратора. (Вы верите в то, что руки бывают такими длинными, чтоб дотянутся от сервера до клиентского компьютера и выдернуть нелегально повешенный на COM порт модем?)
                  4.Эксклюзив. Купив у нас систему сегодня, вы будете кормить нас всю оставшуюся жизнь. Потому как никто кроме нас не сумеет внести в систему необходимые вам изменения.

                  Каким же мне видится нормальный Интернет-Банк. Форматы электронных документов: платежных требований, выписок по счету, справочников и т.д. у всех одинаковые, разработаны авторитетным объединением банков, разработчиков ПО и клиентов(!), например с использованием языка XML и утверждены ЦБ. Передача таких документов производится поверх HTTP или в виде сообщений электронной почты по SMTP. Любой софт полностью поддерживает и форматы и протокол передачи, и если мне, к примеру, не нравится решения от RFC, то я независимо от того нравится это моему банку или нет, иду и покупаю iBank, а если мне не нравится и iBank я иду, например в BSS, и разрабатываю у них софт себе на заказ. Цифровая подпись √ это не закон, а формат аналогичный RSA-шным PKCS и если я не хочу покупать Вербу-О, а хочу посадить сто китайцев с логарифмическими линейками и заставить вычислять их цифровую подпись вручную, то это мое неотъемлемое право. А вот закон должен обязывает Интернет-магазины (тех, кто таковыми добровольно назвался) отпускать товары и услуги по получению заверенного ЭЦП стандартного уведомления о принятии платежа банком, а не в момент поступления средств на счет магазина (в другом банке). Если этого не будет, то шансов у систем безналичных расчетов победить в Internet платежные системы по пластиковым картам, нет никаких. Кстати, отвечать по таким обязательствам должен не только банк его выпустивший, но при банкротстве банка и Certificate Authority, хотя бы частично, пусть заставляют банки размещать страховые депозиты или делают что-то еще.

                  Возможно, мои рассуждения покажутся утопичными, но я знаю о чем говорю. Пять лет я работал в банке с 2000 электрических клиентов. Сейчас я работаю в организации, эксплуатирующей 8(!) систем типа ╚банк-клиент╩ от разных банков. Как вы понимаете, меня вряд ли обрадует девятый договор, если в нем будет написано ╚банк всегда прав╩.

                  С уважением ко всем участникам дискуссии,
                  --
                  Максим Смирнов msmirnoff@altavista.net>

                  Комментарий


                  • #10
                    Отправил Maxim E. Smirnoff 09-15-2000 11:02 AM
                    Очень благодарен уважаемому сообществу за отклики на мои высказывания. Я взял этот ответ как выражение наиболее типичного подхода к построению интернет-систем. Думаю что Maxim E. Smirnoff не будет на меня за это в обиде.

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

                    "... давай те поразбираемся с Интернет. Что такое Интернет? Я вполне серьезно спрашиваю, господа. Кто-нибудь помнит определение Интернет? :-) Берем rfc2026, читаем: ⌠Internet это свободно организованное, международное сообщество автономных взаимосвязанных сетей, обеспечивающих host-to-host взаимодействие, в силу добровольного, строгого соблюдения открытых протоколов и процедур, зафиксированных в стандартах Интернет (собственно в RFC)■. Почувствуйте главное: автономные сети, предоставляют своим участникам возможность взаимодействовать друг с другом только потому, что поддерживают одинаковые протоколы и форматы..."
                    Извините за длинное квотирование, но здесь действительно суть! Интернет - это стандарты обмена, а не методы обеспечения юридической значимости и распределения ответственности. Интернет - открытая ИНФОРМАЦИОННАЯ сеть, а не сеть документооборота. Ответственность не предполагается! Даже наличие стандартов PGP, DES и т.п. не определяет схему распределения рисков. Мы делаем надстройку в виде e-business и превращаем просто информацию в документ. А это уже обеспечение возможности взять материальную компенсацию с неисполнившего свои обязательства участника системы. А обязательства наступают на основе электронного сообщения.
                    Пример. Вот Вы Максим (если Вы программист) на каких условия готовы передавать мне на реализацию софт собственной разработки. При условии, что мы с Вами ни разу не виделись. Вам будет достаточно мэйла с обязательствами от меня или информации на моем сайте?

                    "Только жесточайшее следование правилу: ╚всем должно быть наплевать, какой у меня компьютер, ОС, прикладной софт главное, что я строго поддерживаю стандартные протоколы взаимодействия╩ позволяют строить такие большие сети как Internet."
                    Опять-таки - информационные системы!
                    Еще пример. Вы готовите платежку в Lexicone и выделяете жирным шрифтом сумму - 10 руб. Передаете ее как электронный документ партнеру. Он ее прочитает? А как же! Это же ASCII файл. Да еще и напечатает ее. И у него будет "документ" в котором стоит сумма 2100 руб. Это Lexicon вставил управляющие символы выделения жирным. Согласен, пример не совсем корректен, но отчасти демонстрирует "независимость" от прикладного софта. Стандарты Интернет дают именно общую канву, которая и обеспечила такое развитие ИНФОРМАЦИОННОГО обмена. Если Вам приходит письмо не в той кодировке (допустимо в Интернет) - не беда, исправите и прочитаете. А если финансовый документ?

                    " Иначе, есть дорога, ведущая только назад, в кошмар корпоративных систем."
                    Кошмар ли? Корпоративные системы выступили в роли "палочки-выручалочки" при вакууме в законодательстве.

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

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

                    "3.Безопасность √ проблема администратора."
                    Не только и не сколько! Это проблема ВСЕХ участников системы. На ком ответственность, на том и проблема. Если за все отвечает администратор, то... не хотел бы я быть тем администратором.

                    "4.Эксклюзив. Купив у нас систему сегодня, вы будете кормить нас всю оставшуюся жизнь. Потому как никто кроме нас не сумеет внести в систему необходимые вам изменения."
                    Обычно факт. Но купив "стандартное" ПО вы будете кормить разработчика стандартного ПО или разработчика систем, базирующихся на стандартном ПО. Microsoft тому пример.

                    "Каким же мне видится нормальный Интернет-Банк. Форматы электронных документов: платежных требований, выписок по счету, справочников и т.д. у всех одинаковые, разработаны авторитетным объединением банков, разработчиков ПО и клиентов(!), например с использованием языка XML и утверждены ЦБ..."
                    Здорово! Осталось всех "построить". Попытки были. Но никто не мешает это сделать и сейчас. Кто может заплатить за такой проект?

                    "...Цифровая подпись √ это не закон, а формат аналогичный RSA-шным PKCS и если я не хочу покупать Вербу-О, а хочу посадить сто китайцев с логарифмическими линейками и заставить вычислять их цифровую подпись вручную, то это мое неотъемлемое право. А вот закон должен обязывает Интернет-магазины ... отпускать товары и услуги по получению заверенного ЭЦП стандартного уведомления о принятии платежа банком..."
                    А вот тут стоп! Если ЭЦП не "закон", то в честь чего это магазин должен нести ответственность? "Добровольцев" будет не много, уверяю. Вы опять хотите всю ответственность переложить на одну из сторон, в данном случае на магазины! Так не пойдет. Обязательным к принятию будут только те документы, которые являются документами в юридическом смысле. Тогда ответственность на себя берет государство. Аналогия с деньгами. Они обязательны к приему при соблюдении определенных условий (контроль подлинности купюры).

                    " ...Кстати, отвечать по таким обязательствам должен не только банк его выпустивший, но при банкротстве банка и Certificate Authority, хотя бы частично, пусть заставляют банки размещать страховые депозиты или делают что-то еще."
                    Вот, вот... обязать. А на основании чего принимается решение, что обязательства наступили? Только на основании того, что программа N сказала, что все Ok?

                    Максим Смирнов msmirnoff@altavista.net>


                    ------------------
                    С уважением,
                    Митричев Илья
                    ilya@rfc.ru, ilya@mail.transit.ru
                    ICQ 13530413
                    С уважением,
                    Митричев Илья
                    ilya@rfc.ru, ilya@mail.transit.ru
                    ICQ 13530413

                    Комментарий


                    • #11
                      Отправил Ilya 09-14-2000 12:24 PM
                      Большое спасибо, за внимание к моей реплике и столь подробный ответ. Я принимаю ряд Ваших доводов и все же, наверное, я не сумел выразить главного.
                      Давай те совсем немного абстрагируемся от конкретных систем и посмотрим на эволюцию электронных документов. Сначала документы были бумажными, неотчуждаемыми от своего носителя, существовали понятия оригинала и копии и чудовищные накладные расходы на производство и обращение документов. Затем свершилось маленькое чудо. Удалось отделить документ от его носителя. Сегодня документ может быть представлен на листе бумаги, а завтра скопирован на дискету, передан по проводам, растиражирован в необходимом количестве экземпляров и т.п. Но сказав А следует сказать и Б. Отчуждая документ от носителя совершенно не стоит его приклеивать к конкретной программе, его породившей или умеющий обрабатывать (вот и проблем с различным представление текста в разных редакторах не будет). Технологии позволяют отчуждать документ от породившего программы, даже документ, заверенный цифровой подписью. И уже давно не проблема обеспечить однозначную трактовку документа вне зависимости от кодировок форматов и прочего. Правовая сторона вопроса к этому факту ничего не прибавит и не убавит.
                      А вот что касается неготовности юристов предоставить необходимую правовую поддержку, я с Вами полностью согласен. Им как рассказали бывшие и действующие ФАПСИшники в 93 году, что ЭЦП эта такая хрень, вычисляемая на ЭВМ, так они и не могут избавиться от этого стереотипа. Как согласен я и с тем, что не дозрели отечественные разработчики до технологических консорциумов типа W3C или IETF и платить за это никто не будет. И потому, уж извините, но расчеты нам и дальше придется осуществлять при помощи американских карточных платежных систем, а вычислять цифровую подпись при помощи решений от RSA.

                      Еще раз выражаю благодарность за быстрый и полезный ответ, с уважением
                      --
                      Максим Смирнов msmirnoff@altavista.net

                      Комментарий


                      • #12
                        Решил включиться в обсуждение ;-)

                        Отправил Alexander 09-14-2000 11:33 AM
                        В этой статье я описывал технологию защиты в системе "ИНТЕРНЕТ-БАНК" ...
                        Поэтому никакого аплета наш софт не скачивает с сервера, что исключает возможность фальсификации подписи.
                        Полная чушь и лукавство! Использование на стороне клиента вместо Java-апплета специализированного ПО (любого, в том числе и Интер-Про) никак не защищает пользователя-клиента от возможного наличия закладки в этом софте, и соответственно не исключает возможности фальсификации ЭЦП клиента. Решение лежит исключительно в плоскости доверия с используемому прикладному софту,в том числе и к реализации ЭЦП. Здесь только один выход - Open Source, а не какой-то там Сертификат кем-то выданный ;-)

                        Как я уже упоминал, наш программный продукт использует решение от Сигнал-КОМ ("Inter-PRO")...

                        Думаю этот ответ снимет вопросы по моему программному продукту. Теперь давайте посмотрим, что ответит Репан Дмитрий по поводу защиты в его системе от ╚троянского╩ апплета??? Мне и самому это интересно!
                        Ваш "ответ", Александр, явился всего лишь кратким описанием схемы построения системы для Интернет-Банкинга с использованием технологии Proxy SSL. Не более :-(

                        Что касается подмены банком загружаемого к клиенту java-апплета на какой-то злонамеренный - да, такая возможность существует. Теоретически банк может сам получить Сертификат разработчика в Thawte, написать свой зловредный апплет, подписать действительным сертификатом и в один прекрасный момент загрузить этот зловредный апплет клиенту. Апплет по внешнему виду будет один в один похож на iBank'овский. Далее апплет просит ввести клиента пароль, обращается к дискете, расшифровывает секретный ключ ЭЦП клиента и отправляет этот ключ в банк. Всё, атака состоялась - банк похитил секретный ключ ЭЦП клиента и теперь может сам подписывать документы от имени клиента. Возможно и другая схема, без мучений банка по разработке похожего апплета. Можно _попробовать_ просто договориться с разработчиком о "доработке" уже существующего апплета. Сертификат разработчика получать при этом банку не надо.

                        Но это всё теоретические изыскания. В основе же любого партнерства между банком и клиентом лежит ДОВЕРИЕ. Если я не доверяю банку, я не то, что не буду работать с банком по Интернет-Банкингу, я в нем даже счет не открою!

                        Кстати, вполе точно такие же атаки возможны и в схеме с использованием технологии Proxy SSL. Уже прошли те времена, когда Web-браузер был тупым и отображал ровно то, что есть в html-страничке. Теперь можно сделать очень многое! В банке совершенно свободно можно модифицировать Web-приложение, формирующее динамически HTML-странички. При чем так, что у клиента на экране в Web-браузере в подписываемой платежке будут присутствовать одни реквизиты получателя, а в параметрах команды POST, передаваемых через Proxy SSL на Web-сервер банка, будут присутствовать другие реквизиты, которые клиент и подпишет. О возможностях целенаправленной атаки из Интернета на инсталлированный у клиента Inter-Pro, или встраивание разработчиком "закладки" в устанавливаемый клиенту спецсофт тоже можном вспомнить и развить тему...

                        С уважением, Репан Димитрий
                        Компания "БИФИТ" (Банковские И Финансовые Интернет Технологии)

                        [Сообщение отредактировал Димитрий (исправлено 16-09-2000).]
                        С уважением, Репан Димитрий
                        Компания "БИФИТ" - www.bifit.com

                        Комментарий


                        • #13
                          Отправил Alexander 09-14-2000 12:55 PM
                          p.s. кстати мне эта идея раздачи бесплатного iBanka тоже сразу не понравилась! Доверяй, но проверяй! :-))
                          Александр, или у Вас проблемы с определениями, или же Вы злонамеренно путаете Благотворительность с Маркетингом. БИФИТ не раздает "iBank" бесплатно. Мы просто следуем принципам открытости в бизнесе и в отношениях с нашими Заказчиками. Как я уже писал, компания "БИФИТ" бесплатно предосталяет Лицензию на 5..10 клиентов не из-за желания "прогнуться", а исключительно в ознакомительных целях. Возможно для Вас и Вашего отдела маркетинга это будет открытием, но такой простой тактических ход дает очень хорошие результаты - динамика ПРОДАЖ увеличивается. И мы не навязываем "iBank" - мы его предлагаем. У любого заинтересованного банка есть возможность взять и посмотреть систему самостоятельно, всё пощумать ручками, а не пытаться понять хоть что либо из заумных и пространственных речей и реклам!
                          Возможность самостоятельного ознакомления очень сильно влияет на выбор системы. Кстати, взять и попробовать систему "iBank" могут не только банки, но и любой желающий, и Вы, Александр!

                          Александр, решитесь и пойдите по нашему пути - и тогда Вы увидите жизнеспособность Вашего решения, Вашей системы "Интернет-Банк"! Да и у банков появится выбор как минимум из двух таких разных, но лично опробованных систем!!!

                          С уважением, Репан Димитрий
                          Компания "БИФИТ" (Банковские И Финансовые Интернет Технологии)

                          P.S. Кстати, назовите хотя бы еще один банк, кроме "Северной Казны", где работает Ваша система. Наш же "iBank" успешно РАБОТАЕТ у Вас в Екатеринбурге, причем уже в ДВУХ банках!

                          [Сообщение отредактировал Димитрий (исправлено 16-09-2000).]
                          С уважением, Репан Димитрий
                          Компания "БИФИТ" - www.bifit.com

                          Комментарий


                          • #14
                            Отправил Alexander 09-14-2000 12:55 PM
                            Одни используют специализированное ПО, другие пишут нечто свое (java-апплеты) для защиты системы от несанкционированного доступа.
                            А разве специализированное ПО написано Господом Богом?! Это еще более "нечто свое", со своими вывортами и прочими "стандартами".

                            Теперь о безопасности в Java.
                            Sun, IBM и др. активно разрабатывают и внедряют в Java все новые достижения в области криптографии и защиты информации. В JDK есть и Security API, и Crypto API, и поддержка работы с большими числами, на которых покоится вся асимметричная криптография. Возможно для некоторых коллег это будет открытием, но элементарные криптографические процедуры, реализованные на java, работает под обычной виртуальной Java-машиной от Microsoft быстрее, чем скомпилированные нативные библиотеки (dll-ки), написанные на C++

                            Тут, как говорится, палка о двух концах, одно в угоду другому! Но я все же счтаю, что безопасность системы куда важнее мобильности и еще чего либо!!!
                            Нет никакой "палки" и никаких "концов". И очень плохо, если так думает, а уж тем более публично вещает поставщик решений! Мобильность и многоплатформенность достигаются не в убыток безопасности! Java-решения куда более надежны, чем толстые клиенты, так как провести целенаправленную тупую атаку на конкретный софт на порядок проще, чем очень тонкую на виртуальную Java-машину, под которой будет выполняться Java-апплет. Ведь апплет должен работать нормально, а в механизм ЭЦП должна закрадываться "закладка". Вобщем, при желании, можно конкурс устроить!

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

                            Комментарий


                            • #15
                              Всей душой за старую добрую мечту, выраженную Максимом Смирновым, о стандартизации способа представления электронных документов. И как заметил Максим в своем ответе Илье Митричеву, изобретать ничего уже давно не надо! Есть UNICODE, есть XML, есть PKCS. Технологии и стандарты уже все доступны и проверены. Есть все, кроме "паровоза" в этом процессе...

                              Кто готов возглавить? Илья Вячеславович, потяните в Вашей государевой деятельности?

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

                              [Сообщение отредактировал Димитрий (исправлено 16-09-2000).]
                              С уважением, Репан Димитрий
                              Компания "БИФИТ" - www.bifit.com

                              Комментарий


                              • #16
                                Это спорный вопрос, требующий детального обсуждения. Бесспорным остается то, что специализированное ПО абсолютно точно защищает банк. К сожалению, не получив ответа на свой достаточно конкретный вопрос, я вынужден его повторить. Итак,
                                ╚Каким образом при использовании SSL-протокола для скачивания апплета с сайта банка (как, например, это сделано в обсуждаемой здесь системе iBank)осуществляется протоколирование того, что происходит в рамках сессии, в том числе и при закачке этого ╚спец ПО╩, что немаловажно при разборе конфликтных ситуаций между банком и клиентом? Иными словами, как при этом банку обезопасить себя от необоснованных претензий со стороны клиента о ╚троянском╩ апплете. Да, апплет подписан разработчиком, но клиент говорит √ ╚в предыдущем сеансе я скачал апплет, забил платежку, подписал, потом выяснилось, что я подписал ╚троянские╩ реквизиты получателя. В текущем сеансе я скачал новый апплет и Вы можете проверить на нем подпись разработчика. Но предыдущего-то апплета уже нет.╩ Как при этом банку доказать, что клиент говорит неправду и как это можно отразить в заключаемом между банком и клиентом договоре?╩

                                _____________quote_________________
                                Решение лежит исключительно в плоскости доверия с используемому прикладному софту,в том числе и к реализации ЭЦП.
                                __________________________________________
                                Да, пусть так. Но у всех уже есть опыт доверия системам ╚классического банк-клиента╩. Давайте от этого и опираться (НЕ ТЕРЯЯ ПРИ ЭТОМ преимуществ интернет-банкинга и не преращая его в ╚классического╩). Наличие специализированного ПО и, главное, юридически проработанного механизма его ПЕРЕДАЧИ клиенту с подписанием соответствующих документов (как, насколько я понимаю, происходит в случае использования Inter-Pro) и порождает то самое доверие, о котором Вы говорите. Юридически грамотно составленный договор, в том числе и с обязательным описанием решения ВСЕХ возможных конфликтных ситуаций (а не профанация договора с абстрактной ссылкой на верную/неверную ЭЦП) √ вот что порождает доверие между клиентом и таким КОНСЕРВАТИВНЫМ учреждением, как банк (по крайней мере ЛЮБОЙ банк считаем себя таковым). Я считаю, что составление такого договора при скачивании апплета НЕВОЗМОЖНО из-за описанной мной выше ситуации. Буду благодарен. Если кто-либо меня переубедит, описав, как решается конфликтная ситуация, описанная выше.


                                _____________quote_________________
                                Что касается подмены банком загружаемого к клиенту java-апплета на какой-то злонамеренный - да, такая возможность существует.
                                _______________________________________
                                Да нет, не банком подмена. А злоумышленная профанация кражи денег со своего счета САМИМ ЖЕ клинетом (см. выше) и попытка таким образом обмануть банк.

                                _____________quote_________________
                                Возможно и другая схема, без мучений банка по разработке похожего апплета. Можно _попробовать_ просто договориться с разработчиком о "доработке" уже существующего апплета. Сертификат разработчика получать при этом банку не надо.
                                _______________________________________

                                Это уже организация преступной группы

                                _____________quote_________________
                                Но это всё теоретические изыскания. В основе же любого партнерства между банком и клиентом лежит ДОВЕРИЕ.
                                ______________________________________
                                Вы-то банку доверяете, и это объяснимо. А вот ДОВЕРЯТЬ клиенту (НЕ VIP, а массовому) банк просто НЕ ИМЕЕТ ПРАВА. Если Вы найдете такой банк, СРОЧНО бегите из него.


                                _____________quote_________________
                                В банке совершенно свободно можно модифицировать Web-приложение, формирующее динамически HTML-странички.
                                ___________________________________________

                                В банке, если уж на то пошло, можно и в АБС документ вкачать от имени клиента, а даже рейс в РКЦ отправить. И не нужно никакой возни с модификацией WEB-приложения.
                                _______________quote_____________________
                                О возможностях целенаправленной атаки из Интернета на инсталлированный у клиента Inter-Pro, или встраивание разработчиком "закладки" в устанавливаемый клиенту спецсофт тоже можном вспомнить и развить тему...

                                ____________________________________________


                                Да, можно, да только это вопрос не прикладного софта, а программно-аппартной защиты сети клиента и банка от НСД из интернет-а.

                                С уважением, Анатолий Сапрыкин,
                                a2000_S@mail.ru

                                [Сообщение отредактировал anatoliy_S (исправлено 18-09-2000).]

                                Комментарий


                                • #17
                                  Отправил anatoliy_S 09-18-2000 11:42 AM
                                  Это спорный вопрос, требующий детального обсуждения. Бесспорным остается то, что специализированное ПО абсолютно точно защищает банк.
                                  Анатолий, Вы, как временами и я, слишком категоричны. Во-первых, если речь идет о спецПО, устанавливаемое на стороне клиента, то от чего это может защищать банк? Нет никакой разницы каким образом попадает спецПО к клиенту - лишь бы этот способ обеспечивал целостность (неизменность) этого ПО. В любом случае это ПО предоставляет Банк. Договор об использовании этого ПО клиент заключает с банком. Необходимым условием работы клиента должно быть ДОВЕРИЕ к предоставляемому банком ПО. И неважно - это Интернет-Банкинг или это Банк-Клиент. В договоре же прописывается, что клиент доверяет ПО (системе), предоставляемое банком.

                                  В Вашем случае, Ваш Интернет-Банкинг состоит из двух компонент - устанавливаемого у клиента софта типа Proxy SSL (с Ваших слов Вы предлагаете использовать "Интер-Про" от Сигнал-КОМа) и динамически загружаемых к клиенту в процессе его работы html-страничек. Именно в html-страничках клиент заполняет html-формы. И именно содержание html-формы, которое передается Web-серверу банка через протокол http в рамках команды POST, подписывается софтом типа Proxy SSL.

                                  В нашем случае клиенту не устанавливается никакой нативный софт. К клиенту гарантированным методом грузится софт из банка. Это Java-апплет.

                                  Ваши же рассуждения и заявления в форуме об абсолютной защищенности банка в случае использования спецПО на стороне клиента, и об абсолютной незащищенности при использовании Java-технологий либо проявление Вашей некомпетентности (это можно поправить, детально ознакомившись с информацией на нашем Web-сайте - www.bifit.com), либо Вашего лукавства (а это уже маркетинг).

                                  Каким образом при использовании SSL-протокола для скачивания апплета с сайта банка (как, например, это сделано в обсуждаемой здесь системе iBank)осуществляется протоколирование того, что происходит в рамках сессии, в том числе и при закачке этого ╚спец ПО╩, что немаловажно при разборе конфликтных ситуаций между банком и клиентом?
                                  Во-первых, если бы Вы, Анатолий, не поленились, скачали бы нашу версию и поставили у себя систему "iBank" (Лицензию на 5..10 клиентов мы предоставляем не только банкам, но и всем желающим, в том числе и компаниям, потенциальным конкурентам), вопросы, подобные этому, У Вас бы не возникали. В системе "iBank", как и положено, ведется журнализация действий пользователя. При скачивании клиентом Java-апплета в логах вспомогательного Web-сервера делается запись (уровень детализации логов везде настраивается). При работе пользователя уже в Java-апплете, когда Java-апплет формирует прикладные запросы Серверу Приложения, также пишутся логи, по которым видно какой клиент, с какого IP-адреса, когда, с использованием какого ключа и что делает. НО! Эти логи НЕ ЯВЛЯЮТСЯ доказательным материалом при разрешении конфликтной ситуации!!! Системы основанные на логах - профанация. Только ЭЛЕКТРОННЫЙ ДОКУМЕНТ клиента с ЭЦП клиента может являтся доказательным материалом при разрешении конфликтной ситуации. Хотя, в соответствии с Гражданским Кодексом, ст. 434, п.1, банк можете прописать в Договоре с клиентом какую угодно процедуру разрешения конфликтой ситуации, в том числе и по логам. Но это уже кидание клиентов.

                                  Иными словами, как при этом банку обезопасить себя от необоснованных претензий со стороны клиента о ╚троянском╩ апплете. Да, апплет подписан разработчиком, но клиент говорит √ ╚в предыдущем сеансе я скачал апплет, забил платежку, подписал, потом выяснилось, что я подписал ╚троянские╩ реквизиты получателя.
                                  Опять возвращаемся к вопросу доверия к софту, предоставленному банком. Использование протокола SSL гарантирует подключение к вспомогательному Web-серверу банка и обеспечивает целостность загружаемой информации. При подмене в DNS и подключении клиента к Web-серверу злоумышленника Web-браузер выдаст пользователю предупреждение, что либо доменное имя, указанное в URL Web-браузера (наример https://ibank.bankname.ru), не соответствует доменному имени в Сертификате. Либо Сертификат Web-сервера выдан неизвестным издателем. Конечно существует вероятность атаки на базу Сертификатов Web-браузера клиента и добавления в нее Сертификата злоумышленника. Но в этом случае также возможна и атака на спец ПО, установленное в Вашем случае у клиента, с целью его модификации (закладка).

                                  В текущем сеансе я скачал новый апплет и Вы можете проверить на нем подпись разработчика. Но предыдущего-то апплета уже нет.╩ Как при этом банку доказать, что клиент говорит неправду и как это можно отразить в заключаемом между банком и клиентом договоре?╩
                                  Безопасность строится не на механизме подписи разработчиком Java-апплета, а на доверии к ПО, предоставляемое банком, и на использовании протокола SSL для гарантированного подключения к Web-серверу банка и обеспечения целостности при скачивании HTML-страницы и Java-апплета. Подпись же разработчика под Java-апплетом используется только для получения Java-апплетом расширенных прав (доступ к дискете, печать, общения с хостами, IP-адреса которых отличны от Web-сервера, с которого был загружен апплет), а также для противостояния атакам по модификации Java-апплета при использовании механизма SoftUpdate.

                                  Что касается доказательств - банку ничего доказывать не надо. Клиент в Договоре указал, что доверяет софту, предоставляемому банком. А материалом при разрешении конфликтных ситуаций являются не логи, а ЭЛЕКТРОННЫЕ ДОКУМЕНТЫ с ЭЦП клиента.

                                  Но у всех уже есть опыт доверия системам ╚классического банк-клиента╩.
                                  Есть доверие к разработчикам этого ПО, а не доверие к системам. Я видел очень много плохо спроектированных и реализованных систем "Банк-Клиент". И доверия они не заслуживают. А вот заслужить Доверие разработчик может только будучи максимально открытым для банков во всех плоскостях. К чему компания "БИФИТ" и стремится.

                                  Я считаю, что составление такого договора при скачивании апплета НЕВОЗМОЖНО из-за описанной мной выше ситуации. Буду благодарен. Если кто-либо меня переубедит, описав, как решается конфликтная ситуация, описанная выше.
                                  У меня нет задачи переубеждать Вас, как в прочем и "продавливать" свою точку зрения по отношению к другим участникам форума. Я лишь открыто и максимально подробно излагаю нашу позицию, с которой Вы имеете полное право не соглашаться.

                                  Да нет, не банком подмена. А злоумышленная профанация кражи денег со своего счета САМИМ ЖЕ клинетом (см. выше) и попытка таким образом обмануть банк.
                                  В соответствии с Договором между банком и клиентом, и при наличие электронного документа с корректной ЭЦП клиента, у банка есть все основания по исполнению этого документа. Все убытки, связанные с кражей секретного ключа ЭЦП клиента несет сам клиент. В случае же, когда электронного документа с ЭЦП клиента нет, или ЭЦП некорректна - все убытки несет банк.
                                  Все логи, журналы сессий и пр. - суррогаты, липа, желание банков перевесить всю ответственность на клиентов.

                                  Вы-то банку доверяете, и это объяснимо. А вот ДОВЕРЯТЬ клиенту (НЕ VIP, а массовому) банк просто НЕ ИМЕЕТ ПРАВА. Если Вы найдете такой банк, СРОЧНО бегите из него.
                                  Здесь я с Вами совершенно согласен. Любой Банк-Клиент, предосталяемый клиенту банком, как в прочем и Интернет-Банкинг, требует определенного доверия клиента к банку. В то же время, банк не может также симметрично доверять клиенту, так как все притензии возникают у клиента к банку, и банк должен оправдывать свои действия.

                                  _____________quote_________________
                                  В банке совершенно свободно можно модифицировать Web-приложение, формирующее динамически HTML-странички.
                                  ___________________________________________

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

                                  Я же постарался указать, что в рамках Web-технологии существует возможность кинуть клиента, модернизировав Web-приложение, исполняющееся в банке на Web-сервере, таким образом, что при заполнении клиентом html-страницы с платежкой, в полях формы будут присутствовать одни реквизиты, в а подписываемых клиентом (Вашим спецПО) и передаваемых в банк полях будут другие реквизиты. При этом целостность Вашего спец.ПО останется девственно чистой! А клиент уже никогда не докажет, что этот документ он не создавал и не подписывал. И мы опять упираемся в необходимость доверия клиента к банку и банковскому софту.

                                  Надеюсь на все вопросы ответил подробно.

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

                                  [Сообщение отредактировал Димитрий (исправлено 18-09-2000).]
                                  С уважением, Репан Димитрий
                                  Компания "БИФИТ" - www.bifit.com

                                  Комментарий


                                  • #18
                                    [quote]Отправил Димитрий 09-18-2000 02:07 PM

                                    Ваши же рассуждения и заявления в форуме об абсолютной защищенности банка в случае использования спецПО на стороне клиента, и об абсолютной незащищенности при использовании Java-технологий либо проявление Вашей некомпетентности (это можно поправить, детально ознакомившись с информацией на нашем Web-сайте - www.bifit.com)...
                                    ___________________________________
                                    С информациейто я знакомился, однако, вопросы мои глубже и выходят за рамки предалагаемого на Вашем сайте.
                                    _________quote_____________________
                                    Во-первых, если бы Вы, Анатолий, не поленились, скачали бы нашу версию и поставили у себя систему "iBank" (Лицензию на 5..10 клиентов мы предоставляем не только банкам, но и всем желающим, в том числе и компаниям, потенциальным конкурентам), вопросы, подобные этому, У Вас бы не возникали.
                                    _________________________________________
                                    Да я и не ленился, в том то все и дело, и с системой Вашей разобрался подробно.
                                    _________quote_____________________
                                    При скачивании клиентом Java-апплета в логах вспомогательного Web-сервера делается запись
                                    __________________________________________
                                    Чем она подписывется?

                                    _________quote_____________________
                                    При работе пользователя уже в Java-апплете, когда Java-апплет формирует прикладные запросы Серверу Приложения, также пишутся логи, по которым видно какой клиент, с какого IP-адреса, когда, с использованием какого ключа и что делает.
                                    __________________________________________
                                    Да, эти логи (поскольку весь трафик шифруется при помощи ключа Вашим апплетом) могут разрешать конфликтную ситуацию.
                                    _________quote_____________________

                                    НО! Эти логи НЕ ЯВЛЯЮТСЯ доказательным материалом при разрешении конфликтной ситуации!!!
                                    ______________________________________
                                    Cовершенно верно, если речь идет о логах, которые ведутся именно при скачивании апплета в Вашем случае. Поскольку трафик (в Вашем случае IP-трафик) в этом случае при скачивании апплета НЕВОЗМОЖНО подписать никакой заранее установленной между банком и клиентом ЭЦП, а SSL-трафик на стороне и банка и клиента не журнализируется в полном (с ЭЦП) объеме.

                                    _________quote_____________________

                                    Системы основанные на логах - профанация. Только ЭЛЕКТРОННЫЙ ДОКУМЕНТ клиента с ЭЦП клиента может являтся доказательным материалом при разрешении конфликтной ситуации.
                                    _________________________________________
                                    Совершенно ВЕРНО √ ВОТ ключевой момент наших с Вами разногласий. Если логи содержат весь трафик, подписанный установленным образом при помощи ЭЦП √ ТОЛЬКО ТОГДА они юридически значимы!
                                    _________quote_____________________
                                    Хотя, в соответствии с Гражданским Кодексом, ст. 434, п.1, банк можете прописать в Договоре с клиентом какую угодно процедуру разрешения конфликтой ситуации, в том числе и по логам. Но это уже кидание клиентов
                                    _______________________________________
                                    Да никакое это не кидание, а просто способ КОНКРЕТНО и ЧЕТКО договориться клиенту и банку между собой.
                                    _________quote_____________________
                                    Конечно существует вероятность атаки на базу Сертификатов Web-браузера клиента и добавления в нее Сертификата злоумышленника. Но в этом случае также возможна и атака на спец ПО, установленное в Вашем случае у клиента, с целью его модификации (закладка).
                                    _____________________________________________
                                    И все-таки Вы не ответили на мой вопрос. Попробую сформулировать его поточнее. Итак, клиент хочет, как Вы выражаетесь, ╚кинуть╩ банк или хотя бы СЕРЬЕЗНО унизить его ДОБРОЕ ИМЯ и сознательно заявляет, что он скачал ╚троянский╩ аплет. Хотя он, на самом деле, просто загрузил его себе в браузер. Как при этом юридичеки значимо будет оправдывать себя банк. Как Вы понимаете, вопос о доверии к ПО в данном случае ничего с юридической точки зрения не даст, поскольку клиент всегда глупее банка и будет доверять любому его софту. При этом если банк использует могущее скомпрометировать его ПО, он автоматически теряет в своем реноме.
                                    _________quote_____________________
                                    Что касается доказательств - банку ничего доказывать не надо. Клиент в Договоре указал, что доверяет софту, предоставляемому банком. А материалом при разрешении конфликтных ситуаций являются не логи, а ЭЛЕКТРОННЫЕ ДОКУМЕНТЫ с ЭЦП клиента.
                                    __________________________________________
                                    Да нет, ИМЕННО логи, но корректно составленные, с содержанием внутри себя (то есть логов), всего трафика, подписанного юридически описанной ЭЦП между банком и клиентом!
                                    _________quote_____________________

                                    Есть доверие к разработчикам этого ПО, а не доверие к системам.
                                    ____________________________________
                                    Смотри описанный выше вопрос полноты ведения логов. Именно этот вопрос достоверно и юридически значимо реализован в ╚классических банк-клиентах╩.
                                    _________quote_____________________
                                    Все логи, журналы сессий и пр. - суррогаты, липа, желание банков перевесить всю ответственность на клиентов
                                    ___________________________________
                                    Или (с учетом сказанного мной выше про полноту логов), желание банка не ╚попасть в просак╩.
                                    _________quote_____________________
                                    Банк действительно внутри себя может сделать всё что угодно. Но для оправдания своих действий по списыванию средств со счета клиента банк должен предоставить не какие-то там логи
                                    ___________________________________

                                    действительно не какие-то там, а полноценные, описанные в договоре, соедержащие внутри себя все ЭЦП
                                    _________quote_____________________
                                    ______Я же постарался указать, что в рамках Web-технологии существует возможность кинуть клиента, модернизировав Web-приложение, исполняющееся в банке на Web-сервере, таким образом, что при заполнении клиентом html-страницы с платежкой, в полях формы будут присутствовать одни реквизиты, в а подписываемых клиентом (Вашим спецПО) и передаваемых в банк полях будут другие реквизиты. При этом целостность Вашего спец.ПО останется девственно чистой! _____________________________

                                    Да, но логи-то (с ЭЦП, содержащие трафик) у клиента и у банка не совпадут и ситуация будет решена в пользу клиента
                                    _________quote_____________________
                                    А клиент уже никогда не докажет, что этот документ он не создавал и не подписывал
                                    ___________________________________
                                    Докажет, см. выше
                                    _________quote_____________________
                                    Надеюсь на все вопросы ответил подробно.
                                    _______________________________________

                                    . К сожалению, пока нет.

                                    Давайте для полноты эксперимента возьмем описанную мной конфликную ситуацию и распишем ее разрешение в моем и в Вашем случае:

                                    ╚Клиент говорит √ ╚в предыдущем сеансе я скачал апплет, забил платежку, подписал, потом выяснилось, что я подписал ╚троянские╩ реквизиты получателя. В текущем сеансе я скачал новый апплет и Вы можете проверить на нем подпись разработчика. Но предыдущего-то апплета уже нет.╩ Как при этом банку доказать, что клиент говорит неправду и как это можно отразить в заключаемом между банком и клиентом договоре?╩

                                    Жду Вашего ответа.
                                    С уважением, Сапрыкин Анатолий
                                    a2000_S@mail.ru

                                    Комментарий


                                    • #19
                                      Отправил anatoliy_S 09-18-2000 04:31 PM
                                      Давайте для полноты эксперимента возьмем описанную мной конфликную ситуацию и распишем ее разрешение в моем и в Вашем случае:

                                      ╚Клиент говорит √ ╚в предыдущем сеансе я скачал апплет, забил платежку, подписал, потом выяснилось, что я подписал ╚троянские╩ реквизиты получателя. В текущем сеансе я скачал новый апплет и Вы можете проверить на нем подпись разработчика. Но предыдущего-то апплета уже нет.╩ Как при этом банку доказать, что клиент говорит неправду и как это можно отразить в заключаемом между банком и клиентом договоре?╩
                                      Банк ссылается на Договор, где описана процедура разрешения конфликтной ситуации. В соответствии с этой процедурой, банк предоставляет клиенту электронный документ с корректной ЭЦП клиента, на основании которой банк перевел деньги со счета. На заявление клиента о недоверии к софту, банк указывает на пункт Договора, в соответствии с которым клиент признает корректность предоставляемого банком софта и доверяет этому софту.

                                      Теперь о логах.

                                      Анатолий, у нас с Вами разные точки отсчета.
                                      В моем случае вопрос решается не на уровне логов, а на уровне электронных документов. В Вашем случае логи с ЭЦП клиента - те же электронные документы, только служебные, уровнем ниже. И ситуация сводится опять к доказательству, что клиент создавал этот ЭЛЕКТРОННЫЙ ДОКУМЕНТ - причем не важно логи это или платежка! В описываемом Вами случае аппеляция клиента к поставляемому банком софту неразрешима. Поясню на примере.

                                      Не важно какая система - iBank или толстый Банк-Клиент. Клиент набивает платежку, подписывает и отправляет в банк. В результате есть логи на стороне клиента с ЭЦП клиента и банка, логи на стороне банка с ЭЦП клиента и банка, и платежка в банке с ЭЦП клиента. То есть присутствует определенный набор электронных документов с ЭЦП клиента. Далее клиент, решая кинуть банк, заявляет, что он создавал платежку с другими реквизитами, а предоставленный банком софт имеет возможность управляться дистанционно. И вот банк такой-плохой кинул клиента, отправив деньги в другую сторону. Но банк, в соответствии с Договором и с процедурой разрешения конфликтной ситуации, начинает предъявлять клиенту электронные документы - (платежку с ЭЦП клиента, логи с ЭЦП). А клиент говорит, что софт имеет закладку, что банк его дурит, что процедура вычисления целосности софта некорректна, что механизм ЭЦП имеет закладку и т.д. Что банк такому клиенту возразит? Правильно - все, что указано в Договоре. Указано в Договоре, например, что доказательным материалом являются логи - "банковские контрольные архивы" - и всё. Но клиент вопит: "Не доверяю я софту! И вот она проблема - "Доверие к софту".

                                      Вот этот пункт - "Доверие клиента к софту, предоставляемое банком" - и должен быть отражен в Договоре.

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

                                      [Сообщение отредактировал Димитрий (исправлено 18-09-2000).]
                                      С уважением, Репан Димитрий
                                      Компания "БИФИТ" - www.bifit.com

                                      Комментарий


                                      • #20
                                        Постараюсь ответить на поставленные в нескольких сообщениях вопросы. Если только мой глас не затеряется в потоке объемных дискуссий... Это просто наблюдение - любой вопрос Форума (не только этой темы) сходится к обмену мнениями (это когда приходишь с одним, а уходишь уже с другим) между Дмитрием Репаном и очередным "попавшимся" на тему "iBank и остальное". Браво Димитрий, восхищен!
                                        Итак, по теме.

                                        "Сначала документы были бумажными, неотчуждаемыми от своего носителя, существовали понятия оригинала и копии и чудовищные накладные расходы на производство и обращение документов. Затем свершилось маленькое чудо. Удалось отделить документ от его носителя. Сегодня документ может быть представлен на листе бумаги, а завтра скопирован на дискету, передан по проводам, растиражирован в необходимом количестве экземпляров и т.п. " (с) Maxim E. Smirnoff
                                        Вся проблема как раз в том, что чуда не свершилось! В России вообще понимание документа отличается от западного мира и тем более Америки. У "них" все строится вокруг сделки и она "основа бытия" (да простят меня юристы за примитивизм). И далее идет речь методов оформления сделки. у нас же все строится на основе ДОКУМЕНТА. Это он порождает другие документы и определяет действия сторон и, в итоге, сделку. Понятие документа у юриста и IT специалиста разное. Программистское понимание документа нельзя отождествлять с юридическим. Чтобы что-то называлось документом, это что-то должно иметь ряд обязательных реквизитов и отвечать ряду требований. Только такие документы порождают ответственность. Платежка документ? Если на бумаге и оформлена в соответствии (печать, подпись, отчасти требования ЦБ по оформлению и т.п.), то да. Электронное сообщение с подписью - не документ! Нет такого закона, который приравнивает это сообщение к документу. Понятие документа затрагивает в России очень многие области права. в случае с электронной платежкой документом является договор клиента с банком, а электронное сообщение выступает в виде приложения как доказательный материал.
                                        ДОКУМЕНТ имеет государственную поддержку в виде арбитражных и прочих судов. Есть понятие оригинала, копии и пр. На этом, например, строится закон о нотариате, строится наследование.
                                        "Но сказав А следует сказать и Б. Отчуждая документ от носителя совершенно не стоит его приклеивать к конкретной программе, его породившей или умеющий обрабатывать [SKIP]... Технологии позволяют отчуждать документ от породившего программы, даже документ, заверенный цифровой подписью. И уже давно не проблема обеспечить однозначную трактовку документа вне зависимости от кодировок форматов и прочего. Правовая сторона вопроса к этому факту ничего не прибавит и не убавит." (с) Maxim E. Smirnoff
                                        Опять взгляд со стороны технологии. Технологии все это позволяют! Согласен, нельзя "приклеивать" документ к программе, однако должен быть описан метод обеспечения юридической силы сообщения. Это уже будет "хитросплетение" технологий и юридических построений. Придется дать детальное описание проверки ЭЦП и правил ОДНОЗНАЧНОГО восприятия сообщения и превращения его в вид, воспринимаемый человеком. Последнее обязательно в соответствии с законом! (утрированно - должны обеспечиваться равные права субъектов с вычислительной техникой и без оной, потому судьи все равно будут требовать бумажных доказательств, есть понятие оформления чего-либо в письменном виде). Поэтому "правовая сторона" именно добавит и прежде всего головной боли! Некоторая аналогия с банкнотами - есть правила определения подлинности купюры. Всех их знают и пользуются? Чаще всего нет. Полагаются на интуицию, личный опыт, авось... Есть аппаратные детекторы, определяющие подлинность с определенной достоверностью. Однако при разборках в суде будет проведена полная экпертиза. Электронная фальшивка будет выявляться только техническими средствами. (Кто умеет "на глазок" по коду проверить ЭЦП?) Достоверность проверки определяется "качественными" характеристиками используемого софта. И с этим связано... "... стандартизации способа представления электронных документов. И как заметил Максим в своем ответе Илье Митричеву, изобретать ничего уже давно не надо! Есть UNICODE, есть XML, есть PKCS. Технологии и стандарты уже все доступны и проверены. Есть все, кроме "паровоза" в этом процессе..." (с) Димитрий. Стандарты действительно есть, но это технологические стандарты! Продолжу вышеприведенную аналогию с купюрами. Есть стандарты на введение металлической полосы в бумагу, есть стандарты на бумагу, но даже при соблюдении все этих стандартов то, что получится не будет денежными банкнотами! Каждое (заметьте КАЖДОЕ) государство имеет свои национальные стандарты на денежные знаки, хотя все используют аналогичные технологии. И это норма. Сейчас нет национального стандарта России на "электронный документ". Попытка будет в Законе об ЭЦП. Точнее попытка приравнять электронные сообщения "в правах" к документам с некоторыми ограничениями. Будет стандарт (не стандарт обмена данными, а стандарт признания "подлинности электронной купюры") тогда можно будет говорить о использовании широкого спектра программ. Но и тогда не отпадет вопрос о сертификации. В том смысле, что кто-то должен нести ответственность за качество софта и возместить убытки в случае "прокола" программы на фальшивке. Не буду диспутировать в недостатках государственной системы сертификации. Я говорю о сути. Поправить меня, если я не прав, но сейчас ни одно софтверная фирма не может нести материальной ответсвенности в случае нанесения убытков потребителю. В договорах-то она может многое прописать, но реально возмести убытки кто сможет?
                                        "...Кто готов возглавить? Илья Вячеславович, потяните в Вашей государевой деятельности?" (с) Димитрий
                                        Нет, не потянем. Я осознаю всю неподъемность этой задачи в текущем формате рабочей группы. Можно прописать поручение правительству в одной из федеральных программ, но вы сами знаете что из этого выйдет. Реальнее раскрутить коммерческий проект и результаты пропихивать через Думу. Вот здесь нужна помощь уважаемого сообщества в вопросах организации и финансирования.

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


                                        ------------------
                                        С уважением,
                                        Митричев Илья
                                        ilya@rfc.ru, ilya@mail.transit.ru
                                        ICQ 13530413
                                        С уважением,
                                        Митричев Илья
                                        ilya@rfc.ru, ilya@mail.transit.ru
                                        ICQ 13530413

                                        Комментарий


                                        • #21
                                          Приветствую, Дмитрий!
                                          Могли бы ответить в одной мессаге!! :-))
                                          >Вы злонамеренно путаете Благотворительность
                                          >с Маркетингом. БИФИТ не раздает "iBank" >бесплатно"
                                          Я не путаю, а всего лишь подтвердил, что такое возможно!
                                          >Александр, решитесь и пойдите по нашему >пути - и тогда Вы увидите жизнеспособность >Вашего решения, Вашей системы "Интернет->Банк"! Да и у банков появится выбор как >минимум из двух таких разных, но лично >опробованных систем!!!"
                                          Я пошел по другому пути, я предоставляю клиентам доступ к нашему сайту с расположением ДЕМО-ВЕРСИИ в 2-х вариантах: тяжелое (Java+Corba+Oracle) и легкое.
                                          >Нет никакой "палки" и никаких "концов". И >очень плохо, если так думает, а уж тем >более публично вещает поставщик решений! >Мобильность и многоплатформенность >достигаются не в убыток безопасности!
                                          Дмитрий, не будьте таким категоричным в высказываниях! Мы разговаривали о Вашей системе и я считаю, что именно в Вашем решении упор сделан на мобильность (о чем Вы сами постояннго говорите в форуме), и в тоже время говорите о возможном троянском аплете, тут же переводя стрелки на доверие банка к клиенту и наоборот! Я считаю, что нельзя перекладывать безопасность в системе на клиента путем написания "правильного" для банка договора на обслуживание!!! Давайте не будем наш подход основывать на том, что банк всегда прав, это может быть не так!
                                          Вообще я согласен с Maxim E. Smirnoff насчет того, что клиент вправе выбрать форму защиты в системе: "Я бы писал в договоре, что клиент сам идет в магазин, покупает там любой понравившейся ему апплет, реализующий конкретные алгоритмы цифровой подписи и представляющий результат в стандартном формате, например в pkcs#7." Нужно только, чтобы софт на стороне банка был унифицирован для этого.
                                          Понимаете, что значит в наше время доверие? Какой уважающий себя клиент полностью будет доверять какому-либо банку?? Ведь всякие потрясения могут быть ,как например в августе 98 года! Помните, как упало доверие к финансовым институтам после этого? Так что в любом деле, связанном с финансами и капиталом, нужно опираться на букву закона и договор, составленный между банком и клиентом! Никакое доверие к софту, к банку, выбравшему какой либо софт, не поможет клиенту вернуть его деньги, а только СУД с помощью правильно составленного договора!

                                          Герасимов Александр

                                          Комментарий


                                          • #22
                                            Отправил Alexander 09-19-2000 12:10 PM
                                            Приветствую Илья!
                                            Ты верно подметил, что как только заходит речь о технологии, построении ситем Интернет банкинга, тут же (с помощью Дмитрия либо без нее) тема переводится на iBank! Хорошая реклама системе,
                                            Александр, это не реклама, это предмет обсуждения. Вы не задавались вопросом: "Почему в этом форуме кроме системы "iBank" не обсуждается никакая другая система?" Может потому, что кроме реально работающей в нескольких десятках банков системы "iBank", нет предмета для обсуждения? Может все Ваши "системы для Интернет-Банкинга", о которых говорите Вы или Илья Митричев (ЗАО "РФК"), только рекламный раздутый пустой пузырь?! И Вы пытаетесь впарить банкам Ваши "технологии и решения", которые существуют только в Ваших рекламных проспектах и на не до конца функциональных демо-стендах?! Ну назовите мне хотя бы пять банков, где успешно РАБОТАЕТ Ваша система! Только не надо ссылки на конфиденциальность и договоренность с банками. Я сам работаю на этом рынке и знаю, что в подавляющем большинстве банки сами заинтересованы в косвенной рекламе системы, проводимой разработчиком.

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

                                            Дело в том, что Дмитрий - разработчик софта, он выбрал сейчас свой путь развития и не может с него сойти или признать проколы, т.к. это будет провалом маркетинговой политики компании!
                                            Ну вот и начались выводы "Большой Комиссии" ;-)
                                            Видать iBank хорошо "проколол" Вам з......

                                            To all: Я завершаю свой длинный флейм в этой теме, и постараюсь впредь высказываться в форуме максимально емко и кратко ;-)

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

                                            Комментарий


                                            • #23
                                              [QUOTE]Отправил Димитрий 09-18-2000 07:07 PM
                                              Банк ссылается на Договор, где описана процедура разрешения конфликтной ситуации. В соответствии с этой процедурой, банк предоставляет клиенту электронный документ с корректной ЭЦП клиента, на основании которой банк перевел деньги со счета. На заявление клиента о недоверии к софту, банк указывает на пункт Договора, в соответствии с которым клиент признает корректность предоставляемого банком софта и доверяет этому софту.
                                              _____________________________________________

                                              Вот и отлично. Это Ваш случай. Теперь случай с использованием специального софта на стороне клиента для осуществления подписи/шифрования http √ трафика банк-клиент:
                                              1. Банк по своим логам проверяет ЭЦП под документом с якобы неверными реквизитами получателя. Да, действительно ЭЦП принадлежит клиенту (или клиент автоматически неправ).
                                              2. По логам http-трафика в банке, содержащими ЭЦП банка под каждой html-страницей и ЭЦП клиента под каждым html-запросом, ╚поднимается╩ весь трафик в системе за время декларированной клиентом ╚закачки╩ ему ╚троянской╩ http-формы платежки. Из логов сразу видно, что и в какое время клиент делал на сервере банка (напомню, все логи содержат ЭЦП, значит, юридически значимы и все действия по ним легко юридически формализуемы). После этого клиент признает свою неправоту или упирается и говорит, что ЭЦП банка ему подделал на формах сам банк, тогда см. п.3
                                              3. По логам http-трафика у клиента, содержащими ЭЦП банка под каждой html-страницей и ЭЦП клиента под каждым html-запросом, ╚поднимается╩ весь трафик в системе за время декларированной клиентом ╚закачки╩ ему ╚троянской╩ http-формы платежки. Из логов сразу видно, что и в какое время клиент делал на сервере банка. Если логи корректы, клиент сразу признает свою неправоту, если логов нет или они физически не читаемы √ клиент автоматически вынужден согласиться с условиями п.2.
                                              Все описанные выше процедуры легко формализуемы в договорах и абсолютно защищают и банк и клиента в любых ситуациях.
                                              Согласитесь, выглядит убедительнее, чем пункт договора, абстактно декларирующий доверие клиента софту банка.
                                              _____________________________________________

                                              Теперь о логах.

                                              Анатолий, у нас с Вами разные точки отсчета.
                                              В моем случае вопрос решается не на уровне логов, а на уровне электронных документов. В Вашем случае логи с ЭЦП клиента - те же электронные документы, только служебные, уровнем ниже. И ситуация сводится опять к доказательству, что клиент создавал этот ЭЛЕКТРОННЫЙ ДОКУМЕНТ - причем не важно логи это или платежка! В описываемом Вами случае аппеляция клиента к поставляемому банком софту неразрешима. Поясню на примере.
                                              _____________________________________________

                                              В том-то все и дело, Дмитрий. Мы говорим об одной и той же вещи, просто она у Вас не реализована до конца. Действительно, Вы в качестве ЭЛЕКТРОННОГО ДОКУМЕНТА рассматриваете платежку, то есть Макроуровнь, я же рассматриваю как платежку (МАКРОУРОВЕНЬ), так и каждую html_страницу и html-запрос, то есть ВЕСЬ трафик или Микроуровень, что является необходимым и достаточным для разрешения ЛЮБОЙ конфликной ситуации не декларациями о доверии, а четкими юридическими формулировками.
                                              _____________________________________________

                                              Не важно какая система - iBank или толстый Банк-Клиент. Клиент набивает платежку, подписывает и отправляет в банк. В результате есть логи на стороне клиента с ЭЦП клиента и банка, логи на стороне банка с ЭЦП клиента и банка, и платежка в банке с ЭЦП клиента. То есть присутствует определенный набор электронных документов с ЭЦП клиента. Далее клиент, решая кинуть банк, заявляет, что он создавал платежку с другими реквизитами, а предоставленный банком софт имеет возможность управляться дистанционно. И вот банк такой-плохой кинул клиента, отправив деньги в другую сторону. Но банк, в соответствии с Договором и с процедурой разрешения конфликтной ситуации, начинает предъявлять клиенту электронные документы - (платежку с ЭЦП клиента, логи с ЭЦП). А клиент говорит, что софт имеет закладку, что банк его дурит, что процедура вычисления целосности софта некорректна, что механизм ЭЦП имеет закладку и т.д. Что банк такому клиенту возразит?
                                              _____________________________________________

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

                                              Правильно - все, что указано в Договоре. Указано в Договоре, например, что доказательным материалом являются логи - "банковские контрольные архивы" - и всё. Но клиент вопит: "Не доверяю я софту! И вот она проблема - "Доверие к софту".

                                              Вот этот пункт - "Доверие клиента к софту, предоставляемое банком" - и должен быть отражен в Договоре.
                                              _____________________________________________

                                              Категорически не согласен. Если продолжать Ваши рассуждения, в предельном случае имеет договор с двумя разделами √ 1. Доверие с софту. 2. Юридические адреса и платежные реквизиты сторон. Договор для того и сделан, чтобы описать ВСЕ возможные ситуации четко и безапеляционно.

                                              С уважением, Анатолий Сапрыкин
                                              a2000_S@mail.ru

                                              [Сообщение отредактировал anatoliy_S (исправлено 19-09-2000).]

                                              Комментарий


                                              • #24
                                                Отправил Ilya 09-19-2000 11:37 AM
                                                Это просто наблюдение - любой вопрос Форума (не только этой темы) сходится к обмену мнениями (это когда приходишь с одним, а уходишь уже с другим) между Дмитрием Репаном и очередным "попавшимся" на тему "iBank и остальное". Браво Димитрий, восхищен!
                                                Илья, ведь ты же прекрасно знаешь меня, ведь я более пяти лет работал с тобой рука об руку в РФК ;-) Чему восхищаться? Что я стремлюсь все разговоры об Интернет-Банкинге переводит в русло своей системы "iBank"? Ок. Давай "пройдемся" по Степаповскому ТЕЛЕБАНКУ, который предлагаешь ты в рамках "Фронт-Офиса". Или по РФК-ашному Интернет-Банку, которую Вы пытаетесь создать. Рассмотрим в форуме эти системы вдоль и поперек. Я же их зубами разгрызу на запчасти! Только потом без обид...

                                                ... А вот кому доверять - компании с опытом и некоторым уставным капиталом или молодым технологичным компаниям выбирает банк. Проблема ухода с рынка разработчика существенно затронет интересы банка. Примеров финасовых пирамид навалом.
                                                Доверять нужно не уставному капиталу (сколько было компаний с громадным уставным капиталом), не опыту, который в IT-бизнесе быстро дряхлеет и устаревает. Доверять нужно ЛЮДЯМ. Именно люди, работающие в компании, определяют успех. Не даром тов. Сталин говорил: "Кадры решают всё!" А бывшие заслуги и успехи - они уже в прошлом...

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

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

                                                P.S. Я всё-таки хорошо бы пролобировать закон об электронном документе. Может начнем консолидировать усилия всех желающих, подпитанное в том числе и финансовыми ресурсами?! Да и дело полезное и нужное во всех отношениях сделаем!

                                                [Сообщение отредактировал Димитрий (исправлено 19-09-2000).]
                                                С уважением, Репан Димитрий
                                                Компания "БИФИТ" - www.bifit.com

                                                Комментарий


                                                • #25
                                                  Что ж, начнем деловую игру. Я клиент. Вы Анатолий - представитель банка. Начинаем разбор конфликтной ситуации в случае использования на стороне клиента спец ПО, которое банк предоставляет клиенту. Моя позиция в споре (как клиента):"Банк предоставил мне ПО с закладкой (или с глюками), и теперь я не доверяю софту банка, а при его использовании я понёс потери. Хочу возмещения убытков."

                                                  Отправил anatoliy_S 09-19-2000 05:32 PM
                                                  Вот и отлично. Это Ваш случай. Теперь случай с использованием специального софта на стороне клиента для осуществления подписи/шифрования http √ трафика банк-клиент:
                                                  1. Банк по своим логам проверяет ЭЦП под документом с якобы неверными реквизитами получателя. Да, действительно ЭЦП принадлежит клиенту (или клиент автоматически неправ).
                                                  Сначала Вы пишите о подписи http-трафика (подразумевая весь поток байт, передаваемых через сокет), в пункте же 1 Вы пишите уже об ЭЦП под документом. Здесь бы по-последовательнее. Но мы берем более общий случай, когда есть в банке и платежка с ЭЦП клиента, и логи (весь http-трафик) с ЭЦП банка и клиента.

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

                                                  2. По логам http-трафика в банке, содержащими ЭЦП банка под каждой html-страницей и ЭЦП клиента под каждым html-запросом, ╚поднимается╩ весь трафик в системе за время декларированной клиентом ╚закачки╩ ему ╚троянской╩ http-формы платежки.
                                                  Опять нестыковка. Теперь Вы говорите о подписи не http-трафика (потока байт, которыми обмениваются Web-браузер клиента с Web-сервером банка), а уже о подписи html-страниц. Ладно. Пусть будут документы с ЭЦП, html-страницы с ЭЦП, весь сетевой трафик с ЭЦП (технология Proxy SSL позволяет это сделать).

                                                  Из логов сразу видно, что и в какое время клиент делал на сервере банка (напомню, все логи содержат ЭЦП, значит, юридически значимы и все действия по ним легко юридически формализуемы).
                                                  Из логов видно:

                                                  а) какие html-страницы подписывал банк и отправлял клиенту

                                                  б) какие html-страницы (а не html-формы) подписывал клиент и отправлял банку

                                                  в) какой http-трафик, подписывал банк и отправлял клиенту

                                                  г) какой http-трафик подписывал клиент и отправлял банку

                                                  Но из логов совершенно не видно кто и какие действия проводил. В логах не указано, что такой-то клиент вводил такие реквизиты. Начинается вопрос ИНТЕРПРЕТАЦИИ логов. Позиция клиента: "Я не доверяю софту банка, соответственно я не доверяю интерпретации этим софтом моих действий и действий банка. Я не доверяю результатам проверки ЭЦП, которое проводится софтом банка, так как не доверяю глюкавому софту банка".

                                                  После этого клиент признает свою неправоту или упирается и говорит, что ЭЦП банка ему подделал на формах сам банк, тогда см. п.3
                                                  Именно упирается обеими руками и ногами

                                                  3. По логам http-трафика у клиента, содержащими ЭЦП банка под каждой html-страницей и ЭЦП клиента под каждым html-запросом, ╚поднимается╩ весь трафик в системе за время декларированной клиентом ╚закачки╩ ему ╚троянской╩ http-формы платежки. Из логов сразу видно, что и в какое время клиент делал на сервере банка.
                                                  Опять возвращаемся к вопросу интерпретации логов в действия пользователя. Клиент говорит, что не доверяет софту банка, и что этот софт удалил из логов троянскую http-форму платежки. И теперь клиент полностью кинут банком, так как не имеет на своей стороне доказательного материала против банка.

                                                  Если логи корректы, клиент сразу признает свою неправоту, если логов нет или они физически не читаемы √ клиент автоматически вынужден согласиться с условиями п.2.
                                                  Ни с чем "автоматически" клиент не соглашается, и говорит, что виноват банк, подсунувший ему недоброкачественное ПО, которое могло дистанционно модифицироваться, отработать свою злостную задачу, а потом восстановиться в первозданном виде (до модификации софта была сохранена первозданная копия).

                                                  Все описанные выше процедуры легко формализуемы в договорах и абсолютно защищают и банк и клиента в любых ситуациях.
                                                  Описанная Вами процедура совершенно никак не доказывает клиенту неправоту клиента. Будет суд, будет скандал. Ну и "реклама" банку.

                                                  Согласитесь, выглядит убедительнее, чем пункт договора, абстактно декларирующий доверие клиента софту банка.
                                                  Вот именно, что вопрос доверия клиента к софту банка, не важно каким образом предоставляемое клиенту (спецПО, java-апплет или html-формы), является краеугольным камнем в любом договоре. В случае отсутствия такого пункта в Договоре клиент при разборе конфликтной ситуации будет аппелировать к некачественному (или даже зловредному) софту и предлагаемая Вами схема совершенно не работает, как в прочем и любая другая, включая, естественно, и "iBank".

                                                  При наличие в Договоре условия доверия клиента банковскому софту допустимы схемы работы и Вашей, и iBank'овской. В Вашем случае кроме документов с ЭЦП используются логи (какие конкретно? html-страницы с ЭЦП банка? http-запросы с ЭЦП клиента? http-ответы с ЭЦП банка? Вообще весь поток байт, идущий в оба конца с ЭЦП отправителя?), которые привносят ИЛЛЮЗИЮ большей защищенности, увеличивают нагрузку на банковские Сервера (процедура формирования ЭЦП достаточно процессорно емкая, и производительность при этом падает в несколько раз), запутывают еще больше клиента (ему бы понять что такое электронный документ с ЭЦП, а Вы предлагаете еще и интерпретировать http-запросы, ответы и html-страницы). В результате получается ситуация "пароль на ключ для доступа к ключу, для доступа к пароля на доступ к ключу...". Хотя совершенно спокойно можно ограничиться обычным электронным документом с ЭЦП клиента + доверие клиента к банковскому софту + согласие клиента с процедурой разрешения конфликтных ситуаций.

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

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

                                                  [Сообщение отредактировал Димитрий (исправлено 19-09-2000).]
                                                  С уважением, Репан Димитрий
                                                  Компания "БИФИТ" - www.bifit.com

                                                  Комментарий


                                                  • #26
                                                    Приветствую Илья!
                                                    Ты верно подметил, что как только заходит речь о технологии, построении ситем Интернет банкинга, тут же (с помощью Дмитрия либо без нее) тема переводится на iBank! Хорошая реклама системе, особенно когда Дмитрий, отвечая на вопросы или просто вклиниваясь в дискуссию начинает делать замечания и поправлять говорящего, что мол ВСЕ неверно (или почти все)! Я согласен с высказыванием в предыдущей теме Глеба Алексеева: "Судя по всему по поводу Интернет банка существует два мнения:
                                                    1. Мнение Дмитрия Репана
                                                    2. Неправильное мнение" :-))
                                                    Дело в том, что Дмитрий - разработчик софта, он выбрал сейчас свой путь развития и не может с него сойти или признать проколы, т.к. это будет провалом маркетинговой политики компании! Я же, человек знающий несколько технологий, предлагаю разные варианты клиентам, не привязываясь к конкретным продуктам! :-)


                                                    P.s. Дмитрий, я думаю на этот счет Вы со мной согласны!? Или опять дискуссия? :-)
                                                    Александр

                                                    Комментарий


                                                    • #27
                                                      Дмитрий, выше голову, не все так плохо!! :-))

                                                      Давайте без наездов друг на друга! Еще раз Вам говорю - я (и моя фирма) не есть разработчик систем!!! Мы продвигаем на рынок законченные решения комплексной автоматизации банковского бизнеса, а именно: операционная работа, кредиты, депозиты, межбанковские расчеты, касса, учет хозяйственных операций банка и т.д., а также системы клиент-банк, телефонный банкинг, интернет банкинг.
                                                      Согласен, что система "Интернет-банк" не столь популярна только лишь потому, что ее начали продавать лишь месяц назад!!! Т.е. до этого времени она год успешно эксплуатировалась в банке "Северная Казна", после чего стала коммерческим проектом! Так что Вы зря сравниваете себя со мной (вашу фирму и мою), у нас разные задачи!
                                                      Интересно, что Вы называете чушью? У меня есть право на свое видение технологий и-банкинга. Именно об этом и очень кратко написал в своей статье. В третьей части статьи я конкретно и четко описал технологию построения защиты в системе, пояснил для читателя основные понятия и термины, затем в форуме я описал принцип работы Proxy SSL. Какие у Вас будут конкретно замечания по моим высказываниям? Или Вы называете чушью все то, что не сходиться с Вашей точкой зрения или системой от бифит? Тогда напишите свой цикл статей и докажите всем, что Вы - лучший!
                                                      Ей богу, Дмитрий, просто смешно, когда Вы готовы всех и вся обозвать некомпетентными! :-))

                                                      Герасимов Александр

                                                      Комментарий


                                                      • #28
                                                        Если юмор не понимается - шутить не будем.

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

                                                        ------------------
                                                        С уважением,
                                                        Митричев Илья
                                                        ilya@rfc.ru, ilya@mail.transit.ru
                                                        ICQ 13530413
                                                        С уважением,
                                                        Митричев Илья
                                                        ilya@rfc.ru, ilya@mail.transit.ru
                                                        ICQ 13530413

                                                        Комментарий


                                                        • #29
                                                          Из далекой Литвы я приветствую уважаемых коллег! Недавно открыл для себя этот форум.
                                                          Что меня особенно радует в нем, так это откровенность и смелость в высказываниях уважаемых
                                                          участников, особенно Дмитрия. На правах абсолютно незаинтересованной стороны я решил подлить
                                                          "масла в огонь", как говорится, "кусать -так кусать"!
                                                          --------------------------------------------------------------------------------------
                                                          Ок. Давай "пройдемся" по Степаповскому ТЕЛЕБАНКУ, который предлагаешь ты в рамках
                                                          "Фронт-Офиса". Или по РФК-ашному Интернет-Банку, которую Вы пытаетесь создать.
                                                          Рассмотрим в форуме эти системы вдоль и поперек. Я же их зубами разгрызу на запчасти!
                                                          Только потом без обид...
                                                          --------------------------------------------------------------------------------------
                                                          Ох, нравится мне это - "зубами..." Однако, полагая, что, мало кто в России напишет адекватный
                                                          ответ, я решил потратить некоторое время на поисковых серверах, выясняя для себя, что же есть
                                                          "Степаповскому ТЕЛЕБАНКУ" и "РФК-ашному Интернет-Банку".
                                                          В результате я взял на себя смелость составить список тех, кого Дмитрий "разгрызет на запчасти".

                                                          Позволю себе распределить их по рейтингу (в скобках - мои комментарии):

                                                          1. www.stepup.ru [сделали Телебанк на веб технологии]
                                                          2. www.signal-com.ru [встроили в Телебанк свою "защиту"]
                                                          3. www.v6.ru [смогли же создать веб сайт и встроить в него п.п.1,2.]
                                                          4. www.telebank.ru [жертвы п.п.1-3.]
                                                          5. ФАПСИ [лицензировало "Сигнал-Ком", будь оно не ладно...]
                                                          6. www.intel.com [сочли Телебанк за "Историю успеха" - ссылки на п.п.7, п.п.9]
                                                          7. www.stepup.ru [сделали из Телебанк - "Клиент-Банк" и опять же не на Ява.]
                                                          8. www.rfc.ru [прикрутили к п.7 свой "Бееек-Офис" и продают его вкупе с п.7]
                                                          9. www.guta.ru [видимо, используют п.4,п.7,п.8]

                                                          Владимир.
                                                          P.S.Мне персонально интересен "разгрыз" INTEL и ФАПСИ.
                                                          ЗЫЫ. А у нас Дмитрия не спасли бы от "жесткой посадки" ни Дедка, ни Бабка, ни Внучка, ни Жучка, ну и тем более не Мышка..... [прошу прощенья за каламбур].

                                                          Комментарий


                                                          • #30
                                                            Здравствуйте!

                                                            Господа, а нельзя ли и впрямь чуть расширить предмет обсуждения? Помимо достоинств iBank-овского applet-а, абстрактных рассуждений и кухонных выяснений, хотелось бы знать вот что:
                                                            1) Какие неприятности и с какой примерно частотой наживают банки и организации, использующие Интернет-Банки (а то, быть может, предмета обсуждения просто НЕТ?),
                                                            2) И как обычно разрешаются эти конфликты?
                                                            3) В дополнение к списку от multibanka я предложил бы подать к столу Репана Интернет-Банк от BSS. Мы рискнули его поставить и внедрить у пары десятков клиентов. На мой взгляд, он не сулит существенно больших неприятностей, чем классический. А на ваш?

                                                            С уважением, Михаил Мишустин
                                                            mishustin@minbank.ru
                                                            Московский Индустриальный Банк

                                                            Комментарий

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

                                                            Свернуть

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

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