TECKLORD, по материалам SecurityFocus. Сценарий: создается сайт, требующий аутентификацию пользователей. Пользователи могут сами создавать имена и пароли и использовать их для доступа к сайту. Является ли ваша система аутентификации безопасной? Недостаточная безопасность пользователей является проблемой, которую должен решить разработчик сайта. Возможно это недостаток стандартов, а может аудита? Данная статья отвечает на оба эти вопроса, основываясь на стандартной процедуре аудита, которая оценивает вашу безопасность. Проверьте систему аутентификации на вашем сайте, отвечая на нижеследующие вопросы. Имена пользователей и пароли Требует ли система ввода имени пользователя и пароля? Некоторые сайты требуют лишь ввода пароля. Проблема возникает, когда пользователь указывает пароль, который уже кем-то используется. Вам придется уведомить его, что такой пароль уже используется, тем самым дать доступ к ресурсам другого пользователя. Требует ли ваша система устойчивости паролей? Если ваша система безопасности зависит от паролей, то надежную безопасность можно обеспечить лишь использованием устойчивых паролей. Так, что требуйте минимальную длину пароля, и не позволяйте, чтобы пароль был схож с логином. Использование цифр и знаков пунктуации сделают пароль более устойчивым, равно, как и использование длинных паролей(Ten Windows Password Myths). Возможно сделать пароль устойчивее, позволив юзерам использовать пробелы и поощряя фразовые пароли. Более того, необходимо разрешить использование всех символов на клавиатуре, не ограничиваясь лишь цифрами и буквами, и определить максимальную длину пароля в 128 символов. ScreenName в AOL, содержащее AIM, Netscape Network и Compuserve, требуют минимальную длину пароля в 3 символа, и максимальную - в 16, что не является безопасным. Позволяет ли система «старение» паролей и их историю? Hotmail возник 4 июля 1996 года, почти 7 лет назад. А это почти 2500 дней. Интересно, сколько миллионов первых пользователей хотмейла до сих пор используют те же пароли, что и сем лет назад? Если вы не желаете применять политику старения пароля, то напоминайте хотя бы своим пользователям, о давности использования ими одного и того же пароля. Ведение истории паролей предотвращает использование старых паролей. Это осуществляется путем сохранения некоторых последних паролей, используемых пользователем. Пользователи могут, конечно, менять пароли несколько раз подряд, чтобы изменить историю паролей. Во избежание этого, можно хранить все пароли, или установить временной лимит на их изменения. Использует ли система простые и легко угадываемый имена и пароли? Следует избегать использование обычных, легко угадываемых или последовательных имен. Это позволит уменьшить количество атак на отдельный эккаунт. Не следует выдавать пользователям временные или легко угадываемые пароли, а позволять им самим создавать пароль. Возможно ли получить имена пользователей с сайта? Некоторые сайты позволяют легко угадать или собрать список имен пользователей. Если атакующий способен это сделать, существует возможность брут-форса. Так же существует возможность сбора e-mail’ов с последующей рассылкой спама. Выдают ли сообщения об ошибках много информации? Не следует давать подсказки о длине пароля, используемых символах, при неудавшейся попытке пользователя пройти аутентификацию. Обнаруживает ли ваш модуль брут-форс, и предотвращает ли его? Для предотвращения брут-форс атаки следует принять меры по ее обнаружению. Заблокируйте эккаунты с большим количеством неудач при аутентификации, но будьте бдительны и опасайтесь повального количества таких неудач. Содержит ли исходный код приложения требуемые для аутентификации имя пользователя или пароль? Если да, то удалите их. Использует ли система длинные ссылки для аутентификации пользователей? Такой способ аутентификации можно сравнить с ключом, который прячут под ковриком у входной двери. Вы находитесь в безопасности до тех пор, пока кто-либо не узнает, что вы прячете ключ под ковриком. Могут ли пользователи изменять свои имена? Иногда, пользователям необходимо изменить свой логин по той или иной причине не создавая новый эккаунт. Некоторые системы не позволяют этого, так как имя пользователя является ключевым полем в базе данных. Но eBay, например, позволяет изменение имени пользователя без потери его личных данных. С другой стороны, необходимо осторожно относится к тому, что пользователи могут менять свои имена. Пользователь может сменить свое имя во избежание плохой репутации, а это конечно же не поощряется. Требуете ли вы ввода e-mail в качестве логина? Microsoft's Passport требует от пользователя ввода подлинного e-mail`а в качестве логина. e-mail адреса в качестве логина могут позволить спамерам получить большую базу для рассылок, и усложнить процесс смены имени пользователя. Этот способ так же вынуждает пользователей менять логин каждый раз, когда они меняют почтовый ящик. Вы можете позволить пользователям использовать в качестве логина их e-mail, но не следует принуждать их делать это. Получают ли пользователи автоматически он-лайн эккаутны, даже если они их не используют? Многие банки автоматически заводят он-лайн эккаунты для своих клиентов, даже если держателю счета этого не нужно. Возможно у этих клиентов нет Интернета, или они не хотят изучать механизм работы, или не доверяют банковской системе безопасности. Обеспечение доступа к ресурсам, которые не используются клиентом, может быть опасным, так как некоторые пользователи даже не подозревают о существовании своего эккаунта. Управление паролями Могут ли пользователи легко менять свои пароли? Если вы не сделаете процедуру изменения пароля очень простой, то пользователи будут реже менять пароли. Изменение паролей должно быть обязательной и удобной процедурой для всех систем аутентификации. Например, помещая ссылку для смены пароля вверху страницы, когда его срок действия истекает. Должны ли пользователи проходить повторно аутентификацию перед и после смены пароля? Когда вы позволяете пользователям менять пароль, сделайте возможным ввод старого пароля, например, требуя заполнить три поля: старый пароль, новый и подтверждение нового пароля. Это мера безопасности не позволит взломщику сменить пароль на похищенных эккаунтах. Скажем, кто-то прошел аутентификацию на веб-сайте, а затем решил посетить другие сайты. Предположим, что пользователь вышел, оставив свое рабочее место с открытым окном браузера. Кто угодно может в этот момент воспользоваться отсутствием пользователя, сменить его пароль и получить полный контроль над его эккаунтом. Также бывают ситуации, что при краже кукиса или других средств аутентификации, существует возможность получения доступа к эккаунту жертвы. Если вы всегда будете требовать ввод старого пароля, то этим уменьшите количество атак такого рода, поскольку атакующему нужно будет знать настоящий пароль пользователя. После того, как пользователь создаст пароль, вы должны прервать его сессию для нового входа. И, наконец, когда пользователь изменит пароль, пошлите ему письмо с подтверждением, и, возможно, включите также ip адрес, изменившего пароль. Позволяет ли система восстанавливать пароли? Как альтернативу для восстановления пароля, следует его переустановить. Восстанавливаемые пароли должны хранится в базе в виде простого зашифрованного (с использованием обратимого алгоритма шифрования) текста. Предположим, хакер получает полный доступ к компьютеру жертвы. Увидев, что у пользователя есть банковский счет, хакер заходит на сайт банка, нажимает на ссылку «забыл пароль», и ждет письмо с новым паролем. После получения письма, он его удаляет и успешно проходит аутентификацию на сайте. Лучший способ – обнулить пароль и послать пользователю письмо вместе с безопасной ссылкой на ваш сайт. В письме следует четко указать, что пароль был обнулен, и с какого ip адреса это было сделано. Когда пользователь нажмет на ссылку, он попадет обратно на ваш сайт, где сможет выбрать новый пароль для своего эккаунта. Проверяет ли система достоверность пользователя при изменении пароля? Второй метод предотвращения вышеописанного сценария заключается в требовании ввода какой-то персональной информации перед тем, как обнулять пароль и оповещать об этом пользователя. Вы должны убедится, что именно пользователь получит это письмо. Посылает ли система важную информацию по e-mail? Следующий шаг: доставка нового пароля пользователю. Схема восстановления пароля на E*Trade с первого взгляда впечатляет. Пользователь не может восстановить пароль, он может лишь переустановить его. Страница восстановления паролей шифруется SSL, так что никто не может с помощью снифера узнать вашу информацию. Пользователю требуется указать персональную информацию, чтобы переустановить пароль. Проблема этой системы безопасности в том, что как только пользователь обнулит пароль, он получает простое письмо с временным паролем. Электронная почта не является безопасным средством передачи информации, и пароль может быть перехвачен. AOL позволяет восстановление пароля без персональной аутентификации: все что для этого нужно – это ник, чтобы переслать пользователю пароль по e-mail. Если существует возможность воспользоваться снифером, то для получения пароля следует лишь ввести имя пользователя на странице восстановления паролей. Еще один очень распространенный метод – пересылка по почте имени пользователя и пароля с рекомендацией сохранить письмо на будущее. Уязвимыми являются не только пароль и имя пользователя, посланные по e-mail, но и сохраненное пользователем письмо. Выдает ли система временные пароли? Если ваша система выдает временные пароли, следует требовать либо смены пароля при первом входе, либо лимитировать время использования этого пароля. Использует ли система напоминание пароля? С первого взгляда эта услуга также кажется полезной, но напоминание паролей и секретные вопросы могут ослабить безопасность системы. Например система, требующая 8 символьный пароль (минимальное количество комбинаций - 218 340 105 584 896), и требующая секретного ответа только на 2 пункта: девичья фамилия матери и кличка питомца. Самое интересное, что разных фамилий не так уж много, есть много Ивановых, Петровых, Сидоровых, Кузнецовых… А популярные имена животных(например собак) сводятся к Тузику, Шарику и Бобику. Если вы все же решили использовать секретные вопросы, вы должны обеспечить хотя бы 20 вариантов или больше. Также можно разрешить пользователям задавать свой вопрос и отвечать на него. К сожалению не все пользователи отнесутся к этому ответственно, и вопросы могут быть похожими на следующие: Как меня зовут? Какой у меня e-mail? Какой у меня пароль? Секретные вопросы тогда полезны, когда они не схожи с паролем. Секретные вопросы должны использоваться для идентификации пользователя и обнуления пароля, а не для доступа к эккаунту. Заключение Так заканчивается первая часть статьи, обсуждающей вопросы аудита безопасности аутентификации на сайте. Данная часть была сфокусирована на именах пользователей и паролях. Во второй части речь пойдет о конфиденциальности пользователя, сессиях аутентификации, безопасности пользователя и кукисах.
