SATtva Персональная страница
темы архив все rss xml 2.0
 
 
блог
досье
связь
english
 

Замена открытого ключа

22.12.2006
pgp

Подходит к концу год, и одновременно заканчивается срок действия моего OpenPGP-ключа 0x4D8BB49E. В принципе, срок действия базового ключа подписи у него не ограничен, и для продления было достаточно создать новый шифровальный подключ, однако, он уже морально устарел, и не всегда за три с лишним года использовался в полном смысле безопасным образом. Сегодня была изготовлена замена.

Ключ 0x8443620A уже доступен на этом сайте и в базах основных депозитариев интернета; за две-три недели он должен обойти всю сеть pgp.net. Новый ключ имеет перекрёстные подписи с прежним, что должно упростить вам (если вы мой постоянный корреспондент) установление его подлинности.

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

Такая схема сломает совместимость с некоторыми ранними версиями ПО, впрочем, большинство пользователей уже переключились на PGP 9 и GnuPG 1.4.x, что должно сгладить этот недостаток. Если же трудности возникнут у слишком многих, я добавлю ещё один временный подключ к прежнему открытому ключу и продлю его жизнь до будущего лета. Затем ключ 0x4D8BB49E будет аннулирован и, вероятно, удалён.

Защита HTTP-авторизации без SSL?

05.11.2006
security

Вчера ночью сайт "openPGP в России" был благополучно перенесён на хостинг-площадку .masterhost. Одной из главных причин (помимо наплевательского сервиса прежней хостинг-компании) была потребность в корректной поддержке SSL для защиты пользовательских данных. Между тем, подключение SSL приведёт к удорожанию хостинга вдвое, поэтому, поразмыслив немного, я пришёл к идее простого протокола, защищающего пароль пользователя openSpace от компрометации.

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

Итак, возвращаемся к поставленной задаче. Поскольку при авторизации на сайте пароль открыто передаётся через Сеть, наблюдателю на канале связи ничего не стоит перехватить его, чтобы в дальнейшем входить на сайт под именем легитимного пользователя. Таким образом, цели, преследуемые в данной работе:

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

Перед потенциальным злоумышленником также стоят две альтернативные цели:

- задача-минимум: захватить сессию легитимного пользователя;
- задача-максимум: раскрыть пароль пользователя.

Наиболее элегантное и простое решение здесь -- SSL, обеспечивающий шифрование всего трафика между пользователем и сайтом на транспортном уровне, а также аутентификацию сайта. Как уже отмечалось, это сравнительно дорого...

Альтернатива

На этапе аутентификации пользователя для входа на сайт можно применить простой протокол "запрос-ответ", не раскрывающий пароль на канале связи. Для этого потребуется реализовать миниатюрное приложение на javascript, обеспечивающее необходимые преобразования на стороне пользователя. Как часто бывает в таких описаниях, роль пользователя выполнит Анна, а сервера -- Борис; числовые индексы переменных обозначают номер этапа, значение которого принимает переменная. Протокол может выглядеть так:

1) Анна инициирует начало протокола (для этого ей нужно открыть страницу с формой для ввода имени и пароля). Вместе с этим, Борис определяет IP-адрес Анны (который ещё пригодится), а также присваивает ей (передаёт) идентификатор неавторизованной гостевой сессии -- sid.

2) Далее Борис генерирует и отправляет Анне
r = H(k,t1,ip1),
где H -- операция хэширования, k -- секретный показатель, известный только Борису, t1 -- метка времени начала исполнения протокола, ip1 -- IP-адрес Анны, определённый на этапе 1. Кроме того, Борис сохраняет ip1 и t1 в переменных сессии Анны.

3) Анна вычисляет
h = H(r,u,p),
где u и p -- её логин и пароль, соответственно.

4) Анна возвращает Борису
h,u,sid1

5) Время поступления ответа на этапе 4 сравнивается с меткой времени, сохранённой на этапе 2. Если ответ получен в допустимом интервале, исполнение протокола продолжается.

6) Борис по u извлекает из базы данных пароль Анны p.

7) Борис самостоятельно вычисляет
h' = H( H(k,t1,ip4), u4, p6)

8) Борис сравнивает h, полученный от Анны на этапе 4, с h', вычисленный им самим на этапе 7.

9) При их соответствии Борис генерирует новый идентификатор авторизованной сессии sid', помещает ip4 в переменные сессии и сообщает sid' Анне.

Векторы атак

Попробуем атаковать протокол с различных направлений. В роли пользователя снова выступит Анна, сервером будет Борис, Николай -- пассивным наблюдателем, Виктор -- активным взломщиком.

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

Этап 2, опять же, не сообщает Николаю ничего полезного. Хотя он знает IP Анны и может угадать метку времени, он не имеет представления о секретном ключе Бориса, используемом для имитозащиты передаваемых данных.

Когда на этапе 4 Анна возвращает свои подсчёты серверу, Николай видит лишь очередной хэш, не несущий информации о пароле. Хотя ему известны и значение r (перехваченное на этапе 2), и логин Анны, он никогда не видел её пароль, так что его восстановление из h равносильно (в идеале) полному перебору результата функции хэширования. Получается, что у Николая не слишком много шансов определить пароль Анны, и наша основная задача -- скрыть пароль на канале связи -- выполнена. Но может быть взлом удастся более смелому Виктору, обладающему также более серьёзными ресурсами для нападения?

У него есть несколько вариантов. Например, он мог бы попытаться подделать значение h, передаваемое на этапе 4, но, не зная пароль Анны, это бесперспективно -- Борис выявит расхождения в пересчитанном h' на восьмом этапе. Виктор мог бы вклиниться в протокол на этапе 9 и перехватить идентификатор авторизованной сессии. Однако если Анна включила в настройках openSpace привязку сессии к IP, такая смена адреса (поскольку легитимный адрес Анны Борис сохранил в переменных сессии) тут же приведёт к инвалидации сессии. Казалось бы, вариантов нет. Но вместо всего этого шаманства Виктор пойдёт самым простым путём, известным как "атака гроссмейстера".

Расположив свой компьютер на канале связи между Борисом и Анной, он атакует протокол с самого первого этапа. Когда Анна запрашивает с сайта страницу логина (инициирует протокол), Виктор перехватывает запрос и пересылает его от своего имени (т.е. со своего IP). В результате Борис назначает Виктору гостевой идентификатор sid Анны. Виктор, притворившись Борисом, пересылает идентичные данные от себя к Анне (запрошенную страницу и sid). Анна вычисляет ответ на запрос Бориса и возвращает его наряду с остальными данными. Виктор вновь пассивно ретранслирует эту информацию Борису. Тот проверяет правильность ответа, используя IP, хранящийся в сессии и убеждается в том, что ответ получен он Анны, ведь пароль должна была знать только она. Следовательно, Борис создаёт авторизованную сессию и возвращает её номер источнику запроса -- Виктору! Здесь нет возможности определить, что источник не тот, за кого себя выдаёт; и даже после авторизации сессия не будет прервана, поскольку IP источника (Виктора) идентичен на всех этапах протокола. Чтобы успешно завершить нападение Виктор лишь должен вернуть Анне от имени Бориса какую-нибудь стандартную ошибку HTTP и прервать связь, чтобы она списала всё это на проблемы с сервером.

Контрзащита

К сожалению, я не вижу иного пути улучшить этот протокол, кроме следующего:

1) Анна инициирует исполнение протокола. Борис узнаёт её IP и присваивает ей гостевой sid.

2) Борис посылает
r = H(k,t1)

3) Анна вычисляет и возвращает Борису
h = H(r,u,p,ip), u, sid1,
где ip -- известный ей самой IP-адрес её машины.

4) Борис по u извлекает из базы данных пароль Анны p.

5) Борис вычисляет
h' = H( H(k,t1), u3, p4, ip3),
используя для ip3 источник ответа, полученного на этапе 3.

6) Борис сравнивает h и h', при соответствии которых помещает ip3 в переменные новой авторизованной сессии, а её идентификатор возвращает Анне.

Что будет, если и теперь Виктор попытается транслировать сообщения между участниками протокола, а в конце захватить авторизованную сессию? На этапе 3 он перехватывает значение h. Не зная пароля Анны он не может изменить его, поэтому передаёт Борису в исходном виде. Разумеется, Борис получает IP Виктора в качестве источника ответа и использует этот IP на этапе 5, повторно вычисляя хэш. В итоге, на этапе 6 Борис обнаруживает расхождения и прерывает протокол.

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

В общем, это просто тренировка для ума, и весьма маловероятно, что подобное будет реализовано на практике. Но всё же, какие ещё есть недостатки или потенциал для улучшения?

Лучше один раз увидеть

20.10.2006
крипто

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

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

Сайт исправлен

10.10.2006

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

Убита Анна Политковская

08.10.2006
мнение

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

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

Если правда есть равнодействующая всех мнений, то без Анны Политковской мы станем менее правдивы. Она была талантливой, убеждённой и искренней. Это достойно уважения, а её потеря -- скорби.

openSpace CMS

29.09.2006
софт

openSpace CMS -- так теперь называется программная платформа сайта openPGP в России. Изначально это была wiki-система WackoWiki, но с момента принятия решения сделать работу проекта более открытой не подразумевалась чистая wiki. Движок требовалось серьезно доработать.

В итоге за два месяца адаптации WackoWiki и копания в ее потрохах система превратилась в некий гибрид классической wiki (с ее анархическим подходом) и более авторитарной CMS, что, на мой взгляд, стало вполне оригинальным решением. Признаться, работа увлекла. А когда началась разработка конвертора для переноса базы данных форума phpBB в среду wiki, стало ясно, что пути назад нет, и полумерами здесь не ограничиться.

Движок openSpace будет доведен до ума, а затем выложен в свободный доступ под лицензией BSD. (Причины тому не идейные: я сторонник GPL, но оригинальная WackoWiki опубликована под BSD, а мне хочется дать ее авторам возможность бэк-портинга без смены своей лицензии, что потребовалось бы в случае GPL.) О последующем будущем этого движка я не уверен. Я буду рад, если он послужит где-то помимо openPGP в России или если кто-то найдет в его коде интересные для себя идеи, но самостоятельно вряд ли буду заниматься поддержкой и развитием этого проекта, кроме того, чтобы портировать изменения из самого openPGP в России.

Думаю, если что-то толковое в этом ПО и есть, оно появится в WackoWiki. Впрочем, если кто-то захочет взять готовый код под крыло и независимо продолжить его эволюцию, что ж, это повод для разговора.

Воздух premium-класса. Недорого

03.06.2006
право

VeriSign грозит суд в связи с их практикой удостоверяющего центра. Невероятно? Подробности интересней.

VeriSign, мировой гигант в сфере поставщиков решений безопасности для электронной коммерции, удостоверяющий центр по выдаче сертификатов X.509 и регистратор международных доменных имён с суммарным годовым доходом в полтора миллиарда долларов, обвиняется в недобросовестной рекламе.

Помимо прочего, VeriSign предоставляет электронным торговцам SSL-сертификаты X.509, идентифицирующие их веб-сайты и позволяющие шифровать ценные данные покупателей (номера кредитных карт и т.п.). С января 2001 года вдобавок к обычному пакету услуг сертификации Secure Site за $349 компания начала продавать так называемый premium-пакет Secure Site Pro стоимостью $895. По заявлениям VeriSign этот premium-пакет поддерживает более надёжное шифрование, что позволяет клиентам совершать покупки в интернет-магазинах и работать со счетами в интернет-банках в более защищённом режиме. Однако, как установил технический эксперт из компании Southeast Texas Medical Associates LLP, выступающей ведущим истцом по делу, в сущности между SSL-сертификатами, предоставляемыми в этих пакетах, нет никаких различий, за исключением разницы в цене на более чем $500. "По сути это мошенничество", -- так охарактеризовал действия корпорации адвокат Билл Кершоу, поддерживающий коллективный иск.

Как было отмечено в комментариях блога Иана Григга, всё, что вы получаете за эти пять сотен баксов (в случае Geotrust -- другого поставщика SSL-сертификатов, недавно поглащённого VeriSign), -- это картинка печати, которую можете повесить на свой сайт, со ссылкой на базу данных ChoicePoint с информацией о владельце сертификата. Что, правда, можете сделать и не отдавая 500 у.е.

Продавцы воздуха вечны?

Английское МВД заставит выдать шифровальные ключи

20.05.2006
право

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

Закон о правовом регулировании следственных полномочий (Regulation of Investigatory Powers Act, или сокращённо RIP* Act или просто RIPA) был принят в июле 2000 года. Этот законодательный акт можно сравнить с нашим законом "О следственно-оперативных и розыскных мероприятиях", однако более широкой сферы применения.

* Можно ещё расшифровать как "rest in peace" -- покойся с миром. :-)

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

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

Третья и самая короткая часть RIP, озаглавленная "Investigation of Electronic Data Protected by Encryption etc.", является самой неоднозначной. Далее я разберу некоторые её положения.

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

Последствия этого таковы, что любое облечённое законом лицо (полиция, таможня, спецслужбы), получившее в распоряжение перехваченные или изъятые зашифрованные данные, имеет право наложить на сторону, которая, как это лицо "полагает на разумных основаниях" (пункт 2 раздела 49), может располагать шифровальным ключом, "требование о раскрытии [информации]" (Imposition of a disclosure). Согласно этому требованию, обязанная им сторона должна представить либо ключ к защищённым данным, либо расшифровку этих данных, однако вид раскрытия определяет уполномоченное лицо (пункт 4 раздела 49, подпункт g).

Если уполномоченное лицо увидит "исключительные обстоятельства", для расследования которых недостаточно получения только расшифровки данных, то, согласно разделу 51, оно имеет право обязать подследственную сторону выдать шифровальный ключ для защищённых данных. А теперь держитесь за стулья: если подследственная сторона заявит, что не располагает рассматриваемой информацией либо нужным ключом расшифрования, она будет обязана выдать ВСЕ(!) шифровальные ключи, находившиеся в её распоряжении в момент получения требования (пункт 3 раздела 50).

(Всё вышесказанное относится как непосредственно к ключевому материалу, так и к парольным фразам, алгоритмам и всему остальному, "что позволяет получить или восстановить ключ либо обратить защищённую информацию в разумный вид" (пункт 9 раздела 50).)

Есть и ряд ограничений. Так, согласно пункту 9 раздела 49 требование о раскрытии не может быть представлено к ключам цифровой подписи, однако лишь в том случае, если ключ не использовался для шифрования данных. Кроме того, требование о раскрытии ключа, а не данных, должно соизмеряться с возможным "ущербом для бизнеса лица, обязанного требованием о раскрытии" (пункт 5 раздела 51, подпункт b), т.е., по идее, не должно налагаться на мастер-ключи банковских учреждений. Кроме того, требование о раскрытии исключительно шифровальных ключей может налагать только высшее руководство силового ведомства; выданный ключ должен применяться только для расшифрования изначально полученной и заявленной в требовании информации, а затем быть уничтожен (раздел 55).

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

Всё это довольно страшно... однако по сей день не действует. Английское право основано на т.н. первичном и вторичном законодательстве (primary and secondary legislation). Первичное -- это непосредственно законодательные акты, принятые Парламентом. Вторичное -- это распоряжения министров, вводящие те или иные положения законов в силу. Принятие RIPA вызвало столько шума, что вторичные распорядительные акты "активизировали" все части закона, кроме третьей. Считалось, что правительство не хочет ввязываться в перепалку с правозащитниками и придерживает эти жёсткие нормы "на чёрный день". Теперь с помощью ставших уже привычными жупелов "детская порнография" и "терроризм" МВД Великобритании пытается запустить третью часть RIPA в действие.

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

Как со всем этим бороться? Методов несколько. Технические -- это стеганография и "отрицаемое шифрование" (deniable encryption), используемое, в частности, в TrueCrypt (без привлечения дополнительных мер и улик в суде невозможно доказать, что контейнер TC -- это зашифрованные данные, а любые сомнения всегда толкуются в пользу обвиняемого); для защиты пересылаемых данных следует использовать PFS -- краткосрочные сеансовые ключи, согласуемые после аутентификации с помощью ключей цифровой подписи, а после передачи данных стираемые (такая схема применяется в Tor, в ремэйлерах и во множестве других систем и протоколов). Есть ещё проект m-o-o-t -- ОС, специально разработанная как противодействие третьей части RIPA, которую авторы обязуются опубликовать после ввода этих норм в силу.

Правовые методы защиты -- это ссылки на забывчивость: подсудимый может утверждать, что пароль, защищающий ключ, был настолько сложен, что стресс от предъявления требования о раскрытии информации привёл к забыванию. Но прокатит ли такая отмазка в суде -- вопрос открытый. Но вообще, на мой взгляд, лучше пойти на сотрудничество со следствием, и если дело касается зашифрованного PGP-сообщения, выдать сеансовый ключ, что позволяет сделать GnuPG: это ограничит ущерб и не приведёт к нежелательным уголовным последствиям.

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

1. От 25 до пожизненного в тюрьме либо экстрадиция в Штаты с перспективой высшей меры
либо
2. два года или штраф за невыдачу ключа.

;-)

Концепция: открытость

08.05.2006
pgp

Слухи о том, что я решил забросить проект "PGP в России" и прекратить обновления сайта, сильно преувеличены. Действительно, активность в работе над контентом в последние месяцы снизилась, однако причиной тому стала, во-первых, моя занятость с другими делами и, во-вторых, полная переработка дизайна сайта и концепции его построения.

Некоторые участники форума уже в курсе планируемых изменений, которые затронут даже название проекта. Главным отличием pgpru.com 2.0 станет его открытость для участия простых читателей и посетителей благодаря его построению на базе системы wiki. Это, однако, будет модерируемая, а не стихийная wiki, что позволит сохранить структуру сайта и удобство навигации.

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

No pasaran! Спам в форумах и блогах

09.04.2006
security

Безрадостная картина

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

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

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

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

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

Повесть о настоящем человеке

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

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

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

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

Опыт - сын ошибок трудных

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

freeCap -- это реализация концепции CAPTCHA (от Completely Automated Public Turing test to Tell Computers and Humans Apart, т.е. полностью автоматизированный публичный тест для разделения компьютеров и людей): скрипт генерирует сильно зашумлённую картинку с некоторым случайным текстом, который, тем не менее, человек способен различить, чтобы доказать свою человеческую сущность. Этот мощный бесплатный скрипт нашёл широкое применение как на сайте "PGP в России", так и в этом блоге, тоже пострадавшем однажды от спамеров. И внедрить его в создаваемую или установленную систему не составит труда ни одному веб-мастеру, имеющему хотя бы поверхностное представление о программировании на PHP.

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

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

<?php
// CAPTCHA session start
session_start();
if(!empty($_SESSION['freecap_word_hash']) &&
!empty($_POST['word']))
{
if($_SESSION['hash_func'](strtolower($_POST['word'])) ==
$_SESSION['freecap_word_hash'])
{
$_SESSION['freecap_attempts'] = 0;
$_SESSION['freecap_word_hash'] = false;
$word_ok = "yes";
} else {
$word_ok = "no";
}
} else {
$word_ok = false;
}
// CAPTCHA session end
?>


Второй фрагмент представляет собой html-код, который будет выводить автоматически генерируемое скриптом изображение теста Тьюринга и поле, куда пользователь (или особо умный робот) должен будет ввести текст, прочитанный им на картинке. Можно разместить этот код в той же форме, через которую производится публикация сообщений, чтобы за валидацию теста и ввод сообщения отвечал один и тот же скрипт. Впрочем, возможны и иные варианты.

<!-- CAPTCHA input start -->
Введите код подтверждения:<br />
<input type="text" name="word" maxlength="20" /><br />
<img src="/freecap/freecap.php" id="freecap" vspace="5" />
<!-- CAPTCHA input end -->


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

<?php
// CAPTCHA validation start
if ($word_ok != "yes")
{
print"Неверный код подтверждения!";
}
// CAPTCHA validation end
?>


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

Последнее звено безопасности

06.03.2006
security

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

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

Но, несмотря на слаженность всего процесса, заключительные решения всегда принимают люди: охранник решает, пустить ли через КПП сотрудника, забывшего пропуск; операционист решает, действительно ли перед ним владелец этого паспорта и счета; кассир решает, нет ли в полученном ордере ничего подозрительного. Сбой может произойти в любом месте, причем не только из-за активных действий злоумышленника, но и по невнимательности или халатности сотрудника банка -- звена системы безопасности.

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

Пройдя в кассу, я выполнил свою часть протокола и передал жетон кассиру (не выкладывая деньги в кювету, пока меня не попросят). Та просмотрела мой ордер, расписалась в нем и в книжке и... достала из сейфа несколько пачек купюр и начала поочередно скармливать их счетной машинке. Мне стало интересно, в какой момент девушка поймет ошибочность своих действий, и не прервал ее благородный порыв. И только когда она развернулась, чтобы переложить пересчитанные деньги в кювету, деликатно заметил, что не рассчитывал на такой подарок к 8 марта, а пришел положить деньги на счет, не обналичивать их. Пару секунд девушка в замешательстве смотрела на меня, потом загляну в ордер и, перекрестившись, поблагодарила, что спас ее от увольнения.

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

Чудовищная безответственность

15.01.2006
мнение

Уровень коррупции власти и бизнеса в "корпоративных" городах всегда был обыденностью, но последний случай просто потрясает.

Город Стрежевой на самом севере Томской области, являющийся плацдармом ЮКОСа в регионе, с конца 90-х выбивался даже из ряда подобных населённых пунктов. Население -- немногим более 35 тысяч. Основной сектор занятости -- обслуживание газовых и нефтяных месторождений, разбросанных по просторам Васюганских болот. СБ ЮКОСа и местные преступные группировки состоят из одних и тех же лиц. Городское начальство пьянствует с нефтяным.

В 250 км от Стрежевого находится вахтовый посёлок Пионерный: пара вроде Нового Уренгоя и Ямбурга в Ямало-Ненецком АО. Связь с ним поддерживается только двумя путями -- авиацией и автотранспортом по раздолбанной бетонной дороге, едва проходимой летом, и более доступной зимой, когда превращается в зимник.

Три дня назад, в самый пик сильнейших за последние годы 50-градусных морозов, из Стрежевого в Пионерный выехала очередная группа вахтовиков. Под предлогом экономии средств на авиационную перевозку, людей отправили в обыкновенном ЗИЛе. В дороге машина заглохла. Все 16 человек, находившихся в автобусе, замёрзли насмерть, не добравшись примерно 100 км до пункта назначения. Сообщений об этом не прозвучало ни в региональных, ни в федеральных СМИ.