21 июля, воскресенье 00:50
Bankir.Ru

Объявление

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

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

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

  • #31
    Komlin
    Хм... Да, можно много чего накрутить еще... Но всё равно, код этот лежит на сайте банка и что конкретно загружается клиенту, конролируется банком. Не думаю, что клиент каждый раз будет проверять, подписан ли код, не подписан ли.... Может ли вообще клиент быть на 100% уверен, что именно выполняется на его машине? Интересный вопрос... Думаю, что всё таки нет.
    Предварительная установка кода на машину клиента конечно, несколько усложняет подмену банком этого кода, но не делает это теоретически невозможным: можно выполнить какой-нибудь ActiveX на клиентской машине и т.п. (а как банк докажет, что он такого не делал?).... Понятно, что это сложно, но суд в такой ситуации будет волновать не сложность этого действия, а есть ли 100% уверенность, что банк этого не мог сделать? Опять же говорю, приглашенный эксперт вряд ли ответит утвердительно...

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

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

    закрыли код самого модуля ЭЦП - не готов ответить. Надо подумать...

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

    Комментарий


    • #32
      Komlin
      Нет, Вы не правы насчет посылки пароля открытым текстом. Там не всё так просто, как кажется :-) Сейчас специалист ушел, отвечу в понедельник как точно там делается....
      Сейчас могу наврать, но по-моему, при нажатии кнопки поля очищаются и обращение идет по другой ссылке и там уже логин и пароль шифруются...
      Я помню, специально делали какую-то хитрую схему при входе именно для того, чтобы логин и пароль шифровались при передаче, но не кешировались в ИЕ. Была проблема, что ИЕ предлагал сохранить пароль, пользользователи не думая наживали "Да", а потом любой севший за их компьютер видел их остатки :-)

      Комментарий


      • #33
        Механизатор учёта Как много слов, и как мало смелости :-) Интернет-общение без сомнения портит некоторых людей :-)

        Комментарий


        • #34
          Постинг удалён как злостный дубель, см. ниже.
          Последний раз редактировалось Komlin; 18.01.2003, 01:55.

          Комментарий


          • #35

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

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

            Кстати правильно настроенный и защищённый орг. мерами пользовательский комп. взломать очень трудно, поверьте мне.

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

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

            Последний раз редактировалось Komlin; 18.01.2003, 02:21.

            Комментарий


            • #36
              Спасибо за замечание, я посмотрел повнимательнее, действительно отсылка производится уже в закрытую страницу:

              form method="post" name="LoginForm" action="https://dzerbank.ru/InternetBank/Login.asp">

              но проблема всё равно остаётся: сама страница ввода запрашивается по http:// прокотолу и никак не защищена, поэтому может быть легко подменена.

              ******************************
              Общее правило - все страницы в которых работают с паролями должны доставлятся и обрабатываться в https://. В противном случае данные нетрудно перехватить тем или иным способом
              *********************************


              У Вас явно нарушен пункт 1. Рецепт на исправление тот же.
              Извините за небольшую путаницу,
              мне просто было некогда подробно разбираться т.к. у нас глубокая ночь.

              Комментарий


              • #37
                Совсем не стремлюсь обидеть, но вообще Ваш сайт является примером неправильной работы с сетификатами ( просто по незнанию оcобеностей IE или невнимательности), ибо Вы явно не скупились (не ленились) :купили хороший сертификат, заверенный дорогим АЦ и поставили приличный SSL-сервер.

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

                Первая ошибка:
                Следуя ссылке на страницах банка
                пользователь начинает работу с Банк-клиентом с незащищённого адреса
                http://dzerbank.ru/Index.asp?Id=IBLogin
                (и наверняка уже занёс его в "Избранное" или "Рабочий стол").

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

                Таким образом большинство Ваших пользователей пользователь изначально привыкает к неправильному алгоритму работы.

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

                Совершенно неожиданно помощь атакующему приходит с самого сервера.

                На первый взгляд там всё хорошо, оставшиеся страницы работает ч/з SSL, защищена сертификатоми т.п.

                Читаем инструкцию как проверять подлинность страницы:
                http://dzerbank.ru/Index.asp?Id=IBLogin

                Для того, чтобы убедиться, что это действительно сайт Коммерческого Банка "Дзержинский", проверьте строку адреса Вашего броузера:

                далее на сайте приведена картинка изображающая фрагмент сроки адреса браузера с текстом
                Адрес: http://dzerbank.ru/ (!?)
                !!! Простите, кто ж так делает - для обмана невнимательного пользователя даже особо напрягаться не придётся - штампуй все странички с одного адреса.
                У HugeVlada или Экспертика и т.п. конечно не украдут, а как быть с начинающим пользователем неспециалистом в ИТ, внимательно изучившим Ваши советы на странице входа?
                Во первых даже адрес неправильный (?!) - должно быть что-то вроде
                https://dzerbank.ru/Index.asp?Id=IBLogin
                https://dzerbank.ru/InternetBank/Index.asp

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

                Подлинность страницы проверятся только щелчком по замочку в строке состояния с изучением появившегося сертификата, и сравнением с Файл/Свойства .

                Почему? Да потому, что верхнее окошко адреса элементарно подделать (нижнее не получится-будет видна пустая белая строка).

                Пусть например пользователь ожидает появления адреса вроде
                https://dzerbank.ru/InternetBank/Index.asp?Id=Transfer

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

                Пример для разрешения 800*600 (разумеется на практике создаются универсальные пример, с селектором разрешений и цветовых схем)

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

                ******************************
                -subst.htm

                html>
                title>Интернет-Банк | Операции | Переводы между счетами/title>
                body leftmargin=1 topmargin=1>
                img src="addr2.jpg">
                ...
                Копия оригинальной странички
                /html>
                Вот и всё. Пользуюясь Вашими рецептами пользователь даже не заметит подмены и спокойно введёт pin-код.
                Образец приведён по адресу.

                http://avkpalm.front.ru/sub3.htm

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

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

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

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

                Рецепты устранения ошибки просты:
                Изменить ссылку на полную как уже предлагалось выше.
                httpS://dzerbank.ru/Index.asp?Id=IBLogin

                На старой странице
                http://dzerbank.ru/Index.asp?Id=IBLogin
                разместить уведомление о необходимости смены закладок или ярлыков если таковые имеются

                Привести более корректные инструкции для проверки подлинности страниц.
                Последний раз редактировалось Komlin; 19.01.2003, 04:36.

                Комментарий


                • #38
                  Fomin Механизатор учёта, просьба личные вещи в привате выяснять.

                  Комментарий


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

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

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

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

                    Комментарий


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

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

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

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

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

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

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

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

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

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

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

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

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

                      Комментарий


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

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

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

                        Комментарий


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

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

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

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

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

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

                          Комментарий


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

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

                            Комментарий


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

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

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

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

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

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


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

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

                              Комментарий


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

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

                                Комментарий


                                • #46
                                  Komlin
                                  Приветствую!

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

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

                                  Комментарий


                                  • #47
                                    Приветствую Вас Алексей!
                                    Приветствую Вас Влад!

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

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

                                    Комментарий


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

                                      Комментарий


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

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

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

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

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

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

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

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

                                        Комментарий


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

                                          Комментарий


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

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

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

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

                                            Комментарий


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

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

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

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


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

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

                                              Комментарий


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

                                                Комментарий


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

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

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

                                                  Комментарий


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

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

                                                    Комментарий


                                                    • #56
                                                      Fomin

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


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

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

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

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

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

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

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

                                                      Комментарий


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

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

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

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

                                                        Комментарий


                                                        • #58
                                                          GeC

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

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

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

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

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

                                                          Комментарий


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

                                                            Комментарий


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

                                                              Комментарий

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

                                                              Свернуть

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

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