16 сентября, понедельник 10:03
Bankir.Ru

Объявление

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

Оцените нашу систему "Интернет-банк"

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

  • Fomin
    Участник создал тему Оцените нашу систему "Интернет-банк"

    Оцените нашу систему "Интернет-банк"

    Коллеги!
    Хочу получить подтверждение или опровержение своего мнения, :-) что наш ИБ уникален сочетанию простоты ипользования и функциональности.

    Демо версия здесь:
    http://dzerbank.ru/Index.asp?Id=IBDemo

    Вопрос возник по тому, что "есть мнение" о возможности поделиться нашей разработкой с другими заинтересованными банками ;-)

  • AVKomlin
    Участник ответил
    Поэтому я и считаю, что производитель должен быть со стороны или должна быть независимая подпись сертификатора.

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

    Прокомментировать:


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

    Прокомментировать:


  • hugevlad
    Участник ответил
    GeC
    могли-бы стать HSM(HardwareSecureModule)
    Таки есть уже такое Приличные чиповые карты производят криптотоперации "на борту", не выводя ключ за пределы себя. Есть i-button со встроенной java-машиной, куда можно запихать аплет вместе с ключом и ставить подпись путем запихивания данных туда с полученим подписи на выходе. Уже давно есть плата "Криптон", ключи в которую грузятся до загрузки ОС. Есть HSM для процессинга пластика, есть железо для SWIFT. Проблема одна: все эти штучки должны уметь своими средствами показывать пользователю, что именно они подписывают. Иначе в программе юзеру можно показать одно, а в HSM на подпись отправить совсем другое

    Прокомментировать:


  • Komlin
    Участник ответил
    Впрочем, все равно клиенту придется хотя бы фокусировать свой мутный взор на окошке с информацией о подписи аплета, что проблематично ...
    Это как раз проблема решаемая: клиент ставит галочку в поле (всегда доверять подписи данного (XXX) производителя) и в дальнейшем, на данном сайте его объекты выводятся без ругательств.
    После этого любой новый запрос сертификата на исполнение кода следует рассматривать как опасный сигнал и внимательно рассматривать.

    Так им клиентам, гораздо проще будет.

    Прокомментировать:


  • GeC
    Участник ответил
    Очень пользительными для систем ИБ могли-бы стать HSM(HardwareSecureModule) - выполняющие все необходимые крипто-операции, и хранящие секретный ключ в таком случае можно уже не опасаться, что кто-то украдет секретный ключ и спать спокойно

    Прокомментировать:


  • hugevlad
    Участник ответил
    Alexei Volchkov
    Есть предложение переформулировать
    При транспортировке информация подписана и закодирована
    как:

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


    если уж мы решили не употреблять политически некорректных выражений "электронная цифровая подпись" и "шифрование"

    В ИБ возникает ситуация в которой процесс "установки" ПО происходит при каждом сеансе работы
    Это можно рассматривать и под несколько другим углом: ПО (в виде браузера и корневых сертификатов) устанавливается один раз, а аплет рассматривается как данные и просто проверяется его подпись.
    Впрочем, все равно клиенту придется хотя бы фокусировать свой мутный взор на окошке с информацией о подписи аплета, чтот проблематично

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

    p.s. В каждой шутке есть доля шутки.

    Прокомментировать:


  • Alexei Volchkov
    Участник ответил
    2 ALL
    Предполагаю, что спор уходит куда-то вбок. Попробую сформулировать свои мысли по поводу безопасности в ИБ вообще.
    Рассмотрим толстого клиента. Что имеется:
    1. ПО, полученное от производителя или банка
    2. Компьютер на котором все работает
    3. Носитель ключа
    4. Транспортная среда.
    Как обеспечить безопасность.
    1. ПО должно быть trusted, то есть получено из рук поставщика или работника банка.
    2. Компьютер должен быть чист от троянов
    3. Ключ храниться надежно
    4. При транспортировке информация подписана и закодирована
    5. Все это прописано в договоре.
    Простота возникает из-за разделения процесса установки ПО от процесса его эксплуатации, процесса обработки документа от процесса транспортировки и из-за локализации критических процессов и информации на компьютере клиента и сервере банка.
    В ИБ возникает ситуация в которой процесс "установки" ПО происходит при каждом сеансе работы, обработка и транспортировка производится одновременно, а сам сеанс работы совмешен с пересылкой информации. Из за такой наворченности по сравнению с предыдущей схемой (толстый клиент) возникает необходимость комплексной защиты. Например постоянной верификации загружаемого ПО, контроль попыток атак на компьютер в течении сеанса работы (ключи - то в памяти, а труба IP протокола подключена в сеть), и т.д. и т.п. При этом возлагать на пользователя задачи проверки fingerprint`ов, установки сертификатов с проверкой их адекватности и отслеживания истинных адресов серверов это не просто не гуманно, а слегка туповато. Отсюда все проблемы про которые пишут критики.
    В заключении скажу, что пока не видел ни одной системы ИБ, в которой эти вопросы были бы до конца решены.

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

    Прокомментировать:


  • Fomin
    Участник ответил
    Goga_Ch Ну Вы ж заметили смайлик, где я писал про ключи на жестком диске. Именно это я и имел в виду... :-)

    Прокомментировать:


  • Goga_Ch
    Участник ответил
    Fomin ЭЦП просто удобнее для клиента (записал ключ на жесткий диск - и нет проблем :-))
    Вот тут-то у клиента проблемы и начинаются, когда через пару месяцев управление "Р" (или как там оно называется) приносит секретные ключи и спрашивает: "Ребята, а это чего?".
    Технология взлома тупа до безобразия. Клиент ходит через Инет, а на компьютере расшарены каталоги. Причем без пароля. Так что поосторожнее с ключами на рабочих станциях.

    Прокомментировать:


  • Fomin
    Участник ответил
    GeC

    Мне кажется, при обсуждении преимуществ одноразовых кодов и ЭЦП они оцениваются не с той стороны - для банка АБСОЛЮТНО НЕВАЖНО, какие средства используются для подтверждения авторства документа, если это прописано в договоре и на это согласен клиент.

    Именно это я и пытался доказать :-)

    Это важно только для клиента ....

    Спорить о желаниях клиента - тема бесперспективная. Тут можно оперировать лишь фактами из практики того или иного банка....
    Клиент уже бесконечно доверился банку принеся в него деньги :-)
    К тому же вспомните про бумажную подпись на документе. Не боится же клиент давать распоряжения на основании простой закорючки на бумаге?

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

    Прокомментировать:


  • Komlin
    Участник ответил
    Gec
    Для крупных клиентов ( с аналитиками и т.п. ) это может и так, для массового же сектора безразлично какая там стоит система. Всё равно в этом никто не разбирается. Они смотрят только на репутация банка.

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

    Поэтому с практической стороны пин-коды для юзеров (особено физиков) безопаснее, но вот для банка наоборот - вероятность нарваться на мошеников резко возрастает.

    Так, что самоотверженность Дзербанка даже что-то вроде восхищения вызывает

    Прокомментировать:


  • GeC
    Участник ответил
    Fomin

    Слишком гипотетическая ситуация... Я про что и говорил выше, что мы придумываем какие-то угрозы и пытаемся от них защититься "по максимуму".... На ПРАКТИКУ надо ориентироваться! :-)
    Тем более то же самое клиент может сказать и про ЭЦП. Типа пока разбираетесь - возместите мне убытки :-)


    Мне кажется, при обсуждении преимуществ одноразовых кодов и ЭЦП они оцениваются не с той стороны - для банка АБСОЛЮТНО НЕВАЖНО, какие средства используются для подтверждения авторства документа, если это прописано в договоре и на это согласен клиент.

    Это важно только для клиента
    Посмотрим, как банк может навредить клиенту :
    - банк проводит документ, который клиент не посылал(1).
    - банк не проводит документ, который клиент посылал(2).
    Предположим, что все по честному - банк не знает, и не может узнать секретный ключ клиента, журналы документов есть на обеих сторонах.

    ЭЦП
    (1) - При помощи эталонного ПО проверяется ЭЦП(клиента) под документом - совпало. значит прав банк, не совпало - клиент.

    (2) - При помощи эталонного ПО проверяется ЭЦП(банка) под квитком к документу (который я надеюсь отправляется из банка и сохраняется у клиента - совпало. значит прав клиент, не совпало - банк.

    Одноразовые коды
    так как банк знает коды, то доказать свою правоту клиент не может.

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

    На ПРАКТИКУ надо ориентироваться! :-)
    Поверьте на практике это встречается и обычно с клиентами, которыми разбрасываться не правильно

    Прокомментировать:


  • Komlin
    Участник ответил
    В случае если атакующий и "жертва" сообщники Пин код всегда совпадёт. Кстати реальная вероятность совпадения с учетом возможности одного перезапроса у клиента и хотя бы трёх попыток угадать и постепенного сокращения кодов весьма велика - 1/8 . (Пусть на каждого клиента в среднем - 50 кодов, он назвал два кода на платёж (первый якобы опечатка), взломщику разрешено хотя бы три попытки ). Сколько у Вас клиентов в час системой пользуется? .

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

    Прокомментировать:


  • Fomin
    Участник ответил
    Komlin
    Если же Пин -код - то он может быть украден и использован
    Так 100 пин-кодов то...

    Клиент (или сообщник взломщика ) приходит в суд с гражданским иском и говорит : когда сервер взламывали/подменяли я с как раз вводил платежи по пин коду(вот свидетели, вот протоколы провайдера). Мой платёж не выполнен, а через час ушёл совсем другой (вот выписка с банка). Пока там милиция ловит взломщика, я прошу, чтобы банк вернул мой платёж или принял участие в убытках

    Слишком гипотетическая ситуация... Я про что и говорил выше, что мы придумываем какие-то угрозы и пытаемся от них защититься "по максимуму".... На ПРАКТИКУ надо ориентироваться! :-)
    Тем более то же самое клиент может сказать и про ЭЦП. Типа пока разбираетесь - возместите мне убытки :-)

    Прокомментировать:


  • hugevlad
    Участник ответил
    Alexei Volchkov
    Да нет почему нельзя - можно. Проблема в том, что популярные CA это расширение вырежут, надо писать свой CA.
    Не очень понял, зачем это оформлять как поле сертификата в терминологии PKI. Я имел ввиду, сертификаты соответствия, которые выдает лаборатория ФАПСИ (или независимая. кстати, где они? ). Типа так: сертификат выдан на СКЗИ имярек версия 1.0, размер исполняемого модуля такой-то, значение суммы MD5 такое-то. Естествено, это все применимо к "утолщеннному" или толстому клиенту, когда некоторая часть софта не загружается каждый раз, а выдается клиенту по акту с указанием всех атрибутов, он их проверяет и дальше уже сам обеспечивает сохранность этого софта. Собственно, и с тонким клиентотм ситуация сводима к этому. Только в роли "постоянной" части выступает браузер с установленными в нем корневыми сертификатами thawte/verisign/etc. Тоько вот сертификат ФАПСИ в эту схему плохо вписывается Разве что агентство начнет указывать в своем сертификате серийный номер, сроки действия и др. атрибуты цифровой подписи аплета.

    Прокомментировать:


  • Komlin
    Участник ответил
    Fomin
    если Вы запрашиваете для подтверждения случайный пин-код
    так и есть. Но число попыток запроса кода ограничено
    Тогда вероятность успеха зависит от количества оставшихся у клиента кодов (ибо использованные коды должны убираться из списка).
    Но хватит об этом. Как я понял Вы уже всё исправили и тема в прошлом . Кстати очень неплохой показатель - по моей оценке на это у Вас ушло около трёх часов с начала рабочего времени. (По моему опыту ошибки бывают почти у всех, важно с какой скоростью, и как тщательно они исправляются).

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

    Если же Пин -код - то он может быть украден и использован, и тут Вам не удастатся доказать обратное, ибо дело сугубо гражданское.
    Клиент (или сообщник взломщика ) приходит в суд с гражданским иском и говорит : когда сервер взламывали/подменяли я с как раз вводил платежи по пин коду(вот свидетели, вот протоколы провайдера). Мой платёж не выполнен, а через час ушёл совсем другой (вот выписка с банка). Пока там милиция ловит взломщика, я прошу, чтобы банк вернул мой платёж или принял участие в убытках ибо это он выбрал ненадёжную схему и не защитил свой банк-клиент надлежащим образом.

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


    [qoute]
    Мы же говорили не только про взлом DNS, но про замену адреса. (например, dzerbahk.ru, вместо dzerbank.ru). А в этом случае пользователь (обычный) ничего не заметит, и никаких окошек не будет.
    [/qoute]
    во первых это уже не проблема банка, а клиента. Надо было смотреть внимательнее.

    во-вторых, как это окошек не будет? Браузер то не обманешь... когда клиент требует код dzerban браузер ждёт подписанный код, а если там переадресация - вначале будет ругательство - страница без сертификата и переадресует туда-то, а уж потом пойдёт обработка новой страницы.
    Последний раз редактировалось Komlin; 21.01.2003, 07:51.

    Прокомментировать:


  • Alexei Volchkov
    Участник ответил
    Komlin Да, конечно, если все оговорено в договоре - то и спорить клиенту не о чем (если договор не противоречит закону РФ).
    Совскм правильно писать не противоречит законодательству РФ (в противном случае можно подумать, что Вы имеете в виду закон об ЭЦП). Весь прикол ситуации в том, что Ваш договор по использованию АСП, основанный на ГК, может никак не соотносится с упомянутым законом.

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

    hugevlad
    Меня удивляет другое: почему нельзя вписывать в сертификат какую-нибудь контрольную сумму софта, которую можно рассчитать независимо (MD5, например).
    Да нет почему нельзя - можно. Проблема в том, что популярные CA это расширение вырежут, надо писать свой CA. Вот пример CA LAN Crypto в сертификатах имеет расширение - серийный номер продукта, насколько я пониманию там этим пользуются для лицензионной политики. Соответственно любые приложения отличные от LAN Crypto, это поле игнорируют, а их приложения как-то пользуют. Аналогично можно сделать и для других приложений. Проблема, в том, что например MS CA поддерживает только свои расширения. Если Вы на него пошлете запрос на сертификат с неизвестным ему (MS CA) расширением он это поле вырежет и выпустит Ваш сертификат уже без
    расширения. Fomin
    Я это видел, и думаю, что это нужно трактовать так, как и написано: Т.е. "аналогов собственноручной подписи, кодов, паролей или иных средств"
    С этим трудно не согласится. Сдругой стороны надо отдавать себе отчет, что тот, кто будет использовать системы, поддающиеся взлому, попадает в ситуацию, в которой он должен будет непрерывно доказывать пользователям надежность своей технологии. Поэтому использование цифровой подписи (замечу не электронной цифровой подписи, как в законе, а именно цифровой), стойкость которой на сегодняшний день не опровергнута более предпочтительно.

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

    Прокомментировать:


  • hugevlad
    Участник ответил
    Fomin Если бы вместо слова "подтверждающих", было слово "гарантирующих", еще можно было бы подумать на ЭЦП, а так...
    Ну, логика рассуждений проста: "Поскольку pin-код или пароль известны и принимающей стороне, наличие его в спорном документе не является подтверждением авторства".
    Насчет мат. доказательств сложности - пусть ответят математики. Насколько я понимаю, в настоящее время н найдено полиномиальных алгоритмов этого дела, а сложность существующих алгоритмов выражается очень даже точными цифрами...

    Прокомментировать:


  • Fomin
    Участник ответил
    Komlin
    если Вы запрашиваете для подтверждения случайный пин-код
    так и есть. Но число попыток запроса кода ограничено

    Что касается пункта 1, насчет презумпции виновности или невиновности...
    Не берусь спорить, но если этот так, то тогда теряется начальный аргумент (лень смотреть кто выше это сказал :-)), что ЭЦП защищает банк от презумпции виновности. Т.е. якобы банку нужно будет доказывать, что он не обманывал клиента и не делал за него документ, и получалось, что если пин-коды он знает и мог это сделать, а ключ ЭЦП банк не знает....
    Если вопрос переводится в плоскость уголовную, то ЭЦП и коды становятся равноправны в этом смысле....
    Хотя, еще раз оговорюсь, тема сложная не берусь судить...
    Тем более нет судебной практики - следовательно многие юристы, я полагаю, затруднятся с ответом

    Применение ЭЦП признано аналогом собственноручной подписи законом Российской Федерации о цифровой подписи, и соответственно считается надёжным методом аутентификации в случае соблюдения условий её применения и действующих стандартов( и это в целом правда). Поэтому шансы голословно обвинить банк в махинациях нулевые, ибо ключей он не знает, а обвинить его во взломе нельзя без доказательств.

    Последнее предложение, на мой взгляд, не следует из первого.
    Применение АСП регламентируется гражданским кодексом. ЭЦП - частный случай АСП. Подозреваю, что Вы читали закон об ЭЦП, но всё таки выскажу своё мнение:
    Закон об ЭЦП не регламентирует применение АСП, или ЭЦП "вообще".
    Его цель - ответ на вопрос: "что должны сделать два лица, чтобы заключить сделку электронно не контактируя лично друг с другом (т.е. не заключая предварительно "бумажного" договора о применении АСП)".
    И только.
    Он никаким образом не лишает других АСП (в том числе и ЭЦП) права на жизнь.
    (кстати, очень многие считают по другому)
    Таким образом последнее Ваше предложение ("Поэтому....") либо верно и для ЭЦП и для других АСП, либо не верно для обоих же способов.

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

    Сегодня уже нельзя получить второй сертификат на тот же адрес интернета не аннулировав первый
    Мы же говорили не только про взлом DNS, но про замену адреса. (например, dzerbahk.ru, вместо dzerbank.ru). А в этом случае пользователь (обычный) ничего не заметит, и никаких окошек не будет.

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

    Я это видел, и думаю, что это нужно трактовать так, как и написано: Т.е. "аналогов собственноручной подписи, кодов, паролей или иных средств"
    Здесь ни слова ни прямо не косвенно нет про ЭЦП.
    Если бы вместо слова "подтверждающих", было слово "гарантирующих", еще можно было бы подумать на ЭЦП, а так...
    Хотя, кстати, математического доказательста "сложности" разложения числа на множители (как и иных алгоритмов) на сегодняшний день нет.
    Т.е. фактически современная криптография держится на недоказанном "предположении", правда не опровергнутом ПОКА практикой :-)

    Прокомментировать:


  • hugevlad
    Участник ответил
    Komlin
    Приветствую, Александр!
    Вы не знаете случайно почему ФАПСИ не подписывает сертифицированный код? Ведь это было логичным шагом.
    Знаю Потому что подпись по ГОСТ 3410, сделанная одним СКЗИ, не проверится на другом. Таблица заполнения (s-boxes) при вычислении хеш-функции, разные значения a,p,q (впрочем, их-то можно в сертификат записывать). Меня удивляет другое: почему нельзя вписывать в сертификат какую-нибудь контрольную сумму софта, которую можно рассчитать независимо (MD5, например).

    Прокомментировать:


  • Komlin
    Участник ответил
    Приветствую Вас Алексей!
    Приветствую Вас Влад!

    если же выбор системы произведен, и договор подписан, то юридически все равнозначно.
    Да, конечно, если все оговорено в договоре - то и спорить клиенту не о чем (если договор не противоречит закону РФ).

    банк достает из широких штанин сертификат ФАПСИ на средство ЭЦП и грозно вопрошает: "Вы что, хотите сказать, что наши органы выдают сертификаты на что попало?!"
    Вы не знаете случайно почему ФАПСИ не подписывает сертифицированный код? Ведь это было логичным шагом.

    Прокомментировать:


  • Alexei Volchkov
    Участник ответил
    Komlin
    Приветствую!

    Совершенно справедливые мнения высказакны по поводу безопасности ИБ, кстати это относится ко всем ИБ, а не только к конкретному. Первопричина "дыр", "дырочек" и "неясностей", которые встречаются в продуктах - одна принципиальное отличие тонкого клиента от "утолщенного" и толстого. За удобство приходится расплачиваться необходимостью гораздо более серьезной работой по защите информации на стадии разработки и эксплуатации.
    С другой стороны с юридической точки зрения все выглядит не совсем так ка Вы пишите.
    Система pin-кодов же, несмотря на свою распространённость, обусловленную историческими причинами (т.к. компьютеры способные нормальную работу с ЭЦП появились совсем недавно) и безусловную простоту не имеет столь же мощной юридической базы в Российской федерации, изначально взявшей курс на более передовые технологии
    Согласно гражданскому кодексу (т.к. закон об ЭЦП уже общепризнанно неработает) Вы можете использовать ЛЮБОЙ аналог собственноручной подписи, главное, чтобы это было прописано в договоре банк-клиент и была процедура разрешения конфликта. Если клиент с ней не согласен, он не подписывает бумажный договор, а если согласен, то механизм разбора полетов с PIN принципиально не сложнее механизма того же разбора с использованием цифровой подписи.
    Вы правы механизм с PIN легче обломать, чем механизм с ЭЦП, но это играет роль только на этапе выбора клиентом той или иной системы, если же выбор системы произведен, и договор подписан, то юридически все равнозначно.

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

    Прокомментировать:


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

    В одном не могу с Вами не согласиться - уровень понимания происходящего пользователями оставляет желать лучшего. Они не понимают ни сути ЭЦП, ни юридических последствий своих действий с информацией в эл. форме. Еще одно подтверждение - тема в форуме на сайте "Мегафона": http://www.megafonural.ru:8280/site/...&m_start:int=0, начавшаяся с банальности - возмущения пользователем самоподписанным сертификатом сервера, да еще с полномочиями корневого.

    Прокомментировать:


  • Komlin
    Участник ответил
    Перехватив стартовую страницу он сможент незаметно перехватить все остальные, в том числе и с пин-кодами (см. Выше),
    Нуу.... если только клиент очень сильно сам этого захочет... типа на фальшивой странице будет висеть табличка: введите все 100 ваших пин-кодов и пронумеруйте :-), а клиент это выполнит.[/i]
    По-моему достаточно перехватить один-два пин кода из текущего платежа клиента(который будет думать,что работает в штатном режиме), чтобы украсть его деньги. Больше красть нет смысла - остальные заблокируют/сменят после "ухода" денег.
    Даже если Вы запрашиваете для подтверждения случайный пин-код, (работа кодами почему-то недоступна в демо-версии, поэтому вместо нормального тестирования остаётся лишь гадать), это лишь задержит взломщика на десяток минут вынуждая его вместо одной попытки перевода делать несколько пока не выпадет нужный код.

    Я не юрист, но как тут правильно заметили, по гражданским искам действует презумпция виновности. Т.е. это именно банку придется доказывать, что клиент сделал что-то неправильно. Банку придется доказать, что он не подменял софт, не копировал скрытно ключ клиента и т.п. в ДАННОМ КОНКРЕТНОМ случае - задача на мой взгляд практически невыполнимая
    Спасибо что сказали эту фразу "презумпция виновности".
    Сразу стало понятно в чём Вы заблуждаетесь. Не обижайтесь на мой самоуверенный тон, я сам поначалу так же путался, по-моему никто, кроме юристов, самостоятельно не замечает этого подвоха .

    Всё не так страшно( в описанной Вами картине, никакая работа с электронными счетами была невозможна ? мошенники кидали бы банки на каждом шагу)
    Я тоже не юрист, но во времена горячих споров по ГОСТам (см. здешние форумы и форумы багтрака), всё-таки ознакомился с этим вопросом (спасибо HugeVlad?u и Димитрию )

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

    Система pin-кодов же, несмотря на свою распространённость, обусловленную историческими причинами (т.к. компьютеры способные нормальную работу с ЭЦП появились совсем недавно) и безусловную простоту не имеет столь же мощной юридической базы в Российской федерации, изначально взявшей курс на более передовые технологии. Поэтому, в спорах по той же визе зачастую страдает либо банк либо продавец услуги.

    Правда надо признать, что в случае, когда банк сам разрабатывает и поставляет СКЗИ не сертифицируя и не заверяя их у сторонних организаций ?юридическая? стойкость не многим выше чем у системы кодов. Но это не вина ЭЦП -просто последнюю надо использовать по-другому.


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

    Потом, если злоумышленник подменяет страницу, то он может и сертификат получить. Прото сертификат будет на другую организацию, например....
    Сегодня уже нельзя получить второй сертификат на тот же адрес интернета не аннулировав первый. На этом УЦ уже обожглись.
    Последний раз редактировалось Komlin; 20.01.2003, 07:35.

    Прокомментировать:


  • Fomin
    Участник ответил
    Komlin
    чтобы однажды не прибежал десяток абонентов и сказал: у нас исчезли деньги!!!

    Где-то слышал, что до 30% операций по пластиковым картам совершаемых через интернет опротестовывается клиентами. Однако банки не спешат "закрывать" эту тему.

    Прокомментировать:


  • Fomin
    Участник ответил
    Когда я говорил про прецеденты, я имел в виду именно судебные решения. Понятно, что про "недоразумения" между клиентом и банком я слышал, но они всегда выяснялись на этапе разбирательств.
    Я же говорорю про тот случай, ради которого банку стоит использовать ЭПЦ:
    когда клиент делает платеж, а потом умышленно заявляет что ничего не делал.

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

    перехватить все остальные, в том числе и с пин-кодами
    Нуу.... если только клиент очень сильно сам этого захочет... типа на фальшивой странице будет висеть табличка: введите все 100 ваших пин-кодов и пронумеруйте :-), а клиент это выполнит.

    Зачем банку что-то доказывать?
    Я не юрист, но как тут правильно заметили, по гражданским искам действует презумпция виновности. Т.е. это именно банку придется доказывать, что клиент сделал что-то неправильно. Банку придется доказать, что он не подменял софт, не копировал скрытно ключ клиента и т.п. в ДАННОМ КОНКРЕТНОМ случае - задача на мой взгляд практически невыполнимая

    В конце концов, во всем мире стоят банкоматы. Деньги (живые бумажные деньги, а не какой-то банковский перевод) выдаются по 4 цифрам пин-кода. Банкомат полностью контролируется банком. Почему никому не приходит в голову, требовать у клиента вставить в банкомат дискету с ЭЦП?

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

    Прокомментировать:


  • Komlin
    Участник ответил
    В конце концов, поймите, это нужно не только Вашим клиентам, это нужно Вам, чтобы однажды не прибежал десяток абонентов и сказал: у нас исчезли деньги!!! Почему?!!!
    Eсли Вам кажется невероятным сам вариант подмены страницы, поройтесь в архивах хакерских сайтов:
    Вот пара примеров:
    В 2000 г. Kavkaz.org был неоднократно взломан подменой его адреса.
    В январе 2001 года lenta.ru, vesti.ru были взломаны в результате взлома Webster'om провайдера, которым пользовались их сотрудники. В результате подмены страниц были узнаны пароли на доступ к новостной ленте сайта и там размещены нескольео необычные новости.

    http://lenta.ru/internet/2000/01/10/jobless/

    Таких примеров достаточно много.

    Прокомментировать:


  • Komlin
    Участник ответил
    1) Насчёт прецедентов - были.
    Один точно был у HugeVlada (он описан где-то в форуме) клиент где-то прохлопал ключевую дискету и потерял деньги, но дело даже не дошло до суда т.к. у ПО были все необходимые и не очень сертификаты и был чётко оформленный порядок передачи ПО клиенту, согласованный с ФАПСИ.

    Были и другие о них больше знает г. Волчков, но можно и поискать по форуму -многие здесь описанны. Где-то также есть пример технической ошибки в ПО, который привёл к многократной отсылке п/п и сильной головной боли банка.

    Дак вот в том-то и дело, что получается, что клиент должен слишком много вещей делать: проверять подпись выполняемого кода, провераять подпись под ActiveX и т.п. исп. код и ACTIVEX обычно одно и тоже - AVK
    Неправильно!!! Всё это он должен сделать только при первом запуске на новом компьютере, а дальше за него всё это делает броузер, выдавая предупреждения, когда появляются какие-то изменения, например новые объекты. Ничего сложного в этом нет, поверьте клиенту по силам в этом разобраться, если он не хочет проблем.

    Теперь насчет возможности подмены страницы. На практике от этого никак не нельзя защититься. По одной простой причине: 99% клиентов НИКОГДА не проверяют сертификаты, адреса и т.п.. Жмут кнопки совершенно не глядя. :-)
    - если сертификат запрошенной страницы соответствует её имени выдаётся маленькое предупрежление о входе на защищенною страницу(кстати его обычно отключают). В противном же случае выдаётся окно на пол экрана -"Сертификат страницы не соответсвует..." и только полный простофиля не обратит на это внимание (При слепом же нажатии Enter - его просто выкинет т.к. по умолчанию стоит отказ). Кстати ложный сертификат довольно долго остаётся в логах браузера.

    Что получит злоумышленник, подменив страницу?

    Он всего лишь перехватит пароль на вход в систему. Сделать документ за клиента он не сможет как в случае с ЭЦП, как и в случае с "карточкой кодов".

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

    Т.е. в случае претензий со стороны клиента, банку придется утверждать в суде, что клиент этого всего не делал, а доказать этого банк не сможет. Это по сути эквивалетно тому, что банк пытался бы доказать, что клиент передал кому-то свой пароль и коды.
    Зачем банку что-то доказывать? Eсли ПО написанно и подписанно верно (тем более в случае стороннего пр-ля), и в нём нет ошибок/закладок, то в случае ЭЦП у банка нет технической возможности подписать что-то за клиента. Вызываете независимого эксперта и он говорит всё суду:"Если пользователь выполнял все требования инструкции, то кража по вине банка не возможна!"

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

    И совсем другая ситуация, когда в ПО есть ошибки, когда приглашённый эксперт говорит: "Да, можно подменить страницу и украсть код из-за ошибки со стороны банка."

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

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

    Утверждение о том, что страница, где запрашивается пароль и логин, уже должна быть HTTPS, правильно, но только в том случае, если пользователь параноик (из тех 100-99=1%, что я писал выше :-)), и каждый раз не ленится проверять подпись.
    Ещё раз повторюсь - если клиент набирает в браузере https:// (или вызывает по закладке, ярлыку на столе) и сертификат ей соответствует обычно никакого сообщения не выходит (максимум -крохотная ремарка). Если же там другая страница - выдатся как минимум ругательство на пор экрана и по молчанию выдаётся вариант не входить. Так что если пользователь не глядя щёлкнет Enter его просто выкинет.
    Как её сможно не заметить

    Прокомментировать:


  • Fomin
    Участник ответил
    Komlin
    Дак вот в том-то и дело, что получается, что клиент должен слишком много вещей делать: проверять подпись выполняемого кода, провераять подпись под ActiveX и т.п.
    Т.е. в случае претензий со стороны клиента, банку придется утверждать в суде, что клиент этого всего не делал, а доказать этого банк не сможет. Это по сути эквивалетно тому, что банк пытался бы доказать, что клиент передал кому-то свой пароль и коды.
    Я конечно, не юрист, но по-моему, банку в любом случае будет трудно выпутаться, хоть ЭЦП клиент использует, хоть простой пароль :-).
    Почему и говорю: интересно было бы знать практику - были такие случаи, когда клиент судился с банком, и чем это кончилось.
    Сильно подозреваю, что таких случаев не было. А если так, то получается, что мы боремся со злом, которого нет :-) Страхуемся от ситуации, вероятность возникновения которой ничтожно мала.

    Насчет простоты использования ЭЦП не соглашусь. Пароль на вход вводить всё равно нужно. А потом вводить пароль к дискете с ЭЦП или пароль из карточки - какая разница. Следить за использованием кодов тоже не надо - это делает система (ведет список всех кодов в карточке клеинта, отмечает использованные и спрашивает только неиспользованные) - этот процесс абсолютно прозрачен для клиента. Кроме того, не надо забывать об остальных неудобствах ЭЦП...

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

    Утверждение о том, что страница, где запрашивается пароль и логин, уже должна быть HTTPS, правильно, но только в том случае, если пользователь параноик (из тех 100-99=1%, что я писал выше :-)), и каждый раз не ленится проверять подпись.

    Прокомментировать:

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

Свернуть

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

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