Предотвращение взлома грубой силой сложнее, чем может показаться на первый взгляд. Решение будет заключаться в объединении элементов управления - один элемент управления не будет разрезать горчицу. И помните цель: вы хотите замедлить атаку грубой силой до такой степени, что она будет либо неэффективна, либо вы сможете обнаружить ее и принять меры. Второй вариант, как правило, более эффективен, чем первый.
Вы можете использовать капчу (это в настоящее время популярный метод), но капчи часто можно автоматически прочитать, а когда они не могут быть прочитаны компьютером, фермы людей могут быть получены путем оплаты низкооплачиваемых работников или путем используя капчу для защиты «бесплатно» порно (используются оба метода).
Совет других использовать секретное значение в форме не очень поможет; злоумышленник просто должен проанализировать HTML-код, чтобы найти секретное значение, и включить его в свой пост. Это довольно просто автоматизировать, поэтому это не очень хорошая защита. Да, и если значение оказывается легко предсказуемым (с использованием плохого или сломанного PRNG или плохого семени), вы снова на ходу.
Отслеживать IP-адрес можно, но только если вы не поддерживаете NAT. С NAT действительные пользователи будут дубликатами. И помните, что злоумышленники могут выдавать себя за другие системы; одна система атаки может использовать другие IP-адреса и даже перехватывать трафик к этой системе (отравление ARP является хорошим механизмом для этого).
Вы можете использовать максимальное количество неудачных тайм-аутов за определенный период времени (например, 3 в течение 1 часа). Это замедляет атакующего, но не обязательно останавливает его. Вы можете включить автоматическую разблокировку, но вам нужно будет немного посчитать и убедиться, что время разблокировки действительно полезно.
Экспоненциальный откат - еще один полезный механизм. Это может быть возможно для привязки к сеансу (который злоумышленник не должен возвращать на сервер) к IP-адресу (с разрывами с NAT) или к учетной записи (которая не учитывает перебор нескольких учетных записей) .
Чтобы другие средства защиты были полезны, у вас должны быть надежные пароли. Если ваши пароли легко угадать (они в словаре? Они короткие? Они сложные?), Атака будет успешной. Хорошая идея - реализовать минимальные требования к надежности пароля и словарь «недопустимых паролей» (в сочетании с заменами общих символов для этого словаря). В качестве альтернативы вы можете использовать такие системы, как OATH, сертификат для входа в систему или аппаратные токены (например, SecurID RSA).
Я думаю, что это был Берт Калиски, который обсуждал клиентские загадки. По сути, вы ставите перед клиентом задачу, которая проста для сервера, но сложна для клиента; клиент делает сам, тратя свои собственные ресурсы, пытаясь разгадать загадку. Сложность здесь заключается в определении правильной сложности для головоломки. Это может быть, например, факторинг большого числа. Как бы то ни было, вам нужно было бы выбрать наиболее эффективный алгоритм, и вы должны были бы иметь возможность обрабатывать различные показатели производительности разных браузеров на разных компьютерах (потенциально медленные), одновременно замедляя автоматические атаки вне браузеров (потенциально быстрее, чем ваш javascript). Я уже говорил, что вам нужно реализовать решение на JavaScript?
Но вы все еще застряли с атакой, которая работает на несколько учетных записей. Мне неизвестны какие-либо общедоступные элементы управления, которые хорошо работают против этого, если вы не можете отслеживать IP-адреса.
Тогда вы захотите защитить имена пользователей. Злоумышленник, который не знает имен пользователей (требуется система, которая не указывает, когда имена пользователей действительны) должен будет выучить как имя пользователя, так и пароль, вместо того, чтобы легко подтвердить имя пользователя, а затем просто атаковать пароли.
И вам нужно быть осторожным, чтобы сообщения об ошибках и время сервера не выдавали (не) действительные пароли.
А когда вы работаете с сообщениями об ошибках, убедитесь, что механизмы восстановления пароля ничего не выдают. Даже в других хороших системах восстановление пароля может взорвать все это.
Но, несмотря на это, атака в конечном итоге зависит от производительности сервера. Вы можете просто реализовать очень медленный механизм аутентификации (должен быть медленным как для действительных, так и для недействительных аутентификаций). Онлайн-атака гарантированно будет идти не быстрее, чем сервер сможет обрабатывать запросы.
Затем вам необходимо обнаруживать атаки методом перебора, поэтому вашей системе нужен хороший контрольный журнал. Но вам нужно быть осторожным, чтобы не регистрировать слишком много сообщений журнала, иначе вы откроете простой способ дозировать сервер, заполнив дисковое пространство. Было бы неплохо что-то вроде сообщения системного журнала «предыдущее сообщение было получено 1000 раз».
Как только вы все закончили разработку вещей, и снова, когда вы закончите реализацию вещей, вы захотите изучить всю систему и все функции системы, математически смоделировать ее с учетом текущих настроек и производительности сервера. и определить среднее количество времени, которое потребуется злоумышленнику для подбора (а) одного аккаунта и (б) любого аккаунта (грубое форсирование по всем аккаунтам, чтобы избежать контроля над аккаунтом).