Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
Есть и еще один класс проблем, связанных с так называемым побочным каналом. В этом случае противник может получить информацию об именах и паролях пользователей, наблюдая, как система реагирует на попытки входа. Например, если хакер хочет войти в систему, но не знает ни одного имени пользователя, то он может попробовать несколько кандидатов. Если система говорит «неверное имя пользователя», но в случае ввода неправильного пароля выдает какое–то другое сообщение, то противник легко поймет, когда наткнется на существующее имя (после чего можно провести атаку с угадыванием пароля). В грехе 13 описан реальный пример такого рода ошибки в почтовом сервере IBM AS/400. Даже если в обоих случаях система выдает одно и то же сообщение, промежуток времени до его появления может меняться в зависимости от того, существует указанное имя или нет; в этом случае у хакера появляется еще один способ выявить существующие имена.
Родственные грехи
Проблемы паролей – это проблемы аутентификации, которые подробно рассмотрены в грехах 10,15 и 17. Многие проблемы можно сгладить за счет введения адекватных мер защиты сети (грех 8). В частности, если вы примените надежную схему аутентификации сервера и зашифруете канал (например, с помощью протоколов SSL или TLS, как описано в грехе 10), то шансы взломать пароли, когда они передаются по сети, резко падают.
Где искать ошибку
Места проявления этого греха найти несложно. Используются ли в программе традиционные методы или «самописная» система проверки пароля без дополнительных механизмов аутентификации□ В последнем случае программа «живет во грехе». Обычно с таким грехом мирятся, но вы должны быть уверены, что пользователи знают о нем.
Даже при наличии многофакторной аутентификации риск остается, если на какой–то ступени используется парольная защита. Например, возможность блокировки учетной записи из–за неудачных попыток входа. Так что главная причина и место ошибки – это само существование парольной защиты!
Выявление ошибки на этапе анализа кода
Столкнувшись с парольной защитой, довольно просто идентифицировать риски. И большинство ее свойств легко проверить. По большей части аспекты, вызывающие возражения, считаются допустимым риском, хотя это и зависит от конкретных условий. Возникает соблазн списать все проблемы с паролями на небрежность пользователей, но мы призываем вас взглянуть на следующий контрольный список; быть может, в нем найдется что–то, легко поддающееся улучшению.
Политика управления сложностью пароля
Отметим, что все перечисленное ниже несущественно, если используется схема одноразовых паролей.
□ Генерирует ли система регистрации сильные пароли автоматически?
□ Разрешает ли система выбирать пароли сколь угодно большой длины?
□ Разрешает ли система выбирать короткие пароли?
□ Реализована ли в системе какая–нибудь схема проверки пароля на «легко–угадываемость» (например, что пароль не должен находиться в словаре и должен содержать хотя бы один символ, отличный от букв и цифр)?
□ Есть ли какие–нибудь ограничения на число неудачных попыток входа?
□ Есть ли ситуации, когда пользователь намеренно блокируется из–за неудачных попыток входа?
□ Требует ли система, чтобы пользователи регулярно меняли пароли?
□ При смене пароля есть ли какая–нибудь защита от выбора пароля, который раньше уже был связан с той же учетной записью?
Смена и переустановка пароля
□ Может ли зарегистрировавшийся пользователь изменить свой пароль по защищенному каналу?
□ Если да, то требуется ли после изменения пароля повторно аутентифицировать его?
□ Могут ли сотрудники отдела технической поддержки переустановить пароль?
□ Если да, должны ли они в любом случае следовать установленным процедурам аутентификации (например, требуется ли предъявить верительные грамоты пользователя, например, номер водительских прав)?
□ Поддерживает ли система процедуру автоматической переустановки пароля, которую может инициировать конечный пользователь (или противник)?
□ Если да, что должен знать или сообщить пользователь, чтобы переустановить пароль, и насколько вероятно, что противник, атакующий пользователя, обладает этой информацией?
□ Каков механизм доставки переустановленного пароля (например, по электронной почте)?
□ Если система поставляется с предустановленными именами и паролями пользователей, то требует ли она изменить пароль при первом входе?
Протоколы проверки паролей
□ Используется ли стандартный или хорошо известный протокол? Это незыблемое требование, но существует ряд подобных протоколов, которые для многих целей недостаточны, поэтому остальные проверки тоже заслуживают внимания. В общем случае самыми надежными считаются протоколы с нулевым знанием, например SRP (Secure Remote Passwords – безопасный удаленный ввод пароля) или PDM (Password Derived Moduli–величина, выводимая из пароля). Системы на базе Kerberos приемлемы, если используются в режиме шифрования и аутентификации. Качество всех остальных систем оставляет желать лучшего. В частности, такие традиционные схемы, как UNIX crypt(), HTTP Digest Auth, CRAM–MD5 (Challenge–Response Authentication Mechanism – механизм аутентификации «оклик–отзыв») и MD5–MCF (Modular Crypt Format – модульный формат шифрования), имеют слабые места, использовать их можно, только если соединение было предварительно аутентифицировано.
□ Предусматривает ли протокол отправку серверу самого пароля или некоторой функции от него (в частности, валидатора)? Если речь не идет о протоколе с нулевым знанием (особый класс протоколов, позволяющих человеку доказать, что он знает пароль, не сообщая его тому, кто его не знает), то этого не избежать.
□ Если так, посылается ли пароль по защищенному каналу, когда клиент предварительно аутентифицирует сервера (по зашифрованной и гарантирующей целостность сообщений линии)?
□ Предполагает ли протокол, что клиент посылает некий оклик и ждет от сервера правильного отзыва (обычно это аутентифицированная копия оклика)? Важно, чтобы оклик никогда не повторялся.
□ Предусматривает ли протокол также отправку оклика сервером?
□ Предусматривает ли протокол явное поименование сторон в ходе обмена сообщениями, с тем чтобы каждая сторона подтвердила имя другой стороны?
□ Доказывает ли протокол не только то, что клиент знает пароль, но и то, что на сервере хранится правильный валидатор?
□ Вырабатывается ли в ходе процедуры аутентификации некий ключ (или криптографическая функция), который потом используется для шифрования данных?
Ввод и хранение паролей
□ Во время ввода пароля пользователем есть ли какие–либо визуальные свидетельства о длине или тексте пароля? Примечание для ультра–параноиков: даже вывод звездочек выдает длину пароля.
□ Хранятся ли пароли в открытом виде? Это очень плохо!
□ Хранятся ли пароли в слабо защищенном постоянном хранилище?
□ Если нет, то хранятся ли валидаторы паролей в виде строки фиксированной длины, порождаемой криптографически сильной односторонней функцией от пароля (лучше всего каким–нибудь стандартным механизмом, например PKCS #5, который мы обсудим в разделе «Хранение и проверка паролей»)? Обратимые функции так же плохи, как и хранение в открытом виде.
□ Является ли частью процедуры вычисления односторонней свертки некоторое начальное значение (затравка), разное для разных паролей? Затравка защищает от атак с предварительным вычислением, но не от вскрытия пароля полным перебором. Минимальная длина затравки должна составлять порядка 32 битов.
□ Включает ли алгоритм достаточно большое число итераций, чтобы противостоять вскрытию перебором? Например, вместо одного хэширования вы можете прогнать алгоритм хэширования тысячу раз, подавая на вход каждой итерации результат предыдущей.
□ Если база валидаторов украдена, сможет ли противник войти от имени пользователя, не вводя пароль? Иными словами, можно ли использовать валидатор, чтобы притвориться законным пользователем? Решать этот вопрос лучше всего профессиональному криптографу.
□ Все ли неудачные попытки входа обрабатываются одинаково (за одно и то же время и с одной и той же индикацией ошибок)?
□ Если все попытки аутентификации протоколируются, то включается ли в протокол введенный пароль?
Тестирование
Некоторые проблемы, касающиеся паролей, можно обнаружить с помощью автоматизированного динамического тестирования. Например, многие сканеры баз данных проверяют, оставлены ли стандартные учетные записи и выставленные по умолчанию пароли. Кроме того, противник может воспользоваться анализатором протоколов для прослушивания соединения и посмотреть, не посылается ли на начальной стадии пароль в открытом виде.
Многие другие проблемы можно выявить с помощью специализированных сценариев или тестирования вручную. Например, понять, какова политика управления паролями. Для тех аспектов политики, которые связаны со временем, придется проявить творческий подход. Например, если вы хотите знать, заставит ли приложение сменить пароль по истечении заданного времени, то, наверное, не стоит ждать несколько месяцев, проще перевести часы сервера вперед.
