Как реализовать хорошую систему для входа / выхода в веб-приложение

Я один из разработчиков PassPad, безопасного генератора паролей и системы хранения имен пользователей. Мы все еще работаем над этим, но у меня есть несколько вопросов о наилучшем способе реализации безопасной системы входа / выхода.

Прямо сейчас мы планируем сделать так, чтобы система входа в систему сохраняла файл cookie с именем пользователя и ключом сеанса, и это все, что служит аутентификацией. Сервер проверяет соответствие этих двух. При входе / выходе создается новый ключ.

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

Есть ли лучший способ реализовать систему входа / выхода на PHP? Желательно, чтобы это не отнимало слишком много времени на кодирование или ресурсы сервера. Есть ли что-нибудь еще, что мне нужно реализовать, например, защита от перебора и т. Д.? Как мне это сделать?


web-applications security login login-control
person Brandon Wang    schedule 23.04.2010    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Убедитесь, что вы прочитали 10 лучших OWASP за 2010 год, особенно A3: Нарушение аутентификации и управления сеансом. Это важно, потому что вы уже нарушили его требования для https. Также не забудьте прочитать о CSRF, принуждение людей к входу в систему или выходу из вашей службы является уязвимостью. Отключите список каталогов в вашем .htaccess: http://passpad.org/actions/

Я также рекомендую запустить брандмауэр веб-приложения, особенно если вы веб-приложение для обеспечения безопасности. mod_security бесплатен и остановит множество атак. Также не забудьте протестировать свое приложение на наличие уязвимостей с помощью wapiti (с открытым исходным кодом) или acunetix ($$$), но убедитесь, что вы тестируете свое приложение с отключенным WAF.

Что касается защиты от перебора, мне очень нравится подход Gmail. Не предлагайте им капчу, пока они не наберутся достаточно «тепла». Тепло может накапливаться из-за неправильных действий в вашей системе. Тепло назначается IP-адресу, а не сеансу. Например, если они регистрируются для двух учетных записей пользователей, вы можете предложить им ввести capthca для третьей. Если у вас было 3 неудачных попытки входа в систему, вы должны их запросить. Если они решат капчу, вы можете «охладить» их, понизив их теплотворную способность или установив ее на ноль. Используйте reCpathca, это безусловно лучший вариант.

person rook    schedule 23.04.2010
comment
Спасибо за ваши комментарии. Обычно я веб-дизайнер, а не разработчик, поэтому многое из этого для меня немного внове. Однако у нас в команде есть эксперт по безопасности. Как я уже нарушил требования к https? Это то, что мы планируем использовать, поэтому, если я нарушаю его, мне нужно знать, как это сделать. Я обязательно отключу списки каталогов. Спасибо. Я также ценю ваши комментарии о WAF и подходе к теплу. Вы рекомендуете хранить тепло в базе и как? - person Brandon Wang; 24.04.2010
comment
@Brandon Wang https должен использоваться для всего сеанса, ни в коем случае нельзя передавать идентификатор сеанса через небезопасное соединение (http). Вы должны хранить тепло в базе данных, я бы сделал IP-адрес уникальным идентификатором, используя $ _SERVER ['REMOTE_ADDR'], который берется непосредственно из сокета, $ _SERVER ['X-Forwarded-For'] - это переменная, управляемая пользователем. который может содержать любое значение. - person rook; 24.04.2010
comment
Можно ли при входе использовать только https, как это делает Google? Я также понимаю, что вы имеете в виду под жарой. Я подумаю об этом. Вы, кажется, очень хорошо разбираетесь в этой области. Не могли бы вы помочь с PassPad в обмен на сокращение? - person Brandon Wang; 24.04.2010
comment
@Brandon Wang Прочтите топ-10 owasp, нет смысла использовать https для имени пользователя / пароля, если вы просто передадите идентификатор сеанса через несколько секунд, хакер, который обнюхивает строку, просто будет использовать аутентифицированный сеанс. Кроме того, Gmail использует https для всего после того, как Китай взломал Google. Я готов помочь, как мне с вами связаться? - person rook; 24.04.2010
comment
Я вижу здесь вашу логику. Риск не так уж велик - мы храним только имена пользователей - но я все же считаю, что мы должны его защищать. - person Brandon Wang; 24.04.2010