> а как же скрипт кидди? лишь бы куда влезть, а потом об этом > везде кричать.
Если ты защищаешь что-то серьезное, то без стойких паролей все равно не обойтись.
А если инфа выеденного яйца не стоит, то пусть ломают все подряд.
Разве на имидж mail.ru повлияют крики кулхакера, который вскрыл аккаунт своего соседа-второгодника, угадав пароль со второй попытки?
Какие есть хитрые трюки для защиты от подбора?
Допустим есть два типа взлома:
1. Подбор пароля для конкретного логина.
2. Подбор логина под конкретный пароль.
Как более грамотно защититься, чтобы меньше страдали пользователи, сидящие за прокси/натом?
Кто юзеры системы? И почему ограничение по набору символов в пароле? Ограничение по пользователям (слабая память:-)) или по системе (не встречал еще такой:-)).26.01.06 14:09 Автор: Garick <Yuriy> Статус: Elderman Отредактировано 26.01.06 14:13 Количество правок: 1
Юзеры системы - обычные пользователи, возможно некоторые даже слабо разбирающиеся в компьютерной технике и с трудом различающие кнопки Power и reset на системном блоке.
Область применения такая, что вносятся ограничения...
На кнопках Повер и Ресет тяжеловато набрать код, хотя задержка будет хорошая:-) Круг пользователей определен или открытый ресурс?26.01.06 14:22 Автор: Garick <Yuriy> Статус: Elderman
Круг пользователей определен. Но ресурс открытый, нету какой-то привязки к диапазонам ip.
Продолжаем вытягивать подробности:-) Те юзверям возможно раздать носители ключевой инфы и уже их запоролить цифрами. Если конечно ограничения в пользователях, а не софте.26.01.06 14:33 Автор: Garick <Yuriy> Статус: Elderman
сабж, т.е. у юзера они должны быть включены, хотя это не самое злое неудобство, имхо
Читаем есть ли кука с ID у данного чела. Проверяем ее.. Если все в порядке даем ему вводить логин/пароль. Если от данного ID дофига запросов - то блокируем его (можно на очень долго). Если же куки нет или она не в порядке (но не заблокирована) - то генерим новый ID. При генерации должна быть задержка.
В итоге:
1. Легальный пользователь, который уже хоть раз заходил - имеет легальную куку и может вводить логин/пароль совсем без задержек.
2. Легальный пользователь, который пришел первый раз (ну или куки очистил) - получит задержку при генерации, но потом будет входить без задержек.
3. Не легальный пользователь (робот), у которого уже есть нужная кука - будет заблокирован после попытки перебора. Т.е. "умный" робот должен очистить свою куку в этом случае, и перейти в пункт 4
4. Не легальный пользователь (робот), у которого нет куки - получит задержку при генерации и перейдет в разряд 3. Т.е. задержка получится все равно.
> сабж, т.е. у юзера они должны быть включены, хотя это не > самое злое неудобство, имхо > > Читаем есть ли кука с ID у данного чела. Проверяем ее.. > Если все в порядке даем ему вводить логин/пароль. Если от > данного ID дофига запросов - то блокируем его (можно на > очень долго). Если же куки нет или она не в порядке (но не > заблокирована) - то генерим новый ID. При генерации должна > быть задержка. --skip--
Имхо куки есть бооольшой вред.
А почему же вред? В данном случае в ней не хранится ничего конфиденциального!26.01.06 14:27 Автор: whiletrue <Роман> Статус: Elderman
> Сабж, она же CAPTCHA, она же тест на человечность. > http://www.captcha.net/ > > Хотя, есть для нее софт и методы по распознаванию. Но как > дополнительная мера - не плохо.
Почитав что это такое и возможности - имхо оооочень неплохой сдерживающий фактор от роботов и скрипт-кидди
> Вторая полумера - это фильтровать не только по IP-шникам, а > по полному набору переменных.
Кстати да, может какие переменные из окружения можно вытянуть, чтобы более-менее идентифицировать пользователя?
Да, имхо - бери полный набор да делай из него хэш...26.01.06 14:39 Автор: whiletrue <Роман> Статус: Elderman
По каким параметрам блокировать? ip? тогда будут страдать другие люди за прокси/натом. По логину? Так тогда появляется пункт2 - подбор логинов по паролю...
Ну... можно добавить еще проверку на человечность (captcha) - тож мера.26.01.06 13:38 Автор: whiletrue <Роман> Статус: Elderman