Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Первый в Рунете публичный аудит почтовой системы 03.06.02 04:19 Число просмотров: 2960
Автор: Serge3 Статус: Незарегистрированный пользователь
Отредактировано 03.06.02 11:15 Количество правок: 4
|
Здравствуйте,
> Пример: процедура вычисления шифра к секретному ключу на
> основе пароля :
> ... return messagedigest.digest();
> }
Я правильно понял, что ключ шифруется на результате однократного применения хэш-функции MD5 к паролю пользователя без случайной добавки?
Зашифрованный ключ сравнительно свободно доступен любому пользователю Internet?
Следовательно, к паролю надо предъявить достаточно жесткие требования на случайность, т.к.:
- возможен "мгновенный" подбор по словарю;
- скорость подбора на одном узле сети не менее, по порядку величины, 10^6 паролей в секунду, т.е. отмороженный хакер, может за год перебрать до 10^18 паролей или получить ключи для 1/10 всех пользователей всех систем с S-Mail-ом даже для Вашей сильно завышенной оценки множества паролей ~70^10. Вот в мощность множества паролей 10^6 поверю, ну 10^9 для параноиков.
В общем, это сильно не стойкая идея хранить ключи в сети.
Успехов.
--
"Serguei E. Leontiev"<lse@CryptoPro.ru>
http://www.cryptopro.ru
|
|
<theory>
|
Первый в Рунете публичный аудит почтовой системы 28.05.02 16:37
Автор: S-Mail Статус: Незарегистрированный пользователь
Отредактировано 01.06.02 10:33 Количество правок: 1
|
Первый в Рунете публичный аудит почтовой системы
Компания Network Research Lab (NR Lab), владелец S-Mail.com, провела независимый аудит безопасности своего сервиса защищенной электронной почты.
Исследование проводилось по инициативе и при содействии компании Network Research Lab (NR Lab), владельца сервиса S-Mail.com. В связи с высокой общественной значимостью сервиса и желанием эксперта оставаться независимым в своих оценках экспертиза проводилась на некоммерческой основе.
«То, что компания NR Lab рискнула прибегнуть к публичному аудиту по
безопасности сервиса S-Mail, безусловно свидетельствует о серьёзном и ответственном подходе компании к заявленным ей целям по созданию системы защищенной почты мирового уровня» – заявил A.V. Komlin.
Тестирование безопасности почтового сервиса S-Mail.com проходило в течение недели с 14 по 19 мая 2002 года по следующим направлениям:
1) возможность несанкционированного доступа постороннего лица к частной переписке пользователей S-Mail;
2) возможность атаки злоумышленника на компьютер пользователя сервиса c использованием S-Mail.
С целью повышения достоверности исследование проводилось путем декомпиляции апплетов, выдаваемых сервером S-Mail, а также анализом открытых HTML-cтраниц и JavaScript-библиотек.
«История известных российских и зарубежных почтовых сервисов показывает, что все они содержат значительное количество ошибок, которые будут обнаруживаться вновь и вновь во всех без исключения системах – говорит г-н Комлин. – Поэтому при выборе службы электронной почты следует уделять большое внимание не перечню недочетов, а времени и качеству их устранения, а также политике владельцев сервиса в области поиска таких ошибок».
Главный итог проведенного аудита: подтвержден основной принцип сервиса S-Mail.com – высочайшая защищённость переписки. Раскодирование и прочтение сторонними злоумышленниками текстов писем признано невозможным.
В процессе тестирования экспертом A. V. Komlin также не выявлено возможностей захвата пользовательского почтового ящика при условии использования браузеров с установленными «заплатками» и внимательном поведении пользователя.
Обнаруженные и устраненные ошибки системы:
1. Неточность в процедуре аутентификации, позволявшая отслеживать логи входящей почты пользователя - адреса абонентов, дату и поле темы. Данная уязвимость не позволяла просмотреть содержание корреспонденции и не давала доступа к его паролю и секретному ключу.
Время устранения ошибки - 2 часа после извещения.
2. Возможность несанкционированного исполнения JavaScript из-за неточной обработки ссылок в тексте письма. Код выполнялся только при проведении курсора «мыши» над ссылкой. Видимый текст ссылки при этом содержал операторы JavaScript, что давало внимательному пользователю возможность избежать срабатывания кода. Данная ошибка также не давала доступа к паролю и секретному ключу абонента.
Время устранения - 3 часа после извещения.
Как рассказал Николай Гудов, технический директор S-Mail.com, «благодаря проведенной экспертизе мы получили возможность со стороны оценить надежность нашего сервиса. Квалифицированный аудит по сетевой безопасности, выполненный г-ном Комлиным, позволил нам ещё более защитить сервис S-Mail.com от посягательств третьих лиц.
Ведь мы всегда в ответе перед нашими пользователями за то, что S-Mail –
это действительно защищенная почта».
* * *
О Network Research Lab Ltd.
Компания Network Research Lab Ltd. (NR Lab) - это специализированная IT-компания, разрабатывающая
и продвигающая программные решения, которые обеспечивают высокий уровень защиты данных
при передаче и хранении в сети Интернет.
За дополнительной информацией обращайтесь по телефону (095) 937-4709
или e-mail: mailto:info@s-mail.com веб-сайт: http://www.nrlab.com/
Об A. V. Komlin
A.V. Komlin – признанный эксперт в области защиты информации в Интернете. Автор целого ряда статей по вопросам уязвимостей в системах web-почты. Победитель «HackZone’99».
За дополнительной информацией обращайтесь по e-mail: avkvladru@mail.ru
S-Mail
|
|
S-Mail. Впечатления проверяющего. Вступление. 31.05.02 11:15
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 31.05.02 11:16 Количество правок: 1
|
Уважаемый читатель. Эта заметка не является каким-то официальным отчётом по тестированию S-Mail. Речь идёт просто о впечатлениях от работы с системой. Поэтому умышленно не оформлял её в виде статьи.
Предыстория:
Где-то пол-года назад в Рунете появилась новая почтовая служба. От своих многочисленных собратьев она отличалась интересным свойством. Эта почта была изначально ориентированна на безопасность пользователя. Для реализации задуманного в ней применялось полное (нередко избыточное) шифрование всей входящей и исходящей корреспонденции при помощи ассиметричных ключей. Как потом выяснилось она довольно интенсивно рекламировалась в сети.
К своему сожалению, я полностью прозевал это событие и узнал о нём только когда пару недель назад обратился один из разработчиков системы с предложением о "публичном аудите сервиса".
Учитывая, что это предложение само по себе уникально, отказаться не смог несмотря на то, что не являюсь в своих глазах экспертом в таких вопросах.
Свои впечатления от данного проекта я разбил на три части выложенных в последующих сообщениях . Первая часть касается применения ассиметричной криптографии в Интернете.
Приложение 1.
Схема работы почты и её отличия от обычных решений в области защиты переписки.
Для клиента схема работы системы достаточно проста: в процессе регистрации случайным образом генерируется его секретные ключи для шифрования почты и цифровой подписи. Затем они шифруются с помощью выбранного пользователем пароля и шифр отсылается на сервер. Туда же отсылаются и открытые ключи с помощью которых будет происходить общение с другими абонентами.
При входе пользователя в сервис осуществляется обратная операция. По её окончании на сервер отсылается случайный подписанный код и если его проверка подтверждает подлинность абонента последний получает доступ к своему почтовому ящику.
Вся информация (письма) в ящике также хранится в зашифрованном виде. Их дешифровка происходит непосредственно на компьютере посетителя.
Все отправляемые ему ( или им) письма шифруются с помощью его (или адресата) открытого ключа непосредственно на машине отправителя и на сервер поступают уже в закодированном виде.
Таким образом, теоретически, никто кроме самого читателя не сможет прочитать свою корреспонденцию. Всё это происходит абсолютно незаметно для пользователя и внешне работа с системой ничем не отличается от своих WWW-собратьев, кроме чуть более медленной загрузки системы.
Максимум на что (в теории) может рассчитывать сотрудник или взломщик сервера , это прочитать не шифруемые заголовки почты (адреса, дату, тему (subject) письма).
Вся клиентская часть реализована на Java и Javascript. Их анализ не составляет большого труда т.к. коды апплета не обфусцированы.
|
| |
S-Mail. Впечатления проверяющего. ч.1. Результаты тестирования. 31.05.02 11:24
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 31.05.02 14:25 Количество правок: 1
|
Р
Разумеется первым, что бросилось в глаза было отсутствие рекламы. Появился резонный вопрос: за счёт чего окупается подобное решение, не бесплатный ли это сыр (конечно, просто бесплатное ПО уже никого не удивляет, но поддержание WEB-сервера требует приличных расходов)? Ответ нашёлся прямо в описании сервиса : компания позиционирует себя как поставщика комплексных решений для организаций и в том числе продаёт расширенную коммерческую версию данного сервиса.
Сразу оговорюсь, что проверялась только бесплатная версия данного сервиса. Не забывайте об этом, особенно читая последний пункт: "приципиальные недостатки".
Недостатки собственно сервиса.
Стойкость данного сервиса зависит от двух компонентов:
стойкости клиентского ПО;
стойкости самого сервера ( в меньшей степени);
Результаты проверки клиентского ПО
Предполагалось, что пользователь не держит одновременно открытых окон с другими страничками из неизвестных источников и использует последние версии браузеров свободные от ошибок. Вообще хочу подчеркнуть, что при работе с любой Web-почтой недопустимо открывать предложенные в письмах неизвестные ссылки не выйдя из сервиса. Особенно в сервисах с поддержкой процессов Java.
Рассматривались две типовые схемы:
а) Возможность несанкционированного исполнения тегов и JavaScript в письме.
Наличие такой возможности позволило бы атакующему выполнять любые команды криптобиблиотеки.
Использованный S-Mail подход был достаточно кардинален: фильтруются все
теги и опасные символы. К сожалению вкралась пара ошибок в автоматическое распознавание и обработку ссылок привёдшая к возможности вставит в них операторы обработки событий (например onMouseOver срабатывавший при наведении мышки).
При этом операторы JS виднелись в тексте ссылки, что позволяло опытному пользователю избежать атаки.
Рекомендации: внимательнее смотреть на текст письма и пользоваться своевременно обновляемыми браузерами.
б) ошибки криптобиблиотеки, позволяющие лицу имеющими доступ к к серверу дешифровать отдельные письма.
Практически применимых слабостей обнаружено не было.
Имелись лишь некоторые теоретические слабости, недостаточные для самостоятельного использования (при выполнении вышеописанных условий).
Ни одна из описанных уязвимостей не позволяла украсть пароль или секретный ключ.
В этом форуме и на bankir.ru активно обсуждаются потенциальные слабости генерации секретного ключа, но к единому мнению пока не пришли. Скорее всего слабость останется в разряде теоретических.
Ошибки сервера:
Найти ошибку позволившую взломать сервер ( имеется в виду хотя бы получение контроля над WWW) мне не удалось.
Задача получения доступа к хранилищу (логам) почты (списку абонентов и адресатов, теме (subj), дате писем) относится к более лёгким и её удалось решить дважды. В обеих случаях найденная ошибка устранялась почти мгновенно ( в течении пары часов с момента отправки письма). Разумеется, доступ к логам не означал каких-то дополнительных возможностей по прочтению текста письма, т.к. для шифрования используются очень стойкие методы. Заодно это служило неплохим подтверждением пользы хранения писем в зашифрованном виде, т. к. аналогичная возможность на обычных серверах приводила к свободному чтению корреспонденции.
Должен сказать, что количество и опасность обнаруженных ошибок по отношению к затраченному времени были очень малыми для службы насчитывающей меньше полугода от роду. Обычно, даже поверхностный взгляд на новую web-почту давал более серьёзные последствия.
Принципиальные недостатки использованных решений:
Самым спорным решением авторов системы безусловно является пароль. Как уже отмечалось во "вступлении" он же является ключом для шифрования секретных ключей. Его размер конечно, не ограничен.
В то же время, как отметили в обсуждении на bankir.ru почти все присутствовавшие там специалисты по криптографии (А. Волчков, А. Репан,"Экспертик") редкого пользователя удаётся заставить использовать более чем десяти-символьный моно-алфавитный пароль.
Соответственно количество вариантов для перебора у большинства пользователей составит не более, чем 70^10 ~= 10^19. Этого, разумеется, мало.
Но трудно обвинять в этом почту, просто потому, что никто не мешает пользователю выбрать ключ любого размер и алфавита. Например фразу. Также следует учесть, что пока не видно других простых и удобных решений по защите секретного ключа хранящегося на сервере. В общем: "Спасение утопающих- дело рук...". Единственное, что можно поставить в упрёк - отсутствие указаний на роль пароля при его выборе.
Другим слабым моментом является хранение открытых ключей на самом сервисе s-mail что приводит к объединению каналов получения ключа и передачи данных (см. ч.3 "АШК и Интернет"). Причина этого решения также очевидна - известные мне другие хранилища ключей платные.
О том, как бороться с этими недостатками читайте в ч.2.
|
| |
S-Mail. Впечатления проверяющего. ч.2. Советы пользователю. 31.05.02 11:21
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 01.06.02 14:02 Количество правок: 2
|
Практические советы по безопасному использованию почты.
Советы пользователю.
Самое главное - ящик для секретной переписки- должен быть ящиком для секретной переписки. Не стоит использовать указывать его при получении сторонней информации: например при регистрации в службах поддержки или давать малознакомым людям. Если Вам всё же лень просматривать несколько почт - откройте ящик на любом сервисе поддерживающем пересылку (mail.ru, pochtamt.ru) и настройте переадресацию на s-mail. Теперь всем посторонним вы даёте открытый ящик.
Начинать беспокоиться о своей безопасности следует уже с момента регистрации:
Помните, что вводимый Вами пароль на самом деле является ключём. Если даже Вас не волнует возможность дешифровки сотрудниками самой почты - всё ограничитесь "снизу" фразой из двух трёх слов, желательно в разных алфавитах. Полностью безопасным можно считать моноалфавитный пароль из 32 букв или смешанный Если Вам трудно набирать её и вы уверенны в недоступности своего компьютера занесите большую часть её в макрос и назначьте какому-нибудь сочетанию клавиш.
Помните говорить о какой-то криптозащите писем можно лишь в случае обмена между двумя пользователями s-mail.
Помните, что из-за особенностей современных браузеров при работе с WWW-интерфейсом почты нельзя открывать предложенные в письмах неизвестные ссылки не выйдя из сервиса. Если ссылка длинная и запоминать не хочется занесите ссылку в буфер обмена правой кнопкой мыши.
Также, с учётом большого числа ошибок выявляемых в любых браузерах необходимо регулярно патчить последние.
Советы параноику.
При заходе на сервис внимательно посмотрите на страничку -нет ли на ней каких изменений, правильна ли подпись апплета.
Недавно в сервисе появилось дополнение- plug-in для работы ч/з Outlook 2000.
Как уже отмечалась - ассиметричная криптография в интернете вещь мало совместимая с адресным контролем. Но не отчаивайтесь. Есть простой способ проверки на применение к Вам подобного приёма: дело в том, что при используемой схеме шифровки (текст шифруется сеансовым
симметричным ключём, последний шифруется открытыми ключами отправителя и получателей), защищённый тест должен:
а) выглядеть одинаково у отправителя и получателя;
б) дешифровываться обеими сторонами;
Это свойство алгоритма ДХ позволяет легко обнаружить подмену ключей.
Применительно к s-mail это означает, что сохранив письмо при отправке в папке Sent (или наоборот получив его), Вы можете
а) просмотреть его и убедиться что письмо дешифровалось Вами;
б) посмотреть исходный HTML в поле письма (В IE это производится щелчком правой кнопки мыши и выбором пункта "просмотреть источник") найти поле <input name="text" value=...>.
в) отослать по другим каналам фрагмент поля value получателю и попросить его сравнить поля. Если они совпали - Вам пока не о чем беспокоиться.
Проще всего реализовать это заведя второй ящик и периодически проводя процедуру проверки.
Разумеется программист может сделать проще - единожды выполнив подобную проверку написать утилитку которая будет запрашивать с public.s-mail.com открытый ключ и сравнивать её с полученным при первом запросе. Если будет время- выложу подобную утилиту сам.
Вроде всё, самое главное сказал.
:)
|
| |
S-Mail. Впечатления проверяющего. ч.3. АШК и Интернет 31.05.02 11:18
Автор: Komlin Статус: Незарегистрированный пользователь
|
Вначале о грустном: схемы с ассиметричной криптографией несмотря на их широчайшее применение в интернет (они применяются в протоколе ssl, имеющемся в любом браузере) по сути недопустимы. Дело в том, что по определению их нельзя применять на незащищённых от модификации каналах. Причина проста: любой провайдер в состоянии подменить открытые ключи участников на свои . В этом случае он сам расшифровывает информацию читает её, зашифровывает своим ключём и отсылает. От этой проблемы пока защищаются исключительно организационными мероприятиями - разнесением каналов передачи данных и мест хранения ключей и некоторыми другими методами (см. ниже). Защита эта достаточно условна, поэтому ни одна спецслужба так и не перешла и не перейдёт на применение открытых ключей.
В то же время "всеобщее" прослушивание сообщений с применением асимметричного шифрования невозможно, поэтому даже в условиях тотального, но не адресного контроля в интернет можно писать всё что угодно, не боясь что Вас услышит "Эшелон" или "СОРМ" . Вскрытие схемы АШ возможно лишь при адресном подходе. Кроме того оно весьма сложно технически и довольно легко обнаружимо на практике.
Поэтому системы, подобные PGP, S-Mail применялись, применяются и будут применяться в интернете. В них так же использованы решения частично снижающие риск работы с системой (см. раздел "практические советы").
Вышесказанное не относится к тем случаям, когда имеется возможность передать открытый ключ из рук в руки. Например на распечатке заверенной печатью и подписью. Эта практика широко применяется для цифровой подписи.
|
|
Первый в Рунете публичный аудит почтовой системы 29.05.02 15:58
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Тестирование безопасности почтового сервиса S-Mail.com
> проходило в течение недели с 14 по 19 мая 2002 года по
> следующим направлениям:
>
> 1) возможность несанкционированного доступа постороннего
> лица к частной переписке пользователей S-Mail;
> 2) возможность атаки злоумышленника на компьютер
> пользователя сервиса c использованием S-Mail.
это все замечательно, техническую часть проверять тоже надо. но самое сложное - аудит организационной части. никто не полезет ломать защиту в самом укрепленном месте (почти не сомневаюсь в квалификации разработчиков). а вот это (орг. аудит) как раз сделать проблематично...
|
| |
Первый в Рунете публичный аудит почтовой системы 30.05.02 11:22
Автор: Весельчак Статус: Незарегистрированный пользователь
|
> это все замечательно, техническую часть проверять тоже
> надо. но самое сложное - аудит организационной части. никто
> не полезет ломать защиту в самом укрепленном месте (почти
> не сомневаюсь в квалификации разработчиков). а вот это
> (орг. аудит) как раз сделать проблематично...
Напрасно не сомневаетесь...
Когда пол-письма видно всеми желающим - это что-то с чем-то.
(см. мои вопросы Komlinу)
Как раз орг. аудит здесь нафиг не нужен:
Если письма хранятся на сервере в зашифрованном виде то меня это не волнует. Кто-там и что там у них на сервере сломает.
|
| | |
Первый в Рунете публичный аудит почтовой системы 30.05.02 13:01
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Напрасно не сомневаетесь...
я сказал "почти" ;)
> Когда пол-письма видно всеми желающим - это что-то с
> чем-то. (см. мои вопросы Komlinу)
посмотрю
> Как раз орг. аудит здесь нафиг не нужен:
спорно
> Если письма хранятся на сервере в зашифрованном виде то
> меня это не волнует. Кто-там и что там у них на сервере
> сломает.
а как генерились ключи, которыми они шифруются? как организован обмен открытыми ключами? как хранится корневой самоподписанный сертификат (если там вообще PKI, а не просто обмен открытыми ключами)?
если эти вопросы решены неправильно, то "о вашей тайне будут знать только двое: вы и КГБ" ;))
|
| | | |
Первый в Рунете публичный аудит почтовой системы 01.06.02 13:52
Автор: Komlin Статус: Незарегистрированный пользователь
|
Приветствую, Влад.
>а как генерились ключи, которыми они шифруются?
Ключи генерируются на машине пользователя.
Стойкость алгоритма обсуждалась на форуме bankir.ru (А. Волчковым, Д. Репаном, Натальей Б.)
В принципе, ничего страшного там не нашли: биологический датчик был признан не очень удачным, но процесс генерации ключа включал ещё несколько этапов и случайных значений (параметры JVM, пути, версии ПО, память системы, время выбора пароля), так что эксплойт им не грозит.
Впрочем разработчики s-mail вроде учли эти замечания (и некоторые другие, сделанные в процессе тестирования) и в новой версии
обещают в корне переделать всю процедуру генерации ключа, а заодно и расширить варианты набора пароля ( в частности сделать набор мышкой с эмулятора клавиатуры).
>как
> организован обмен открытыми ключами? как хранится корневой
> самоподписанный сертификат (если там вообще PKI, а не
> просто обмен открытыми ключами)?
> если эти вопросы решены неправильно, то "о вашей тайне
> будут знать только двое: вы и КГБ" ;))
Влад, работа с ассиметричным шифрованием в Интернет, в принципе, не спасает от адресного внимания спецслужб. Интернет неприменим как канал передачи открытых ключей по определению. Это надо четко осознавать при работе с ним и рассматривать s-mail как средство повышения конфиденциальности почты по отношению к стороннему злоумышленнику, но не как панацею. В этом плане она (вернее её принципы) вне конкуренции.
Честно говоря это первая российская почта к которая действительно пытается быть конфиденциальной, в тяжких условиях WWW-интерфейса (простоты освоения/пользования) и бесплатности ;) . Именно из этого я и исходил при проверке и в своём заключении (процитированном в пресс-релизе) не затрагивал принципиальных недостатков подобной схемы. Отчасти и потому, что они не меньшие, чем проблемы в других решениях (том же PGP).
Поэтому организационный аудит только по отношению к серверу мало, что даст пользователю. Такие вещи проводятся с двух сторон, включая каналы. Впрочем, судя по политике s-mail они когда ни будь пойдут и на это, похоже люди действительно хотят сделать хороший продукт.
Александр.
P.S. Для желающих обезопаситься от подмены ПО на сервере (на случай взлома), уже есть локально работающий plug-in к Outlook'2000, хотя я не вижу особой разницы кого взламывать: сервер или машину пользователя. Пожалуй первый гораздо надёжнее когда речь идёт о неискушённом пользователе. Да и Outlook'2000 ещё то чудо.
P.P.S. Если Вы собираетесь обсуждать секреты, затрагивающие личность г. Пyтинa Вам лучше обратиться к классическому симметричному шифрованию от солидных фирм:).
P. P. P. S. Я не собирался рекламировать s-mail, никак не связан с ними материально, просто высказываю своё мнение считая, что любой человек вправе похвалить понравившийся ему продукт…
|
| | | | |
Первый в Рунете публичный аудит почтовой системы 03.06.02 09:04
Автор: cybervlad <cybervlad> Статус: Elderman
|
Добрый день, Александр.
> а заодно и расширить варианты набора пароля ( в частности
> сделать набор мышкой с эмулятора клавиатуры).
Я тут видел еще более крутой вариант для параноиков - ввод азбукой Морзе через клавишу NumLock :)
> >как
> > организован обмен открытыми ключами? как хранится
> корневой
> > самоподписанный сертификат (если там вообще PKI, а не
> > просто обмен открытыми ключами)?
> > если эти вопросы решены неправильно, то "о вашей тайне
> > будут знать только двое: вы и КГБ" ;))
>
> Влад, работа с ассиметричным шифрованием в Интернет, в
> принципе, не спасает от адресного внимания спецслужб.
Александр, при правильном подходе - спасает. Это азбучная истина. Впрочем, Вы ответили на вопрос выше "там вообще PKI, а не
> > просто обмен открытыми ключами". PKI там и не пахнет, а в "голом" виде ассиметричная криптография действительно беззащитна против MitM-атак.
> Интернет неприменим как канал передачи открытых ключей по
> определению. Это надо четко осознавать при работе с ним и
По определению, единственный канал, которым можно передавать открытые ключи (а не сертификаты!) - личная встреча. Поэтому в чистом виде это нигде и не применяется.
> рассматривать s-mail как средство повышения
> конфиденциальности почты по отношению к стороннему
> злоумышленнику, но не как панацею. В этом плане она (вернее
> её принципы) вне конкуренции.
Т.е. Вы прилюдно заявляете, что в общем случае "сторонний злоумышленник" не имеет возможности изменить маршрут прохождения трафика между клиентом и сервером S-MAIL и сделать тот самый MitM?
Я бы не был столь категоричен ;) Со своей стороны, не стану утверждать, что каждый школьник, начитавшийся журнала "Ксакеп", сможет это сделать. Но задачка эта под силу не одним только спецсслужбам ;)
> Честно говоря это первая российская почта к которая
> действительно пытается быть конфиденциальной, в тяжких
> условиях WWW-интерфейса (простоты освоения/пользования) и
А что, кто-то силком заставлял через веб это делать? ;) Это что-то вроде: "Ребята, у вас не очень круто получилось", "Так мы, стоя на голове это делали!", "А, ну тогда конечно". Я прошу не обижаться уважаемый S-MAIL, но выбор в пользу веб-интерфейса не есть причина, по которой нельзя было сделать какое-либо подобие PKI. А схема реализации настолько тривиальна, что даже нет желания ее расписывать.
Зачем выбирают веб-интерфейс? Правильно, для обеспечения мобильности (читай: удобства). А удобство и безопасность всегда в противофазе ;)
> Отчасти и потому, что они не меньшие, чем проблемы в других
> решениях (том же PGP).
Щаз! Попробуйте в PGP нормально поработать без заверения ключа. Конечно, можно самому заверить, но это уже на свой страх и риск...
Что в PGP, что в GNUPG сделана распределенная система сертифкации ключей. Кстати, при разумном подходе и отсутствии общей доверенной точки, можно произвести безопасный обмен ключами и без личной встречи. Надежность, конечно, уже не 100%, тем не менее...
> Поэтому организационный аудит только по отношению к серверу
> мало, что даст пользователю. Такие вещи проводятся с двух
Среднестатистическому пользователю - вообще по барабану. Вы на меня в прошлый раз обиделись за замечание про НИИ, а мне постоянно приходится общаться с будущими юзерами системы конфиденциальной связи. После длительных душевных разговоров, в процессе которых на пальцах объясняется что такое несимметричная криптография (никакой математики! только аналогия с сундуком, замком и ключом!), о пользе и необходимости самостоятельной генерации ключа, клиент произносит фразу почти как в анекдоте ("ты не выпендривайся, а рукой покажи!"), в смысле, дайте мне дискетку с "кодом", желательно без пароля. Занавес.
> сторон, включая каналы. Впрочем, судя по политике s-mail
> они когда ни будь пойдут и на это, похоже люди
> действительно хотят сделать хороший продукт.
Совершенно верно, для полной уверенности нужен полный аудит сети связи. Но для публичного веб-сервера это невозможно.
Собственно, после Ваших пояснений о ключевой системе S-MAIL, я согласен, что аудит центра там не нужен, ибо PKI отсутствует и там просто нечего проверять.
> P.S. Для желающих обезопаситься от подмены ПО на сервере
> (на случай взлома), уже есть локально работающий plug-in к
> Outlook'2000, хотя я не вижу особой разницы кого
...который также загружен по non-trusted каналу (ИНтернет) ;))
> P.P.S. Если Вы собираетесь обсуждать секреты, затрагивающие
> личность г. Пyтинa Вам лучше обратиться к классическому
> симметричному шифрованию от солидных фирм:).
Не собираюсь ;) Я существо более примитивное, меня больше заботят такие банальности, как коммерческая тайна и авторские права. ;)
> P. P. P. S. Я не собирался рекламировать s-mail, никак не
> связан с ними материально, просто высказываю своё мнение
> считая, что любой человек вправе похвалить понравившийся
> ему продукт…
Угу. Но есть решения проще. Когда возникла надобность в конфиденциальной переписке (соавтор статьи в живет другом городе), был просто выкачан GNUPG, собран из исходников, сгенерированы ключи. Обмен ключами, естессно, произошел по интернет, но вот fingerprint ключей был сверен по нескольким независимым каналам. Пользуемся до сих пор, тем более, что однажды появилась оказия пересечься лично, и теперь уверенность в достоверности полученных ключей - 100%. ;)
А главное, что характерно ;), мы не приявязаны к конкретному сервису и каналу передачи.
|
| | | | | |
Первый в Рунете публичный аудит почтовой системы 03.06.02 11:25
Автор: Komlin Статус: Незарегистрированный пользователь
|
Привет Влад.
> Добрый день, Александр.
> Я тут видел еще более крутой вариант для параноиков - ввод
> азбукой Морзе через клавишу NumLock :)
:))) Речь идёт о том, чтобы осложнить жизнь снифферу. Многие (я например) ведь работают с
веб-интерфейсов в командировках. По-моему редкая гостиница и интернет кафе не
оборудованна клавиатурным снифером. А вот комплексные мышинно-экранные- экзотика.
Экранная клавиатура-же штука довольно удобная, как Palmовод сужу. По крайней мере
она приемлемое по балансу между удобством и защите решение
> > Влад, работа с ассиметричным шифрованием в Интернет, в
> > принципе, не спасает от адресного внимания спецслужб.
> Александр, при правильном подходе - спасает. Это азбучная
> истина.
Как именно? Если перехвачен канал на уровне провайдера, то все попытки
бессмысленны. Другое дело, что правильное применение ( сертификаты,
разнесение каналов получения ключа и данных и т.п.) осложняют
техническую сторону подмены, но не решают проблему. А если проверка не адресная (
столь популярноое ныне сканирование на ключевые слова), то s-mail - приемлемая защита.
> По определению, единственный канал, которым можно
> передавать открытые ключи (а не сертификаты!) - личная
> встреча. Поэтому в чистом виде это нигде и не применяется.
Угу. Именно это я и хотел сказать ( ну может ещё телефонный
разговор если у Вас хороший слух на голоса).
> Т.е. Вы прилюдно заявляете, что в общем случае "сторонний
> злоумышленник" не имеет возможности изменить маршрут
> прохождения трафика между клиентом и сервером S-MAIL и
> сделать тот самый MitM?
> Я бы не был столь категоричен ;) Со своей стороны, не стану
> утверждать, что каждый школьник, начитавшийся журнала
> "Ксакеп", сможет это сделать. Но задачка эта под силу не
> одним только спецсслужбам ;)
Нет, конечно я этого не заявлял и не заявляю. Это действительно реально, хотя и очень трудно.
Особенно учитывая мобильность s-mail.
Кроме того необходимо вскрывать ssl на связи с сервером (передача тела письма идёт ч/з
htpps). А он защищён уже классически, с применением сертификатов.
Согласитесь, это на порядки сложнее чем снять почту прямо с сервера
(Обычно, это под силу даже мне ).
Именно в этом плане S-Mail вне конкуренции с другими российскими Web-почтами.
Яркий пример того как изначальный учёт безопасности на порядок повышает стойкость сервиса.
> А что, кто-то силком заставлял через веб это делать? ;) Это
> что-то вроде: "Ребята, у вас не очень круто получилось",
> "Так мы, стоя на голове это делали!", "А, ну тогда
> Зачем выбирают веб-интерфейс? Правильно, для обеспечения
> мобильности (читай: удобства). А удобство и безопасность
> всегда в противофазе ;)
Я сам противник веб интерфейса (см. мои статьи), но это грустная реалия
современной почты. Он имеет и свои достоинства- простоту(доступность непрофессионалу),
мобильность, бесплатность.
Сегодня многие его считают и более безопасным (спасибо Outlook Express и другим
интегрированным с браузером почтам). По-моему пытаться переломить ситуацию уже бесполезно.
S-mail лучше чем ничего. Гораздо лучше.
> конечно". Я прошу не обижаться уважаемый S-MAIL, но выбор в
> пользу веб-интерфейса не есть причина, по которой нельзя
> было сделать какое-либо подобие PKI. А схема реализации
> настолько тривиальна, что даже нет желания ее расписывать.
Они делают. Только когда всё этом на общем канале - смысла мало.
А независимые каналы денег попросят.
Конечно стоит предоставить пользователям возможность выбора. Но результат я знаю заранее.
> > Отчасти и потому, что они не меньшие, чем проблемы в
> других
> > решениях (том же PGP).
> Щаз! Попробуйте в PGP нормально поработать без заверения
> ключа. Конечно, можно самому заверить, но это уже на свой
> страх и риск...
> Что в PGP, что в GNUPG сделана распределенная система
> сертифкации ключей. Кстати, при разумном подходе и
> отсутствии общей доверенной точки, можно произвести
> безопасный обмен ключами и без личной встречи. Надежность,
> конечно, уже не 100%, тем не менее...
Надёжность передачи ключей ч/з Интернет бесконечно меньше их заявленной криптостойкости.
Какую схему не реализовывай (кроме временной защиты, но она для профи).
> Среднестатистическому пользователю - вообще по барабану. Вы
> на меня в прошлый раз обиделись за замечание про НИИ
Нет, не обиделся. Просто оно в корне неправильно и вообще лучше не касаться личностей спорящих.
От этого только хуже.
>, а мне
> постоянно приходится общаться с будущими юзерами системы
> конфиденциальной связи. После длительных душевных
> разговоров, в процессе которых на пальцах объясняется что
> такое несимметричная криптография (никакой математики!
> только аналогия с сундуком, замком и ключом!), о пользе и
> необходимости самостоятельной генерации ключа, клиент
> произносит фразу почти как в анекдоте ("ты не
> выпендривайся, а рукой покажи!"), в смысле, дайте мне
> дискетку с "кодом", желательно без пароля. Занавес.
М-да. Это увы так.
>plug-in для Outlook ...который также загружен по non-trusted каналу (ИНтернет)
> ;))
; Как и PGP который в лучшем случае куплен на CD-шном рынке.
C open -source ситуация чуть лучше если вы в состоянии проверить его самостоятельно.
Но в целом - тупик.
> > связан с ними материально, просто высказываю своё
> мнение
> > считая, что любой человек вправе похвалить
> понравившийся
> > ему продукт…
> Угу. Но есть решения проще. Когда возникла надобность в
> конфиденциальной переписке (соавтор статьи в живет другом
> городе), был просто выкачан GNUPG, собран из исходников,
По какому каналу? :)))
> сгенерированы ключи. Обмен ключами, естессно, произошел по
> интернет, но вот fingerprint ключей был сверен по
> нескольким независимым каналам. Пользуемся до сих пор, тем
> более, что однажды появилась оказия пересечься лично, и
> теперь уверенность в достоверности полученных ключей -
> 100%. ;)
> А главное, что характерно ;), мы не приявязаны к
> конкретному сервису и каналу передачи.
Правильно Влад. Но Вы всё же профессионал, а большинство пользователей инета нет.
Для тех же Ваших клиентов PGP - жутко сложная штука (одно название чего стоит).
S-Mail же для них простое и привычное решение, которое действительно будет достаточным
во многих случаях.
Александр
|
| | | | | | |
Первый в Рунете публичный аудит почтовой системы 03.06.02 13:45
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > азбукой Морзе через клавишу NumLock :)
> :))) Речь идёт о том, чтобы осложнить жизнь снифферу.
Хм, но если речь идет о сниффере, то примерно равновесно что перехватывать: код ячейки из таблицы виртуальной клавиатуры или код введенного символа. Или Вы о кейлоггере?
> и интернет кафе не
> оборудованна клавиатурным снифером. А вот комплексные
Т.е. все-таки о кейлоггере ;) Но насчет гостиницы не знал. Хотя и не работаю со своими ресурсами с чужих машин, буду иметь ввиду...
> > Александр, при правильном подходе - спасает. Это
> азбучная
> > истина.
> Как именно? Если перехвачен канал на уровне провайдера, то
> все попытки
> бессмысленны. Другое дело, что правильное применение (
Вы сами правильно ниже пишете. И применение этих методов не осложняет техническую сторону, а решает проблему.
Собственно, в чем суть проблемы? Достоверно получить открытый ключ корреспондента. В схеме, используемой в s-mail это невозможно в принципе, т.к. каждый должен обменяться с каждым. А вот если бы был открытый ключ (точнее, самоподписанный сертификат) s-mail, то все бы решалось. Обеспечить его максимальную доступность (опубликовать на туче серверов, один раз напечатать его fingerprint в "АиФ" ;)) и т.п.) легко. Таким образом, любой вновь подключающийся в конце концов может убедиться в целостности и принадлежности загруженного им открытого ключа s-mail. Далее, он генерирует свою ключевую пару, формирует запрос на сертификат, шифрует его на открытом ключе s-mail и отправляет на s-mail. "Перехватчик" может мне сделать только DoS, но не MitM, ибо если даже он сделает свою ключевую пару пошлет запрос от моего имени, он не сможет прочитать мои посылки. Далее, s-mail подписывает мой открытый ключ из запроса (т.е. делает сертификат) и шифрует его на моем открытом ключе. Он не занимается удостоверением моей личности (нам не нужна юридическая значимость подписи), но он точно знает, что сертификат получит только тот, кто сформировал запрос. А там он уже может его распространять свободно.
Найдите здесь возможность вклиниться и адресно что-то прослушать?Естесвенно, мы исходим из того, что "противник" обладает конечной вычислительной мощностью и не может вычислять секретные ключи по открытым за приемлемое время ;)
Идею отдаю бесплатно, тем более, что она давно общеизвестна ;)
> столь популярноое ныне сканирование на ключевые слова), то
> s-mail - приемлемая защита.
Соглашусь с Вами в другом тезисе: лучше, чем ничего. Но, на мой взгляд, не сделаны самые простые вещи (не требующие, кстати, бешенных затрат), выводящие защищенность решения на гораздо более высокий уровень.
> Угу. Именно это я и хотел сказать ( ну может ещё телефонный
> разговор если у Вас хороший слух на голоса).
У меня - неплохой, жизнь научила ;))
> Нет, конечно я этого не заявлял и не заявляю. Это
> действительно реально, хотя и очень трудно.
> Особенно учитывая мобильность s-mail.
> Кроме того необходимо вскрывать ssl на связи с сервером
> (передача тела письма идёт ч/з
> htpps). А он защищён уже классически, с применением
> сертификатов.
Гм. Сертификат я видел только при загрузке аплета. Может, не доглядел? ;)
> Согласитесь, это на порядки сложнее чем снять почту прямо с
> сервера
> (Обычно, это под силу даже мне ).
Ладно прибедняться ;)
> Именно в этом плане S-Mail вне конкуренции с другими
> российскими Web-почтами.
А что, кто-то еще предлагает [b]защищенный[/b] сервис электронной почты? В противном случае, сравнение некорректно...
> Яркий пример того как изначальный учёт безопасности на
> порядок повышает стойкость сервиса.
Кто бы с этим спорил (про изначальный учет ;)). Но раз уж учли безопасность сразу, надо уж и сделать было до конца продуманно...
> > настолько тривиальна, что даже нет желания ее
> расписывать.
> Они делают. Только когда всё этом на общем канале - смысла
> мало.
См. выше.
> А независимые каналы денег попросят.
Зачем? У ребят хватило денег на сертификат Thawte для подписи аплета, кто мешает использовать его для подписи открытого ключа? Не говоря уже о бесплатных подходах с публикацией на N серверах, или подрисью его GnuPG и размещения ключа GnuPG на паблик-серверах ключей...
> Надежность,
> > конечно, уже не 100%, тем не менее...
> Надёжность передачи ключей ч/з Интернет бесконечно меньше
> их заявленной криптостойкости.
Бесконечно? ;) Значит, криптостойкость схемы s-mail стремится к нулю, т.к. криптостойкость ключей имеет конечное значение? ;))
Давайте будем акуратнее в определениях. Она меньше, но не "бесконечно меньше".
> Какую схему не реализовывай (кроме временной защиты, но она
> для профи).
Если к этой категории относить всех, кто смог прочитать (и понять) русский перевод доки к PGP - тогда, да.
> >plug-in для Outlook ...который также загружен по
> non-trusted каналу (ИНтернет)
> > ;))
> ; Как и PGP который в лучшем случае куплен на CD-шном
> рынке.
Это как раз худший случай ;)
> C open -source ситуация чуть лучше если вы в состоянии
> проверить его самостоятельно.
Вот потому я и веду речь об исходниках. Их проверить несколько легче, чем декомпилировать java-аплеты.
> > конфиденциальной переписке (соавтор статьи в живет
> другом
> > городе), был просто выкачан GNUPG, собран из
> исходников,
> По какому каналу? :)))
Правда интересно? Я отвечу ;)
По 3 каналам: из дома с диалапа (пользуюсь исключительно карточками), с работы и у знакомого в университете. Совпадение всех 3 версий уже само по себе достаточно, не говоря уже о том, что это исходники, которые и проверить можно. Последнее я не делал, ибо паранойя у меня еще не в последней стадии, но вот исходники bestcrypt в свое время внимательно почитать не поленился, ибо шифрование раздела все-таки ;)
> > А главное, что характерно ;), мы не приявязаны к
> > конкретному сервису и каналу передачи.
>
> Правильно Влад. Но Вы всё же профессионал, а большинство
> пользователей инета нет.
Для них есть специальный 1-дискетный дистрибутив линукса, который загружает trusted-серду для выполнения GPG :)
> Для тех же Ваших клиентов PGP - жутко сложная штука (одно
> название чего стоит).
Их лев - пусть они и спасают ;)
> S-Mail же для них простое и привычное решение, которое
> действительно будет достаточным
> во многих случаях.
Ага, особенно, если это случай Неуловимого Джо ;)
|
| | | | | | | |
Первый в Рунете публичный аудит почтовой системы 03.06.02 16:34
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 03.06.02 17:17 Количество правок: 1
|
> > > азбукой Морзе через клавишу NumLock :)
> > :))) Речь идёт о том, чтобы осложнить жизнь снифферу.
> Хм, но если речь идет о сниффере, то примерно равновесно
> что перехватывать: код ячейки из таблицы виртуальной
> клавиатуры или код введенного символа.
???
Под виртуальной клавиатурой пониматеся нарисованная на экране клавиатура со случайным
расположением клавиш, которые выбираются мышкой или "ложной" клавишей.
Это обычные, но очень эффективные действия по защите от большинства популярных снифферов.
Трассировка щелчков мышки действительно возможна, возможна и синхронная запись состояния видеопамяти
но большинство сниферов такое не обеспечивают.
Большинство применяемых- сохраняют только нажатия клавиш.
Идея не нова она обсуждалась лет пять назад и это решение было принято как оптимальное по балансу
эффективности и сложности.
> > Кроме того необходимо вскрывать ssl на связи с
> сервером > > (передача тела письма идёт ч/з
> > htpps). А он защищён уже классически, с применением
> > сертификатов.
> Гм. Сертификат я видел только при загрузке аплета. Может,
> не доглядел? ;)
Просто не разобрались:)). Браузер не всегда о них предупреждает, если авторизатор уже есть в базе
Очистите их список в браузере и всё увидите.
> вновь подключающийся в конце концов может убедиться в
> целостности и принадлежности загруженного им открытого
> ключа s-mail. Далее, он генерирует свою ключевую пару,
> формирует запрос на сертификат, шифрует его на открытом
> ключе s-mail и отправляет на s-mail.
...
> Идею отдаю бесплатно, тем более, что она давно общеизвестна
Именно так s-mail и поступает. Все сгенерированные ключи (вернее фрагменты их шифра перемылается по https:).
в виде форм ч/з
https://ksX.s-mail.com/...
В сущности то же самое, только используются встроенные средства защиты браузера.
Собственно, чем эта схема принципиально отличается от требуемой Вами?
> Вы сами правильно ниже пишете. И применение этих методов не
> осложняет техническую сторону, а решает проблему.
> Собственно, в чем суть проблемы? Достоверно получить
> открытый ключ корреспондента.Обеспечить его максимальную
> доступность разбросать по серверам
Угу. Вероятный противник делает то же самое (от Вашего имени), в таких же в больших объёмах.
Чему равна вероятность попасть на ложный ключ (>0,5)? Влад все эти схемы уже давно рассматривались в учебниках.
Там же отмечено, что для применения открытой криптографии должен быть надёжный канал, или публикация ключа должна
начаться ранее атаки на него.
Теперь крайний случай
Ваши письма он (владея каналом) перехватывает и заменяет ключ на свой.
Входящие письма он тоже перехватывает и заменяет ключ на свой.
Вообще на все последоватьльности вашего секретного ключа стоит оператор replace.
Мораль: если адресная проверка началась до публикации ключа в ассиметричном крипто ловить нечего.
Если позже- тогда все эти схемы излишни.
> Соглашусь с Вами в другом тезисе: лучше, чем ничего. Но, на
> мой взгляд, не сделаны самые простые вещи (не требующие,
> кстати, бешенных затрат), выводящие защищенность решения на
> гораздо более высокий уровень.
По-моему всё сделанно, только стандартыми средствами браузеров не наращивая объём апплетов.
> > Именно в этом плане S-Mail вне конкуренции с другими
> > российскими Web-почтами.
> А что, кто-то еще предлагает [b]защищенный[/b] сервис
> электронной почты? В противном случае, сравнение
> некорректно...
Ну, совсем недавно целая куча почт (pochtamt.ru, hotbox.ru, zmail.ru ...) радостно писала, что она предлагает защищённую почту,
при этом речь шла только о SSL до сервера. Посмотрите мою статью "Субъективная ... почт с Web-Интерфейсом".
Там приводился простой пример как читать почту rbc-шных сервисов (pochtamt.ru, fromru.com, rbcmail.com) прямо с сервера,
игнорируя все навороты на пути к нему.
> > А независимые каналы денег попросят.
> Зачем? У ребят хватило денег на сертификат Thawte для
> подписи аплета, кто мешает использовать его для подписи
> открытого ключа?
Что они и сделали в отношении сервера и спокойно пересылают его по https://.
Я говорил о сертификате на каждый ключ пользователя, что сделало бы его независимым от стойкости сервера.
> Если к этой категории относить всех, кто смог прочитать (и
> понять) русский перевод доки к PGP - тогда, да.
Много Ваших клиентов сделало (сделает) это?
> > >plug-in для Outlook ...который также загружен по
> > non-trusted каналу (ИНтернет)
> > > ;))
> > ; Как и PGP который в лучшем случае куплен на CD-шном
> > рынке.
> Это как раз худший случай ;)
Без разницы :(
> Для них есть специальный 1-дискетный дистрибутив линукса,
> который загружает trusted-серду для выполнения GPG :)
Угу. Очень удобная схема работы. Особенно для многократной пересылки документа в процессе его редактирования/согласования.
Полагаю, что для Вашего же случая совместной статьи s-mail была бы удобнее и вполне равноценна ценности поставленной задаче.
Александр.
|
|
Первый в Рунете публичный аудит почтовой системы 29.05.02 04:26
Автор: Komlin Статус: Незарегистрированный пользователь
|
В целом всё правда если вдруг будет время добавлю свой отчёт (полный).
Хотел бы отметить ещё один факт : система по сути открытая
т.к. клиентская часть (включая шифрование) вся написана на Java и JS.
Хотя исходных кодов апплета нигде не лежит это ничего не меняет т.к. нет защиты от интеллектуальной декомпиляции. При этом выдаётся близкий к исходному код.
Пример: процедура вычисления шифра к секретному ключу на основе пароля :
Декомпиляция JADом с последующей обработкой JntelliName
// _$p_loginStart1 - JntelliName
private byte[] _$p_loginStart1 (int i, String s, String s1) throws NoSuchAlgorithmException {
// Called from loginStart(String s, String s1) lines 14,15,17
// l4 (65536, s.toLowerCase(), s1);
// 15 (1, s.toLowerCase(), s1);
// 17 (i + 1, s.toLowerCase(), s1);
MessageDigest messagedigest = MessageDigest.getInstance(getParameter("name.messageDigest"));
String s2 = String.valueOf((new StringBuffer(String.valueOf(s))).append(s1).append(i));
messagedigest.update(s2.getBytes());
return messagedigest.digest();
}
Собственно большинство ошибок и замечаний было найдено простым просмотром открытых текстов.
---------------
"Замечаниями" я называю не ошибки, а просто решения у которых существуют более современные или стойкие аналоги. Собственно их тоже почти везде обещают устранить или уже устранили.
------------
" Недоработки в процедуре аутентификации, позволявшая отслеживать логи почты - адреса
абонентов, поля тем "
Это недоработка не клиентской части, а вообще сервера. Соответственно на стойкость самой криптозащиты она в принципе никак не влияла.
-----------
> A.V. Komlin - признанный эксперт в области защиты
> информации в Интернете. Автор целого ряда статей по
> вопросам уязвимостей в системах web-почты. Победитель
> <HackZone'99>.
Ну на эксперта я не тяну, это с лёгкой руки Ленты.Ру пошло. До специалистов класса [Duka ], Dl, Heater'a, Волчкова и т.д. мне _очень_далеко.
Александр
|
| |
Первый в Рунете публичный аудит почтовой системы 03.06.02 04:19
Автор: Serge3 Статус: Незарегистрированный пользователь
Отредактировано 03.06.02 11:15 Количество правок: 4
|
Здравствуйте,
> Пример: процедура вычисления шифра к секретному ключу на
> основе пароля :
> ... return messagedigest.digest();
> }
Я правильно понял, что ключ шифруется на результате однократного применения хэш-функции MD5 к паролю пользователя без случайной добавки?
Зашифрованный ключ сравнительно свободно доступен любому пользователю Internet?
Следовательно, к паролю надо предъявить достаточно жесткие требования на случайность, т.к.:
- возможен "мгновенный" подбор по словарю;
- скорость подбора на одном узле сети не менее, по порядку величины, 10^6 паролей в секунду, т.е. отмороженный хакер, может за год перебрать до 10^18 паролей или получить ключи для 1/10 всех пользователей всех систем с S-Mail-ом даже для Вашей сильно завышенной оценки множества паролей ~70^10. Вот в мощность множества паролей 10^6 поверю, ну 10^9 для параноиков.
В общем, это сильно не стойкая идея хранить ключи в сети.
Успехов.
--
"Serguei E. Leontiev"<lse@CryptoPro.ru>
http://www.cryptopro.ru
|
| | |
Первый в Рунете публичный аудит почтовой системы 03.06.02 11:21
Автор: Komlin Статус: Незарегистрированный пользователь
|
> Здравствуйте,
> Я правильно понял, что ключ шифруется на результате
> однократного применения хэш-функции MD5 к паролю
> пользователя без случайной добавки?
Хэш - SHA. Он надёжнее.
Применение неоднократное - я привёл фрагмент схемы как иллюстрацию простоты декомпиляции.
Следовательно, к паролю надо предъявить достаточно жесткие
> требования на случайность, т.к.:
> - скорость подбора на одном узле сети порядка 10^6
> паролей в секунду;
Здесь эта схема малоприменима, т.к. время ответа сервера довольно велико ( около 0,1 с).
> - возможен подбор по словарю.
С учётом вышесказанного - теоретически.
Но уязвимую точку Вы указали (как всегда :) )правильно.
Пароль - самое слабое место. Теоретически пароль должен иметь как минимум 32
символа длины в мультеалфавите (см. отчёт).
Практически, пользователи опять будут делать пароль одинаковый с логином и очень удивляться,
кто и как сумел вскрыть их почту :(((.
P. S. По-моему про MD5 ходили плохие слухи, что его научились быстро вскрывать, но
с другой стороны доказательств этого я так и не увидел.
Может Вы видели что-то подобное?
|
| | | |
Первый в Рунете публичный аудит почтовой системы 03.06.02 20:17
Автор: Serge3 Статус: Незарегистрированный пользователь
Отредактировано 03.06.02 21:25 Количество правок: 4
|
Здравствуйте,
> > Я правильно понял, что ключ шифруется на результате
> > однократного применения хэш-функции MD5 к паролю
> > пользователя без случайной добавки?
> Хэш - SHA. Он надёжнее.
SHA-1? Хм. Ну, наверное, всё же АНБ делало, но он сильно похож на MD5. Как я понял они, сейчас, начали переход на другие алгоритмы с длинной значения хэш-функции 256 бит и выше. Да я собственно, и не имел виду ломать саму хэш-функцию, я просто по верхам разглядываю и расспрашиваю, как используют базовые алгоритмы.
Ну да ладно, главное, что без случайной добавки.
> Применение неоднократное - я привёл фрагмент схемы как
> иллюстрацию простоты декомпиляции.
То же хорошо, но по ряду причин не спасает, особенно при не правильном применении.
> Следовательно, к паролю надо предъявить достаточно жесткие
> > требования на случайность, т.к.:
> > - возможен подбор по словарю.
> С учётом вышесказанного - теоретически.
А у меня создалось впечатление, что можно предварительно вычислить таблицу хэш-функций и расшифровать клиентский ключ с одного раза.
> > - скорость подбора на одном узле сети порядка 10^6
> > паролей в секунду;
> Здесь эта схема малоприменима, т.к. время ответа сервера
> довольно велико ( около 0,1 с).
В Вашем анализе это не аргумент по двум причинам:
1. Мне показалось, что ключ расшифровывается в Applete, т.е. у клиента. Это так или нет?
2. Вы в своём анализе ссылались на/установили отсутствие опасности доступа злоумышленника к содержимому WEB-сервера.
> Но уязвимую точку Вы указали (как всегда :) )правильно.
> Пароль - самое слабое место. Теоретически пароль должен
> иметь как минимум 32
> символа длины в мультеалфавите (см. отчёт).
И где Вы таких пользователей видели? Максимум, что я видел - это пользователей, использующие генераторы паролей типа SCO Unix (DoD), или типа ШИП (или ВиПНет). Эти генераторы имеют словари мощностью от 10^6 до 10^12.
А в человеческую фантазию я не верю.
> ...
> P. S. По-моему про MD5 ходили плохие слухи, что его
> научились быстро вскрывать, но
> с другой стороны доказательств этого я так и не увидел.
> Может Вы видели что-то подобное?
Про MD5 точно известно, что:
1. Есть коллизии в шаговой функции;
2. RSA отказался от итеративного использования своей родной хэш-функции MD5 в своей родной спецификации PKCS #12.
И был слух (не подтверждённый, но похожий на правду) в fido7.ru.crypt, что если итерировать MD5, то он начинает повторяться.
Успехов.
--
"Serguei E. Leontiev"<lse@CryptoPro.ru>
http://www.cryptopro.ru
|
| | | | |
Первый в Рунете публичный аудит почтовой системы 04.06.02 04:16
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 04.06.02 04:17 Количество правок: 1
|
Приветствую Сергей.
Спасибо за инфу по MD5.
> Ну да ладно, главное, что без случайной добавки.
Сергей, я не совсем понимаю, что подразумевается Вами под понятием "случайной добавки",
может невольно ввёл Вас в заблуждение неудачными формулировками, если так извините,
форум есть форум - пишешь наскоро. Если нетрудно уточните, что
Вы имели в виду. Не нижесказанное ли случайно?
На случай дальнейших разночтений опишу саму схему.
Схема защиты ключа (примерная на основе декомпиляции, как я её понимаю):
После генерации пара ключей (шифра и подписи) зашифровывается симметричным алгоритмом
по котенкации значений имя+пароль+"65536"
Это значение разбивается на пять(?) фрагментов из которых два(?) избыточные
(судя по алгоритму цифры c ? могут меняться). Фрагменты дополняются
случайными значениями
из на основе полученных из генератора случаных чисел SRandom
и фрагментами открытых ключей.
После некоторых запутанных манипуляций получившиеся фрагменыт отсылаются на сервер где
зашифровываются высланными туда же ключами вида имя+пароль+"i", где i E [0;5]
Сама пересылка с сервером идёт по https://, так что риск подмена пересылаемых значений (которого опасается
CyberVlad ) не превышает риска для любых схем с открытым ключём.
Это конечно очень примерная схема.
> 2. Вы в своём анализе ссылались на/установили отсутствие
> опасности доступа злоумышленника к содержимому WEB-сервера.
Нет, разумеется этот доступ опасен, и это безусловно была ошибка (уже устранённая)
имелось в виду, что хотя и удалось удалось добраться до зашифрованных текстов писем
лично мне это не дало возможности дешифровать их содержимое.
> И где Вы таких пользователей видели?
Увы почти нигде, как уже писал в прошлом сообщении
( уж в этом -то аспекте у меня большой опыт :)) )
большинство предпочитает самую надёжную схему (логин==пароль), но IMHO
это их проблемы: если уж пользователь идёт пользоваться защённым сервисом, то уж
позаботиться о хороше пароле он просто обязан.
> Максимум, что я видел
> - это пользователей, использующие генераторы паролей типа
> SCO Unix (DoD), или типа ШИП (или ВиПНет). Эти генераторы
> имеют словари мощностью от 10^6 до 10^12.
>
> А в человеческую фантазию я не верю.
Лично я для шифров использую буквенно-цифровую смесь набранную случайным набором
на клаве, частично зашитую на макрос, так что остаётся запомнить маленький фрагмент 5-8 с.
НАПРИМЕР:
nk}B084YblfSDb34b`-fKJRF-434UFNA4n;jf=4onf
Ничего сложного в этой процедуре нет. В командировках вожу код в блокноте и Palm'e.
По возвращению код меняется.
Делал я это задолго до того как стал заниматься инф. безопасностью
> "Serguei E. Leontiev"<lse@CryptoPro.ru>
> http://www.cryptopro.ru
|
| | | | | |
Результат проверки - должен быть результатом проверки 04.06.02 21:54
Автор: Serge3 Статус: Незарегистрированный пользователь
Отредактировано 04.06.02 23:10 Количество правок: 7
|
Здравствуйте,
> Сергей, я не совсем понимаю, что подразумевается Вами под
> понятием "случайной добавки",
> может невольно ввёл Вас в заблуждение неудачными
> формулировками, если так извините,
> форум есть форум - пишешь наскоро. Если нетрудно уточните,
> что Вы имели в виду.
Синхропосылка, её аналоги (salt, IV, SV ...), или иные меры не позволяющие по словарю паролей создать словарь(и) ключей. Использование имени пользователя в конкатенации с паролем - это добрая идея, но, на мой взгляд, не достаточная.
> Не нижесказанное ли случайно?
Нет не это, это уже схема распределённого хранения уже полученного ключа, который однозначно связан с паролем. А дальше, как это было у чехов с PGP, достаточно одного подписанного сообщения, и ключики у нас.
> На случай дальнейших разночтений опишу саму схему.
> Схема защиты ключа (примерная на основе декомпиляции, как я
> её понимаю):
> ...
> Это конечно очень примерная схема.
Т.е. анализ этой схемы не ставился как задача, ну и леший с ней. На форуме его всё равно провести не получится.
> ...
> имелось в виду, что хотя и удалось удалось добраться до
> зашифрованных текстов писем
> лично мне это не дало возможности
> дешифровать их содержимое.
Предлагаю Вам остановиться на этой формулировке. Чистая проверка по возможности НСД.
Вы же не ставите перед собой задачу проанализировать комплекс S-mail и доказать, что в некоторой модели угроз и нарушителя, соблюдения правил эксплуатации и регламента, комплекс S-mail обеспечивает безопасность информации по такому-то классу или с такой-то вероятностью. Это другая задача, значительно более тяжёлая и влекущая существенную переработку комплекса, но, как я понимаю, создателям S-mail будет достаточно приведённого выше утверждения: "Я Комлин А.В. имеющий ...регалии и авторитет... проверил S-mail в условиях ... потратил ... сил, обнаружил ..., но писем прочесть не смог". Такое утверждение дорогого стоит, я серьёзно.
Вообще странно, что на них такая "халява" свалилась :)
> ...
> (логин==пароль), но IMHO
> это их проблемы: если уж пользователь идёт пользоваться
> защённым сервисом, то уж
> позаботиться о хороше пароле он просто обязан.
> ...
Т.е. лифт не обслуживает необученных академиков. Каждый академик должен сам научиться подниматься и опускаться, с помощью лифта или без оного.
--
"Serguei E. Leontiev"<lse@CryptoPro.ru>
http://www.cryptopro.ru
|
| | | | | | |
Результат проверки - должен быть результатом проверки 24.08.02 05:22
Автор: kkm Статус: Незарегистрированный пользователь
|
> Т.е. лифт не обслуживает необученных академиков. Каждый
> академик должен сам научиться подниматься и опускаться, с
> помощью лифта или без оного.
>
Вот это определение мне больше всего из всей ветки и понравилось :)
Т.е. на сегодня в любой системе защиты как ни посмотри - самое слабое звено защиты - всегда сам человек !!!
забыл сказать ИМХО :)
Следовательно усиление защиты должно идти по пути исправления самого слабого звена, иначе просто нет смысла наращивать разрядность ключей и защиту серверов, опять имхо :)
С наилучшими пожеланиями, Администратор сайта www.kkm.info Михаил
НАШИ PGP КЛЮЧИ ВСЕГДА МОЖНО ВЗЯТЬ ЗДЕСЬ
http://www.kkm.info/pgpkeys.php
http://www.kkm.info/pgpkeys.php
|
|
|
подробно о проекте
Анализ криптографических сетевых...
