Надерем хацкерам задницу!

Никита "red_way" Кислицин

Xakep, номер #065, стр. 065-118-2

$res.=chr($rnd);

}

/* Возвращаем результат */

return $res;

}

Надо заметить, что это общепринятая практика. Чего только стоят некоторые коммерческие дистрибутивы Unix (привет, Compaq tru64!), которые не позволяют пользователям юзать простые пароли, так и норовя сгенерировать что-то зубодробительное длиной в 16 символов :). Само собой, хорошая система аутентификации должна хранить на сервере информацию о времени последнего изменения пароля и заставлять пользователя выполнять эту неприятную ему операцию раз в несколько месяцев.

Все люди ошибаются. Пользователи - чаще. Не потому что глупы. Ежедневный стресс, плохая экология и нервная работа - все это приводит к ужасной забывчивости пользователей :), поэтому автоматическая система напоминания пароля просто необходима, если, конечно, ты не хочешь превратиться в 24h-службу доверия и психологической помощи. Распространенной практикой является предоставление пользователю возможности отсылки пароля на e-mail. Однако этим самым ты доверяешь почтовой службе пользователя, кроме того, если через ошибку в твоих скриптах взломщик смог залогиниться под каким-либо пользователем, не зная пароля, он сможет заменить пользовательский адрес своим и получить полноценный акцес к твоему сервису. В целях безопасности здесь можно запретить отсылку пароля, если e-mail был сменен менее чем 10 дней назад. Полезны могут быть такие параноидальные, на первый взгляд, меры, как уведомление пользователя о смене любой его личной информации. Тут надо быть осторожным и соизмерять риски с приобретенным геморроем.

Защита от грубой силы

Как говорится, сила есть - ума не надо. Зачастую так и бывает. Любую систему, теоретически, возможно взломать просто тупым перебором паролей. Другое дело, что методы поиска уязвимостей и социальной инженерии дают отдачу значительно быстрее. Однако, как показывает практика, многие громкие взломы совершены именно с использованием переборщиков (чего стоит только первый дефейс www.xakep.ru!). Однако от любого bruteforce’а весьма надежно защищает одна очень изящная концепция, которая заключается в следующем: если пользователь не смог пройти аутентификацию, то следующий запрос от него не принимается до тех пор, пока не пройдет некоторое время - например, 3 секунды. Таким образом, перебор пароля грозит затянуться надолго - даже если он состоит из шести цифр (идеальный вариант для брутфорсеров), полный перебор всех вариантов займет больше месяца. Более того, в такой системе рационально блокировать аккаунт на более значительное время после некоторого количества неудачных попыток аутентификации. Обрати внимание, что есть аналогичная концепция, которая идентифицирует пользователя не по логину, под которым он хочет войти в систему, а по IP - на мой взгляд, это менее эффективное направление, однако и оно дает отличные результаты!

Криптуй все

Представим на минуту печальную ситуацию. Из-за твоей невнимательности, через SQL-injection взломщик получил доступ ко всем таблицам базы данных. Выяснив названия всех таблиц, полей и их типов, он сможет без проблем извлекать любую инфу из базы данных. Именно поэтому очень важно использовать двойной уровень защиты - самые ценные данные (например, информацию о финансовых транзакциях или пароли пользователей) следует хранить в базе данных в зашифрованном виде, таким образом, даже получив доступ к этой информации, злоумышленник не сможет ей нормально пользоваться, а на расшифровку опять-таки уйдет уйма времени. Не буду тебя грузить теорией криптографии (кое-что на эту тему есть в статье «Шифруйся сам» этого номера), а если тебе интересны математические основы и общие концепции этой науки, я бы посоветовал обратиться к шедевру computer science - книге Брюса Шнаера “Прикладная криптография”. Нам же сейчас достаточно знать, что есть симметричные и несимметричные алгоритмы, а также хеш-функции. Для данных, которые предполагается использовать в первозданном виде, расшифровывая в самой программе, обычно используют симметричные коды - хотя это зачастую не дает ожидаемого результата, поскольку ключ шифрования приходится хранить внутри сценария либо получать откуда-то извне, что само по себе небезопасно.