Авторизация с использованием протокола SSL и защита от перебора пароля

Astral Man

We Will Rock You
Авторизация с использованием протокола SSL и защита от перебора пароля

Всем привет!

Делаю авторизацию пользователей с использованием SSL протокола, возник вопрос - как защититься от подбора пароля? Блокировака по IP не подходит т.к. пользователи могут работать в за одним внешним IP.
Можно как-то определить что пользователь авторизуется именно через браузер а не использует сокеты и т.п. ? Или есть какие-то методы самого SSL?

Надеюсь вопрос понятен.
 
Автор оригинала: Astral Man
Блокировака по IP не подходит т.к. пользователи могут работать в за одним внешним IP.
Блокировать не после первой неудачной попытки, а, скажем, после пятой. Или десятой. И не с одного IP (ведь можно использовать список проксей), а в течение заданного отрезка времени.

Автор оригинала: Astral Man
Можно как-то определить что пользователь авторизуется именно через браузер а не использует сокеты и т.п. ?
Думаю, не все боты умеют использовать куки и JavaScript.
 
Делаю авторизацию пользователей с использованием SSL протокола
мсье не разбирается в вопросе
реккомендую почитать, что такое SSL и для чего он используется
 
yugene
Блокировать не после первой неудачной попытки, а, скажем, после пятой. Или десятой. И не с одного IP (ведь можно использовать список проксей), а в течение заданного отрезка времени.
Т.е. блокировать логин? Так не пойдет, если его заблокировать то реальный пользователь не сможет работать.

-~{}~ 19.07.05 10:02:

Tor
Я знаю что такое SSL, и использую авторизацию по этому протоколу. Может просто не корректно поставил вопрос.
Если пользователь соединяется по SSL то устанавливается защищенное соединение.. пользователь получает с сервера открытый ключ (если не ошибаюсь) и с помощью это ключа он идентифицируется на сервере.. правильно?
Может можно определить этот ключ, и в случае перебора паролей блокировать этого пользователя по этому ключу.
 
Нет, средствами PHP ключ определить невозможно (и вообще SSL сделан так, что протоколы, работающе поверх него, не должны ничего знать о его существовании), кроме того, при каждом новом соединении (даже с одного IP) ключ будет разный.
А к решению проблемы защиты от перебора нужно подходить следующим образом:
1) проверяем, когда была попытка предыдущего входа
2) если она была менее 30 секунд (или любого другого подходящего времени) назад, то в любом случае (даже при правильном пароле) выдаем сообщение "неверный пароль"
3) если предыдущая попытка входа была более 30 секунд назад, производим проверку пароля, как обычно
4) объясняем пользователям, что если они получили сообщение "Неверный пароль", то следующую попытку входа они могут предпринять не ранее, чем через 30 секунд.
 
если она была менее 30 секунд (или любого другого подходящего времени) назад, то в любом случае (даже при правильном пароле) выдаем сообщение "неверный пароль"
если попытка была менее 30-ти секунд назад, то даже ресурсы тратить на проверку пароля не стоит

з.ы. 30 уменьшил бы до 10-ти
 
XXXX Pro
Спасибо за совет! Млин и чего я сам до такой илементарщины не додумался...
 
Автор оригинала: XXXX Pro
А к решению проблемы защиты от перебора нужно подходить следующим образом:
Получается, если в течении дня идет атака с перебором пароля, залогиниться вообще не получится?
 
ну если атакующий сидит с тобой в одной сетке...
 
yugene
А ты прав...

physh
Причем тут одна сетка? или ты имеещь ввиду под одним внешним ip ?
 
Как одно из решений:
Под каждое имя пользователя отводи поле, когда последний раз пытался залогиниться. Затем просто проверяй, если идет логин на то же имя, а TIMEOUT еще не истек с прошлого раза, то отказывай в доступе + можно привязать проверку по IP + куки.
 
rotoZOOM
Затем просто проверяй, если идет логин на то же имя, а TIMEOUT еще не истек с прошлого раза, то отказывай в доступе
И в случае перебора паролей настоящий пользователь зайти не сможет...

Господа, а вообще стоит на этом заморачиваться? Пароль подобрать все равно не смогут, он не меньше 8 символов... единственное беспокоит многочисленные обращения к базе во время перебора...
 
Давать ответ не сразу, а через секунду. Это конечно не спасет от параллельных запросов. Имхо это самое простое, что можно сделать и больше не париться.
 
Сверху