Вход попыток аутентификации включая пароли
В PHP 5 можно использовать SoapClient на WSDL для вызывания функций веб-сервиса. , Например :
$client = new SoapClient("some.wsdl");
и $client теперь объект, который имеет методы класса, как определено в some.wsdl. Таким образом, если бы был метод, названный getTime в WSDL тогда, то Вы просто звонили бы:
$result = $client->getTime();
И результат этого (очевидно), был бы в переменной $result. Можно использовать __ getFunctions метод для возврата списка всех доступных методов.
9 ответов
есть большая разница между ошибкой пользователя и атакой грубой силы / словаря: объем запросов . Не храните неудачные попытки - вы совершенно правы, что с паролем в виде открытого текста следует обращаться минимально - просто посмотрите на схему попыток. Этого должно быть достаточно данных.
что-нибудь еще, и ваша «повышенная безопасность» начинает выглядеть как «расширенные возможности вектора атаки».
Это похоже на чрезмерную инженерию. Я бы просто отслеживал неудачные попытки входа в систему, и после того, как количество неудачных попыток входа в систему составляет $ x, вы затем блокируете IP от попытки другого входа в систему в течение 1-24 часов или около того.
Если вы обеспокоены тем, что кто-то нацелен на конкретную учетную запись, вы можете отметить количество неудачных попыток для определенного имени пользователя, а затем принять соответствующие меры, такие как ограничение неудачных входов в систему с этим именем пользователя до 2 или 3 за 24-часовой период с любого IP-адреса. адрес.
Я могу придумать, как вы могли бы попытаться обнаружить атаки по словарю / перебора путем сравнения, но вам придется собирать вводимые пользователем данные и сравнивать их с предыдущими попытками, это может быть проблемой безопасности, если вы хранение легитимных паролей с небольшими ошибками в базе данных.
Регистрация сырых паролей кажется действительно плохой идеей, как вы сами указали.
Не могли бы вы просто зарегистрировать имя пользователя и время неудачных попыток входа в систему, фактически не регистрируя пароли? Было бы довольно очевидно, если бы была атака грубой силой, если бы были сотни попыток входа в систему за короткий промежуток времени. Вы также можете зарегистрировать IP-адрес.
Я не уверен, что вы имеете в виду, когда упоминаете о хранении необработанных паролей - по-видимому, вы хотите сохранить только неудачные попытки ввода пароля в виде простого текста для анализа шаблонов (словарные атаки) и объема (грубый force).
В моем ограниченном опыте вы должны были взять введенный пользователем пароль, хэшировать его (с солью, той же солью, которая используется для хеширования сохраненного пароля) и сравнить с сохраненным хешированным значением. Если проверка не удалась (хешированные значения не равны), запишите в журнал текстовую версию пароля, использованного для попытки.
Я бы посоветовал также реализовать блокировку учетной записи после определенного количества неудачных попыток и, возможно, имея экспоненциальное окно тайм-аута, когда можно повторить попытку входа в систему. Если пользователь вводит пароль неправильно, чтобы начать,
В зависимости от выбранного вами протокола аутентификации, например, в случае Kerberos , у вас может не быть доступа даже к введенному паролю.
Вы когда-нибудь думали о фиксированном количестве логинов, а затем о временном блоке? Если логин не удался 3x / 5x / 10x, если хотите, то полностью заблокируйте учетную запись на определенный период времени.
Делая это, вы делаете это настолько кропотливым для использования брутфорсером, что они, вероятно, просто не будут не пытайся. Вести журнал каждой неудачной попытки, и более того, даже мысль о паролях в виде простого текста - плохая идея. Скорее используйте следующую аналогию:
«Если я сделаю свой дом таким трудным для проникновения, они сначала испытают соседей».
Сделайте жизнь грубой силой, и они не будут беспокоить.
Другой вариант - после заданного количества неудачных попыток входа в систему добавить captcha . Это опять же, если капча правильная, резко мешает их прогрессу.
HTH,
Kyle
Как говорили другие, регистрация паролей - плохая идея.
Гораздо лучшая идея - ограничить попытки входа в систему .
Если все сделано правильно, дросселирование может значительно снижает риск парольных атак, а также ограничивает атаки типа «отказ в обслуживании».
Как отмечали другие, хранить пароли в виде открытого текста очень - плохая идея, и регулирование / ограничение попыток входа в систему - правильный путь.
Если это так, заботясь о безопасности паролей, то вам следует реализовать политику паролей при создании паролей , а не во время аутентификации. Затем вы можете проверить в памяти слова словаря и использовать типичные политики, такие как минимальная длина, должна содержать число, заглавную букву и т. Д.
Конечно, политики паролей могут раздражать пользователей, но теоретически они могут улучшить ваше беспокойство по поводу слабых паролей.
Уродливая правда в том, что пароли - плохой способ подтвердить личность, но альтернативы более дорогие и громоздкие.
Вы можете хранить хэши неудачных паролей, если вы действительно хотите сохранить какую-либо информацию о них . Это не позволит вам анализировать шаблоны вручную, но позволит сравнивать неудачные попытки друг с другом.
Тем не менее, я не думаю, что анализ паролей даст какую-либо полезную информацию.