безопасная веб-аутентификация с использованием файлов cookie

Question

Я занимаюсь разработкой веб-приложения на PHP, и основной задачей приложения является безопасность. До сих пор я сохранял данные аутентификации в 2 файлах cookie:

• одно печенье для уникальной строки хеша (30 символов)
• один файл cookie для уникального идентификатора (первичный ключ таблицы базы данных mysql, в которой хранится информация о файле cookie и идентификатор пользователя)

Таблицы БД выглядят так:

• Пользователи ( user_id , имя пользователя, пароль)
• Cookies ( cookie_id , user_id, hash, time, ip)

Когда пользователь заходит на страницу, приложение проверяет наличие файлов cookie (проверка файлов cookie) на клиенте и сравнивает их с таблицей базы данных Cookies. Если строка хеша и идентификатор совпадают, сеанс продлевается, а если нет, сеанс уничтожается (если существует), и пользователю предлагается войти в систему. Он также проверяет, истек ли сеанс, сравнивая текущую отметку времени с отметкой времени последней операции.

Когда пользователь входит в хеш-строку, он генерируется и сохраняется в базе данных (текущая отметка времени и IP-адрес также сохраняются). Первичный идентификатор вновь созданной строки и строки хеша затем сохраняются в двух файлах cookie и используются для аутентификации.

Я хотел бы внедрить дополнительную безопасность для предотвращения атак по словарю или методом "грубой силы", подавляя попытки входа в систему и проверки файлов cookie. Я хотел бы добиться этого, когда пользователь не может N раз войти в систему или проверить файлы cookie, которые он блокирует на 20 минут. Но если я сделаю это, используя IP, я потенциально заблокирую каждого пользователя, использующего этот IP.

Я мог заблокировать определенную учетную запись пользователя, когда было предпринято более X неудачных попыток, но проблема в том, что злоумышленник не предоставил правильное имя пользователя (поэтому мне пришлось бы заблокировать весь IP на N минут).

Форма входа также имеет проверку капчи, но это только замедляет атаку (ничто по сравнению с отказом в попытках входа в течение X минут).

• Есть ли другой способ запретить попытки входа в систему без блокировки всей сети, использующей этот IP?
• Должен ли я отказываться от попыток входа в систему, когда есть N неудачных проверок cookie?
• Если куки пользователя украдены, я использую IP в таблице Cookie, чтобы предотвратить его повторное использование, поэтому куки могут использоваться только с того же IP, что и пользователи. Это безопасно, или я должен сделать это как-нибудь еще?

Заранее спасибо,

PS: все пароли в базе данных хэшируются, значения cookie кодируются перед использованием в запросе db (поэтому инъекции невозможны).

Answer 1

Я занимаюсь разработкой веб-приложения на PHP, и основное внимание в этом приложении уделяется безопасности

Если вы заботитесь о безопасности, вам не следует реализовывать аутентификацию самостоятельно, а использовать OpenID так же, как stackoverflow.com => http://www.codinghorror.com/blog/2008/05/openid-does-the-world-really-need-yet-another-username-and-password.html

LightOpenID - очень приятная / простая библиотека openID => http://gitorious.org/lightopenid

Я хотел бы реализовать дополнительную защиту для предотвращения атак по словарю или грубой силы, ограничивая попытки входа и проверки сеанса.Я хотел бы добиться этого, когда пользователь не может N раз войти в систему или проверить файлы cookie, которые он блокирует на 20 минут.Но если бы я делал это, используя IP, я потенциально мог бы заблокировать каждого пользователя, использующего этот IP.

PS: я бы использовал OpenID, но ниже я расскажу, как мне это сделать.

Как вы говорите, блокировка IP-адресов плохая, потому что многие пользователи используют один и тот же IP-адрес через NAT.но когда вы подозреваете атаку методом грубой силы (с IP), я бы просто позволил им проходить аутентификацию только в том случае, если они правильно вводят капчу.Таким образом, пользователи, находящиеся за NAT, могут по-прежнему входить в систему, пока хакер не работает.

Форма входа также имеет проверку капчи, но это только замедляет атаку (ничто по сравнению с отказом в попытке входа в систему для Xминут).

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

Answer 2

Безопасность достигается не сложным кодом, а простотой . Вместо того, чтобы придумывать свою собственную обработку сессий, вы должны использовать php's встроенный .

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

Вы должны ограничивать количество попыток аутентификации (т.е. вводить пароли), возможно, с помощью CAPTCHA или, что еще лучше, вообще не хранить пароли и использовать OpenID . Также недостаточно просто хэшировать пароли; используйте соль .