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

□ Сообщения, содержащие только коды ошибок. Коды конечно, вещь полезная, особенно когда они что–то говорят администратору. Но надо также включать текст, понятный пользователю.

Помните, что люди, мало разбирающиеся в компьютерах, склонны принимать неправильные решения в том, что касается безопасности.

Родственные грехи

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

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

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

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

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

□ Найдите в интерфейсе пользователя все параметры, относящиеся к безопасности. Что включено по умолчанию, а что выключено? Если программа по умолчанию небезопасна, возможны проблемы. Неприятности могут возникнуть и в тех случаях, когда ослабить безопасность слишком легко.

□ Изучите систему аутентификации. Если пользователь не может успешно аутентифицировать второго участника соединения, есть ли возможность все–таки установить соединение? Разумеется, при этом пользователь понятия не имеет, кто находится на другом конце. Хороший пример – это SSL–соединение, когда клиентская программа соединяется с сервером, но имя в сертификате свидетельствует о том, что это не тот сервер, а пользователь даже не обращает на это внимания. (Скоро мы объясним эту ситуацию подробнее.)

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

В основе науки о практичности лежит тестирование. К сожалению, фирмы–разработчики такому тестированию не уделяют много внимания. При тестировании практичности пользователи обычно работают парами (метод обсуждения вслух). Они самостоятельно исследуют систему, часто в первый раз. При оценке безопасности можно применить такой же подход; главное, чтобы пользователь попробовал те функции, которые вас интересуют.

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

Основы тестирования практичности применимы и к безопасности, поэтому имеет смысл познакомиться с этой дисциплиной. Мы рекомендуем книгу Jacob Nielsen «Usability Engineering» (Morgan Kaufman, 1994) («Инженерная оценка практичности»). Кроме того, в статье Alma Whitten и J.D. Tygar «Usability of Security: A Case Study» («Практичность безопасности на конкретном примере») излагаются некоторые соображения по поводу тестирования функций безопасности программ с точки зрения удобства пользования.

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

Но парочку своих любимых примеров мы все же приведем.

Аутентификация сертификата в протоколе SSL/TLS

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

Рис. 19.1 . Диалоговое окно, которое открывает Internet Explorer, если браузер заходит на сайт с «самоподписанным» сертификатом

Типичный пользователь, увидев такое, подумает: «Ну и что все это значит?» В общем–то ему наплевать, поэтому он просто зайдет на сайт, нажав кнопку Yes и даже на дав себе труда попытаться понять, в чем проблема. Редкий пользователь, обуреваемый любопытством, решит нажать кнопку View Certificate (Показать сертификат), а потом все равно не будет знать, на что смотреть.

В разделе «Искупление греха» мы покажем более правильные способы решения этой конкретной проблемы.

Установка корневого сертификата в Internet Explorer 4.0

Предположим, что вам нужно установить сертификат нового корневого удостоверяющего центра (УЦ), чтобы получить доступ к сайту, защищенному SSL/ TLS, сертификат которого выпущен «левым» УЦ (обычно с помощью OpenSSL или Microsoft Certificate Server). До выхода в свет Internet Explorer 5.0 вы бы увидели окно, показанное на рис. 19.2. (Не надо затевать разговор о рисках, связанных с установкой сертификата корневого УЦ с сайта, который вы не можете аутентифицировать. Это другая тема.)

Это окно никуда не годится, потому что оно бесполезно как для обычных пользователей, так и для администраторов. Для человека, не знакомого с криптографией (а это большая часть населения планеты), текст выглядит полной бессмыслицей. А для администратора наличие двух сверток не дает ничего, если только он не позвонит конкретному человеку или фирме и не попросит для подтверждения повторить обе свертки: SHA–1 и MD5. К счастью, в Internet Explorer 5.0 и более поздних версиях это окно заменено куда более осмысленным.