информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыАтака на InternetВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Об ошибках в iBank 2 13.06.02 09:19  Число просмотров: 2291
Автор: cybervlad <cybervlad> Статус: Elderman
<"чистая" ссылка>
Добрый день, Александр!

> В том и только том случае если клиент может доказать
> непорядочность банка.
Это должен доказывать эксперт. Клиенту надо лишь доказать, что спорный софт получен им от банка/производителя.

> Организационные методы контроля по определению менее стойки
> нежели математические решения. Никакие орг. методы не
> способны обеспечить надёжность сравнимую со математической
> стойкостью ключа.
Александр, сейчас Вас безопасники закидают гнилыми помидорами.
Организационные меры всю жизнь были наиболее действенными при низких затратах на их реализацию. Логика проста: криптографические/математические методы сами по себе уязвимы, если не принять орг. мер. Более того, орг. методами "математику" обойти можно, обраное неверно.

> Нет. При правильной организации такой процедуры (
> передачей на CD-R, с росписями на диске и в журнале,
> фиксацией контрольных сумм) эта процедура маловероятна.
> Речь шла об атаке через WWW-сервер в предложенной процедуре
> ознакомления с продуктом.
Кстати, из начального постинга это не очень ясно.
Хорошо, давайте рассмотрим модель нарушителя в этой атаке.
1. Это сотрудник банка.
2. Этот банк использует i-bank
3. Сотрудник "окучивает" потенциального клиента подключиться к системе удаленного управления счетом (или знает, что это сделали люди из подразделения "завленкания клиентов").
4. Клиент идет знакомиться с системой на демо-стенд Бифита.
5. Всемогущий сотрудник банка устраивает подмену части кода (DLL внешней СКЗИ) с целью внедрить закладку на комп. клиента чтобы в дальнейшем, когда клиент подключится "по-настоящему", утянуть его секретный ключ ЭЦП.

Начинаем смотреть неувязки.
1. Сотрудник банка настолько крут, что может "врезаться" в канал между клиентом и Бифитом? Или у него столько денег на подкуп тех. персонала сетей?
2. Насколько мне известно, на демо-стенде не используется внешняя криптография по лицензионным соображениям (Бифит может раздавать свой продукт как угодно, но отдавать чужие DLL у него права нет). Что и где в этом случае должен подменять злоумышленник?
3. Совсем не факт, что для ознакомления и последующей работы будет использован один и тот же компьютер. Соответственно, упираться ради неясного результата никто не будет.

Лирическое отступление: тогда уж до кучи с апплетом надо подписывать и %WINDIR%\winsock.dll.

> Я писал о частном случае ознакомления. На него приведённые
> утверждения не распространялись (см. выше).
Александр, а политика? Вы думаете, что рядовой клиент разберется
в обсуждаемом вопросе и поймет, что возможность атаки, носит, скорее, теоретический характер? А осадок останется: "То ли он украл, толи у него украли..."
И еще один принципиальный момент, касающийся доказательности etc. Хорошо, пусть будет ssl, пусть будет ЭЦП аплета и всей пачки. Клиентский софт позицируется как "тонкий", это не "абоненткий пункт сети секретной связи", выражаясь армейским языком, на котором ведутся журналы работы. Что клиент будет предъявлять в арбитраже? Типичная отмазка нечестного банка: "У нас все нормально, можете посмотреть на сервере, а откуда взялась эта кривая DLL на компьютере клиента, мы не знаем".
Нет, все-таки тут надо не мудрить, а принять недорогие орг. меры с правильной передачей дистрибутива СКЗИ клиенту (договор, контрольне суммы). И клиент будет защищен юридически, и нечестному асуизатору в банке (буде такой найдется) неповадно будет...

/Vlad.
<theory> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach