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

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

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

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

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

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