Ограничение попыток входа в систему независимо от пользователя?

У меня есть система входа в систему, требующая имени пользователя и пароля. Я хочу отображать капчу после определенного количества неудачных попыток входа в систему. Как правильно это реализовать? Я читал на этом сайте, и некоторые решения предлагают добавить «количество неудачных попыток» в таблицу пользователей. Однако мне нужно, чтобы неудачные попытки не были привязаны к определенному пользователю, то есть я бы хотел, чтобы капча отображалась независимо от того, существует ли в системе введенное имя пользователя. Можно ли сохранить это в переменной сеанса (я использую PHP)? Если да, то нет ли недостатков в простом добавлении данных по мере необходимости в переменные сеанса? У меня уже есть идентификатор сеанса для каждого посетителя на сайте (вошел в систему или нет), поэтому я могу создать таблицу, которая связывает попытки входа в систему с этим идентификатором сеанса ... какие-либо идеи о том, какой подход является лучшим / наиболее безопасным? Спасибо.

Обновление: из ответов на данный момент, похоже, что идентификатор сеанса - не лучшая идея, поскольку хакер может просто очистить свой кеш (но действительно ли это проблема, потому что это не замедлит грубую силу атаки достаточно, чтобы сделать его бесполезным?). Другой вариант - по IP ... но я сомневаюсь в отношении пользователей интрасети или прокси, поскольку неудачные попытки будут разделены .... Я действительно не могу придумать никаких других методов ... можете ли вы?


person oym    schedule 31.07.2009    source источник


Ответы (5)


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

Имейте в виду, что автоматическая атака грубой силой может быть написана на языке сценариев вне браузера, который может управлять файлами cookie, отправляемыми для каждого запроса.

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

ОБНОВЛЕНИЕ: необходимость очистки файлов cookie во время последовательных попыток грубой силы не замедлит атаку, поскольку этот процесс будет автоматизирован и произойдет почти мгновенно. Манипуляции с файлами cookie при таких атаках довольно распространены. Изменение файла cookie - это не то же самое, что очистка кеша вашего браузера (что обычно требует времени, так как необходимо удалить кучу файлов). Все, что нужно сделать злоумышленнику, - это предотвратить отправку файла cookie.

person Andre Miller    schedule 31.07.2009

установите APC http://www.php.net/apc или memcache (d) http://www.php.net/memcache или здесь http://www.php.net/memcached (memcache также требует установки сервера memcached, см. здесь http://www.danga.com/memcached/), затем используйте соответствующие команды увеличения для неудачных попыток входа с IP-адреса с тайм-аутом все, что вам подходит (5 минут, 30 минут и т. д.). это позволит вам БЫСТРО определить, происходит ли попытка грубой силы (не беспокоясь о состоянии гонки), и автоматически истечет срок действия блока через определенное время.

Пример APC:

$max_attempts = 5;  // max attempts before captcha
$attempts = apc_fetch('login_attempts_'.$ip));
if($attempts and $attempts>$max_attempts){
    // block code here or redirect, captcha etc... also suggest a short sleep time to delay answer, slow down bot
}else{
    // check login here, run next code if login fails
    if($login_failed){
        if(!$attempts){
            apc_store('login_attempts_'.$ip,1,$timeout);
        }else{
            // function NOT currently documented on php.net, increments number stored in key
            apc_inc('login_attempts_'.$ip);
        }
    }
}

конечно, это очень грубый пример ... но вы поняли идею

person Jason    schedule 31.07.2009
comment
APC устарел, но вместо него вы можете использовать APCu. - person helderk; 14.07.2021

Сеансовый подход не будет работать, если хакер закрывает свой браузер и повторно открывает его при каждой попытке, поэтому таблица, в которой хранится количество неудачных попыток и время последней попытки (чтобы вы могли проверить, прошел ли, скажем, час, чтобы вы могли сбросить counter) на пользователя будет самым безопасным способом.

person Blindy    schedule 31.07.2009
comment
верно, но я подумал, что идея капчи в первую очередь состоит в том, чтобы препятствовать автоматическим атакам методом грубой силы ... поэтому закрытие браузера или очистка кеша после каждой попытки не решают проблему сами по себе? - person oym; 31.07.2009
comment
и вы говорите сохранять неудачные попытки для каждого пользователя - означает ли это, что счетчик неудачных попыток будет увеличиваться только при вводе действительного идентификатора пользователя (и не будет, если идентификатор пользователя и пароль недействительны)? - person oym; 31.07.2009
comment
Хорошо автоматизированные атаки методом грубой силы могут легко уничтожить объект WebClient и создать новый при каждой попытке. Что касается второй части, вы можете реализовать второй резервный уровень безопасности внутри объекта сеанса на случай, если идентификатор пользователя недействителен, и отработайте это. Обратите внимание, однако, что сохранение попыток взлома для каждого пользователя позволяет вам делать больше, чем просто запрещать IP-адрес, оно позволяет вам фактически изменить pw и отправить его по электронной почте на адрес электронной почты пользователя (я видел, как Blizzard делала это раньше). - person Blindy; 31.07.2009

Вы можете регистрировать все неудачные попытки с IP-адресом и временем. Старые неудачные попытки удаляются через определенное время, и если их больше, чем определенное количество неудачных попыток для данного IP-адреса, отобразится капча.

person Moak    schedule 31.07.2009

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

person Hans    schedule 31.07.2009