Дэвид Лебланк - 19 смертных грехов, угрожающих безопасности программ
Если пользователь решит переустановить свой пароль, сделайте эту процедуру максимально усложненной или даже невозможной для человека. Разрешать это следует лишь тогда, когда пользователь сможет убедительно подтвердить свою личность, предъявив один или несколько предметов, которыми только он может обладать, например паспорт или копию водительских прав.
Да, пароли часто забывают, поэтому автоматизированная переустановка должна быть простой. Хотя у электронной почты есть много недостатков с точки зрения безопасности, но дать возможность получать временный, случайно сгенерированный пароль по почте все же куда лучше, чем создавать ситуацию, в которой пользователь может пасть жертвой социальной инженерии. Конечно, риск есть, особенно в корпоративной локальной сети, где чужую почту можно просмотреть.
Прежде чем посылать новый временный пароль по почте, нужно убедиться, что пользователь знает ответ на «личный вопрос». Это дает некоторую гарантию того, что переустановку действительно запрашивает законный владелец. Кроме того, если вы выберете этот подход, то мы рекомендуем не позволять пользователю выбирать собственный пароль, а посылать ему сгенерированный пароль по почте. В этом случае противнику еще придется взломать почтовый ящик. Напомним, что такая мера предотвратила бы атаку на мобильный телефон Пэрис Хилтон.
Чтобы еще усилить защиту процедуры переустановки пароля, обеспечиваемую «личными вопросами», мы предлагаем подумать о создании большой базы данных вопросов, на которые каждый человек дает разные ответы. Дайте пользователю возможность выбрать вопрос, который ему легче запомнить. Это затруднит противнику сбор информации.
Рекомендации по выбору пароля
Обычно человек не запоминает случайно выбранный пароль, поэтому хотя бы какое–то время пароль будет существовать на бумажке. Лично мы считаем, что ничего плохого в этом нет, если только сама бумажка хранится в бумажнике или в кошельке, а не под клавиатурой, но гарантировать это трудно. Поэтому мы не рекомендуем заставлять пользователей запоминать случайный пароль, но предложить это в качестве необязательной возможности разумно. Впрочем, есть люди настолько параноидального склада ума, что готовы подать в суд даже на собственный генератор случайных паролей.
Лучше попытаться обеспечить минимально приемлемое качество паролей. Но тут надо соблюсти баланс между «неудобозапоминаемым» и негодным паролем. Чем выше вы поднимаете планку, тем больше шансов, что пользователь будет недоволен и запишет пароль на бумажку.
Разумно потребовать, чтобы минимальная длина пароля составляла от шести до восьми символов (а максимальная ограничена). Иногда требуется наличие небуквенных (и даже нецифровых) символов, и мы с этим согласны. Чтобы показать пользователю, насколько выбранный пароль уязвим для атаки перебором, можно провести такую атаку. Очень впечатляет! В корпоративной среде эта задача обычно ложится на ИТ–департамент. Но можно включить такую возможность в свою программу и активировать ее при первом вводе нового пароля. Есть даже библиотека 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: http://msdn.microsoft.com/ msdnmag/issues/04/10/SecurityBriefs /
Резюме
Рекомендуется
□ Гарантируйте невозможность считывания пароля с физической линии во время аутентификации (например, путем защиты канала по протоколу SSL/TLS).
□ Выдавайте одно и то же сообщение при любой неудачной попытке входа, какова бы ни была ее причина.
□ Протоколируйте неудачные попытки входа.
□ Используйте для хранения паролей одностороннюю функцию хэширования с затравкой криптографического качества.
□ Обеспечьте безопасный механизм смены пароля человеком, который знает пароль.
Не рекомендуется
□ Усложните процедуру переустановки пароля по телефону сотрудником службы поддержки.
□ Не поставляйте систему с учетными записями и паролями по умолчанию. Вместо этого реализуйте процедуру инициализации, которая позволит задать пароль для записи по умолчанию в ходе инсталляции или при первом запуске приложения.
□ Не храните пароли в открытом виде на сервере.
□ Не «зашивайте» пароли в текст программы.
□ Не протоколируйте неправильно введенные пароли.
□ Не допускайте коротких паролей.
Стоит подумать
□ Об использовании алгоритма типа PBKDF2, который увеличивает время вычисления односторонней свертки.
□ О многофакторной аутентификации.
□ Об использовании протоколов с нулевым знанием, которые снижают шансы противника на проведение успешной атаки с полным перебором.
□ О протоколах с одноразовым паролем для доступа из не заслуживающих доверия систем.
□ О программной проверке качества пароля.
□ О том, чтобы посоветовать пользователю, как выбрать хороший пароль.
□ О реализации автоматизированных способов переустановки пароля, в частности путем отправки временного пароля по почте в случае правильного ответа на «личный вопрос».
Грех 12. Пренебрежение безопасным хранением и защитой данных
В чем состоит грех
Мы часто больше печемся о защите данных во время передачи, а не тогда, когда они уже оказались на диске. Но ведь информация куда больше времени проводит именно на диске, а не в сети. Есть ряд аспектов, которые нужно принимать во внимание при рассмотрении вопроса о безопасности хранения данных: права, необходимые для доступа к данным, шифрование данных и опасности, угрожающие хранящимся секретам.
Вариантом безопасного хранения данных является хранение секретов в тексте программы, хотя термин «хранение» здесь применим очень относительно! Из всех грехов этот раздражает нас больше прочих, поскольку это просто глупо. Многие программисты хранят такие секретные данные, как криптографические ключи и пароли, в самой программе, полагая, что пользователи их не узнают потому, мол, что реинжениринг выполнить очень трудно. И не надейтесь – злоумышленник может дизассемблировать любой код, чтобы завладеть секретными данными.
