19 смертных грехов, угрожающих безопасности программ

Виега Джон

Но это эффективно лишь в том случае, когда вы ограничиваете число одновременных попыток входа. Разумно ввести ограничение «не больше одного входа за раз». На самом деле без такого ограничения нельзя доказать корректность даже самых сильных протоколов.

Мы рекомендуем сделать борьбу с атаками частью стандартных рабочих процедур. Например, можно вести черный список IP–адресов на уровне сети. Кроме того, если зарегистрировано много попыток войти от имени некоторой учетной записи, то можно при следующем входе известить об этом ее владельца и предложить ему сменить пароль.

Если пользователь решит переустановить свой пароль, сделайте эту процедуру максимально усложненной или даже невозможной

для человека. Разрешать это следует лишь тогда, когда пользователь сможет убедительно подтвердить свою личность, предъявив один или несколько предметов, которыми только он может обладать, например паспорт или копию водительских прав.

Да, пароли часто забывают, поэтому автоматизированная переустановка должна быть простой. Хотя у электронной почты есть много недостатков с точки зрения безопасности, но дать возможность получать временный, случайно сгенерированный пароль по почте все же куда лучше, чем создавать ситуацию, в которой пользователь может пасть жертвой социальной инженерии. Конечно, риск есть, особенно в корпоративной локальной сети, где чужую почту можно просмотреть.

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

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

Рекомендации по выбору пароля

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

Лучше попытаться обеспечить минимально приемлемое качество паролей. Но тут надо соблюсти баланс между «неудобозапоминаемым» и негодным паролем. Чем выше вы поднимаете планку, тем больше шансов, что пользователь будет недоволен и запишет пароль на бумажку.

Разумно потребовать, чтобы минимальная длина пароля составляла от шести до восьми символов (а максимальная ограничена). Иногда требуется наличие небуквенных (и даже нецифровых) символов, и мы с этим согласны. Чтобы показать пользователю, насколько выбранный пароль уязвим для атаки перебором, можно провести такую атаку. Очень впечатляет! В корпоративной среде эта задача обычно ложится на ИТ–департамент. Но можно включить такую возможность в свою программу и активировать ее при первом вводе нового пароля. Есть даже библиотека CrackLib с открытыми исходными текстами, которая именно для такой проверки и предназначена. Загрузить ее можно со страницы www.crypticide.com/users/alecm.

Проверку на слабость пароля лучше всего проводить, когда пользователь выбирает пароль. Если вы обнаружите слабый пароль позже, то не будет уверенности, что он уже не скомпрометирован!

Проще предложить

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

Считается хорошей практикой заставлять пользователей менять пароли с некоторой периодичностью (например, раз в 60 дней). В некоторых отраслях промышленности это обязательно, в других к этому относятся скептически. Связано это с тем, что, устраняя одни риски, такая практика порождает другие. Когда человек сталкивается с неудобной системой, он может сделать нечто такое, что в других случаях делать поостерегся бы. Например, повторно использовать старый пароль или выбрать легко угадываемый пароль, поскольку запомнить новый ему трудно.

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

Прочие рекомендации

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

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

Дополнительные защитные меры

Одна из самых больших опасностей, связанных с паролями, – это легкость перехвата в случае, когда человек сидит перед общедоступным терминалом или даже за компьютером своего знакомого. Снизить этот риск позволяют системы с «одноразовым паролем». Идея в том, что пользователю предоставляется калькулятор паролей в виде небольшого приложения, работающего на КПК типа Palm Pilot или на смартфоне. При входе в систему пользователь с помощью этого калькулятора получает новый одноразовый пароль. К числу популярных систем такого рода относятся О PIE (one–time passwords for everything) и S/KEY.

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

Другие ресурсы

□ PKCS #5: Password–Based Cryptography Standard: www.rsasecurity.com/ rsalabs/node.asp?id=2127

□ «Password Minder Internals» by Keith Brown:msdnmag/issues/04/10/SecurityBriefs /

Резюме

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

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

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

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

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