19 смертных грехов, угрожающих безопасности программ
Шрифт:
□ Если да, то требуется ли после изменения пароля повторно аутентифицировать его?
□ Могут ли сотрудники отдела технической поддержки переустановить пароль?
□ Если да, должны ли они в любом случае следовать установленным процедурам аутентификации (например, требуется ли предъявить верительные грамоты пользователя, например, номер водительских прав)?
□ Поддерживает ли система процедуру автоматической переустановки пароля, которую может инициировать конечный пользователь (или противник)?
□ Если да, что должен знать или сообщить пользователь,
□ Каков механизм доставки переустановленного пароля (например, по электронной почте)?
□ Если система поставляется с предустановленными именами и паролями пользователей, то требует ли она изменить пароль при первом входе?
Протоколы проверки паролей
□ Используется ли стандартный или хорошо известный протокол? Это незыблемое требование, но существует ряд подобных протоколов, которые для многих целей недостаточны, поэтому остальные проверки тоже заслуживают внимания. В общем случае самыми надежными считаются протоколы с нулевым знанием, например 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 битов.
□ Включает ли алгоритм достаточно большое число итераций, чтобы противостоять вскрытию перебором? Например, вместо одного хэширования вы можете прогнать алгоритм хэширования тысячу раз, подавая на вход каждой итерации результат предыдущей.
□ Если база валидаторов украдена, сможет ли противник войти от имени пользователя, не вводя пароль? Иными словами, можно ли использовать валидатор, чтобы притвориться законным пользователем? Решать этот вопрос лучше всего профессиональному криптографу.
□ Все ли неудачные попытки входа обрабатываются одинаково (за одно и то же время и с одной и той же индикацией ошибок)?
□ Если все попытки аутентификации протоколируются, то включается ли в протокол введенный пароль?
Тестирование
Некоторые проблемы, касающиеся паролей, можно обнаружить с помощью автоматизированного динамического тестирования. Например, многие сканеры баз данных проверяют, оставлены ли стандартные учетные записи и выставленные по умолчанию пароли. Кроме того, противник может воспользоваться анализатором протоколов для прослушивания соединения и посмотреть, не посылается ли на начальной стадии пароль в открытом виде.
Многие другие проблемы можно выявить с помощью специализированных сценариев или тестирования вручную. Например, понять, какова политика управления паролями. Для тех аспектов политики, которые связаны со временем, придется проявить творческий подход. Например, если вы хотите знать, заставит ли приложение сменить пароль по истечении заданного времени, то, наверное, не стоит ждать несколько месяцев, проще перевести часы сервера вперед.
Что проверить трудно, так это качество самого протокола аутентификации. Хотя вы, конечно, можете узнать, посылаются ли пароли в открытом виде, но для понимания внутренней логики протокола лучше провести анализ кода.
Примеры из реальной жизни
Есть множество примеров парольных систем, в которых обнаружены серьезные дефекты. Проблемы встречаются настолько часто, что мы уже к ним привыкли и часто склонны не обращать внимания на опасность. Поэтому многие приложения, которые, строго говоря, нарушают правила безопасности (например, в финансовом мире, где к качеству паролей, частоте их смены и т. д. предъявляются жесткие требования), не считаются среди специалистов непригодными к использованию.