Вот как мы предлагаем искать признаки этого греха в программе:

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

2. Если защиты нет, это, очевидно, плохо.

3. Для каждой точки определите, используется ли при организации сеанса какой–нибудь протокол аутентификации. Плохо, если нет.

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

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

6. Убедитесь, что аутентификационные сообщения нельзя подделать. В частности, если для аутентификации применяется цифровая подпись на открытом ключе, проверьте, можно ли доверять открытому ключу другой стороны. Обычно для этого нужно либо свериться со статическим списком известных сертификатов, либо воспользоваться инфраструкторой открытых ключей (PKI), контролируя попутно все относящиеся к делу поля сертификата. Подробнее см. грех 10.

7. Если процедура аутентификации может быть атакована, проверьте, относится ли это только к первой успешной попытке входа в систему или также и ко всем последующим. Если начальная аутентификация может быть атакована, а последующие – нет, то аудитор должен признать, что оснований для беспокойства куда меньше, чем в случае, когда угрозе атаки с «человеком посередине» подвержены все соединения. Обычно при этом запоминаются верительные грамоты хоста и при последующем соединении с тем же хостом сравниваются с предъявленными.