Не рекомендуется

□ Не встраивайте конфиденциальные данные в HTTP–заголовки и в HTML–страницы, в том числе в URL, куки и поля форм, если канал не шифруется с помощью таких технологий, как SSL, TLS или IPSec, или данные не защищены криптографическими средствами.

□ Не доверяйте никаким данным в Web–форме, поскольку злоумышленник может легко подставить любые значения вне зависимости от того, используется SSL или нет.

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

Грех 10.

Неправильное применение SSL и TLS

Рекомендуется

□ Пользуйтесь последней версией SSL/TLS. В порядке предпочтительности: TLS 1.1, TLS 1.0hSSL3.

□ Если это имеет смысл, применяйте списки допустимых сертификатов.

□ Прежде чем посылать данные, убедитесь, что сертификат партнера можно проследить до доверенного УЦ и что его срок действия не истек.

□ Проверяйте, что в соответствующем поле сертификата партнера записано ожидаемое имя хоста.

Не рекомендуется

□ Не пользуйтесь протоколом SSL2. В нем имеются серьезные криптографические дефекты.

□ Не полагайтесь на то, что используемая вами библиотека для работы с SSL/TLS надлежащим образом выполнит все проверки, если только речь не идет о протоколе HTTPS.

□ Не ограничивайтесь проверкой одного лишь имени (например, в поле DN), записанного в сертификате. Кто угодно может создать сертификат и вписать туда произвольное имя.

Стоит подумать

□ О применении протокола OCSP для проверки сертификатов в цепочке доверия, чтобы убедиться, что ни один из них не был отозван.

□ О загрузке свежей версии CRL–списка после окончания срока действия текущего и об использовании этих списков для проверки сертификатов в цепочке доверия.

Грех 11.

Использование слабых систем на основе паролей

Рекомендуется

□ Гарантируйте невозможность считывания пароля с физической линии во время аутентификации (например, путем защиты канала по протоколу SSL/TLS).

□ Выдавайте одно и то же сообщение при любой неудачной попытке входа, какова бы ни была ее причина.

□ Протоколируйте неудачные попытки входа.

□ Используйте для хранения паролей одностороннюю функцию хэширования с затравкой криптографического качества.

□ Обеспечьте безопасный механизм смены пароля человеком, который знает пароль.

Не рекомендуется

□ Усложните процедуру переустановки пароля по телефону сотрудником службы поддержки.

□ Не поставляйте систему с учетными записями и паролями по умолчанию. Вместо этого реализуйте процедуру инициализации, которая позволит задать пароль для записи по умолчанию в ходе инсталляции или при первом запуске приложения.

□ Не храните пароли в открытом виде на сервере.

□ Не «зашивайте» пароли в текст программы.

□ Не протоколируйте неправильно введенные пароли.

□ Не допускайте коротких паролей.

Стоит подумать

□ Об использовании алгоритма типа PBKDF2, который увеличивает время вычисления односторонней свертки.

□ О многофакторной аутентификации.

□ Об использовании протоколов с нулевым знанием, которые снижают шансы противника на проведение успешной атаки с полным перебором.

□ О протоколах с одноразовым паролем для доступа из не заслуживающих доверия систем.

□ О программной проверке качества пароля.

□ О том, чтобы посоветовать пользователю, как выбрать хороший пароль.

□ О реализации автоматизированных способов переустановки пароля, в частности путем отправки временного пароля по почте в случае правильного ответа на «личный вопрос».

Грех 12.

Пренебрежение безопасным хранением и защитой данных

Рекомендуется

□ Думайте, какие элементы управления доступом ваше приложение применяет к объектам явно, а какие наследует по умолчанию.

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