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

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

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

Есть и еще один класс проблем, связанных с так называемым побочным каналом. В этом случае противник может получить информацию об именах и паролях пользователей, наблюдая, как система реагирует на попытки входа. Например, если хакер хочет войти в систему, но не знает ни одного имени пользователя, то он может попробовать несколько кандидатов. Если система говорит «неверное имя пользователя», но в случае ввода неправильного пароля выдает какое–то другое сообщение, то противник легко поймет, когда наткнется на существующее имя (после чего можно провести атаку с угадыванием пароля). В грехе 13 описан реальный пример такого рода ошибки в почтовом сервере IBM AS/400. Даже если в обоих случаях система выдает одно и то же сообщение, промежуток времени до его появления может меняться в зависимости от того, существует указанное имя или нет; в этом случае у хакера появляется еще один способ выявить существующие имена.

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

Проблемы паролей – это проблемы аутентификации, которые подробно рассмотрены в грехах 10,15 и 17. Многие проблемы можно сгладить за счет введения адекватных мер защиты сети (грех 8). В частности, если вы примените надежную схему аутентификации сервера и зашифруете канал (например, с помощью протоколов SSL или TLS, как описано в грехе 10), то шансы взломать пароли, когда они передаются по сети, резко падают.

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

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

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

Политика управления сложностью пароля

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

□ Генерирует ли система регистрации сильные пароли автоматически?

□ Разрешает ли система выбирать пароли сколь угодно большой длины?

□ Разрешает ли система выбирать короткие пароли?

□ Реализована ли в системе какая–нибудь схема проверки пароля на «легко–угадываемость» (например, что пароль не должен находиться в словаре и должен содержать хотя бы один символ, отличный от букв и цифр)?

□ Есть ли какие–нибудь ограничения на число неудачных попыток входа?

□ Есть ли ситуации, когда пользователь намеренно блокируется из–за неудачных попыток входа?

□ Требует ли система, чтобы пользователи регулярно меняли пароли?

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

Смена и переустановка пароля

□ Может ли зарегистрировавшийся пользователь изменить свой пароль по защищенному каналу?