Эта содержательная статья предполагает, что пароли не должны быть очень надежными: http://www.baekdal.com/tips/password-security-usability?
Здесь есть одна конкретная строка, которая меня беспокоит:
Фактическое количество варьируется, но большинство веб-приложений не смогут обрабатывать более 100 запросов на вход в секунду.
Верно ли, что большинству веб-приложений требуется защита только от 100 попыток в секунду? Кажется, что это очень мало, если вы имеете дело с распределенными системами, которые могут быть атакованы несколькими злоумышленниками.
РЕДАКТИРОВАТЬ Дополнительные пояснения по моему вопросу: исходя из текущей средней производительности большинства веб-серверов, каково максимальное количество попыток входа в систему, возможных во время атаки методом грубой силы? Я не спрашиваю о парольных атаках в автономном режиме, когда кто-то действительно может совершить попытки входа в систему.
В перспективе, предположим, что у вас есть требование к системе, которая не может использовать tar-pitting или временное отключение учетной записи (чтобы предотвратить DoS-атаки хакерами через попытки входа в систему), количество фактических попыток входа в секунду в веб-системе очень полезно.
но большинство веб-приложений не смогут обрабатывать более 100 запросов на вход в секунду.
Это значит: Автор этой статьи делает необоснованное (но не совсем необоснованное) утверждение, что отправка более 100 входов в секунду была бы эффективной атакой отказа в обслуживании против «большинства» веб-приложений.
Для каждого входа типичное веб-приложение должно хешировать пароль и сравнивать его с хешированным представлением в базе данных. Если веб-приложение использует хорошая функция хеширования, это действительно использует изрядное количество ЦП. Таким образом, это утверждение, возможно, не совсем необоснованно, но, по моему опыту, большинство веб-приложений просто используют простой хеш, такой как MD5, SHA1 или SHA256, который не требует интенсивного использования процессора.
В этой статье содержится большая ошибка:
Примечание. Приведенные ниже примеры основаны на 100 запросах пароля в секунду.
В следующих абзацах автор делает предложения по надежности пароля, исходя из максимальной скорости атаки 100 попыток в секунду. Это может быть разумным числом для онлайн атака, при которой злоумышленник подключается к действующему веб-приложению.
Но для не в сети Атака, при которой злоумышленник сначала загрузил всю базу данных с помощью атаки SQL-инъекции, это совершенно неправильно. Например, вот Реализация NVIDIA CUDA для SHA1, который может сделать 47 миллионов хешей в секунду на небольшом кластере серверов.
веб-приложениям нужно только иметь возможность защищаться от 100 попыток в секунду?
Извините, но нет, вы неправильно поняли эту часть. Теперь вы смотрите на это с точки зрения владельца веб-приложения, пытающегося защищать против онлайн атака методом подбора пароля. Вы должны принять меры длинный прежде чем дойдет до этого.
Наконец, вы можете захотеть прочитать FAQ к статье, это проясняет смысл авторов. Он говорит о том, как конечные пользователи могут генерировать достаточно безопасные и при этом легко запоминающиеся пароли, а не об обработке паролей на стороне сервера.
Обновление, после редактирования вопроса:
Исходя из текущей средней производительности большинства веб-серверов, каково максимальное количество попыток входа в систему во время атаки методом грубой силы?
Для простого хэша, такого как SHA1, я бы сказал, что один четырехъядерный сервер, при условии наличия хороших методов программирования, мог бы обрабатывать очень приблизительную оценку 10 000 запросов в секунду. Это будет полностью зависеть от используемой инфраструктуры и программирования веб-приложений, поскольку накладные расходы на обработку HTTP-соединения будут преобладать над скоростью вычисления SHA1. Если мы используем Apache в режиме Prefork с fx PHP, то цифры будут намного меньше, возможно, 2000 запросов в секунду на сервер.
Допустим, у вас есть требование к системе, которая не может использовать тар-питтинг или временное отключение учетной записи
Затем измените требования - это не подлежит ремонту.
количество фактических попыток входа в систему в секунду в веб-системе очень полезно.
Опять же, у вас должно быть предупреждение, которое уведомляет вас о нападении грубой силы. длинный прежде, чем он станет таким массовым.
Вы можете реализовать easy jail для брутфорсеров. Скажем, после 3 неудачных попыток входа вы блокируете вход с этого IP-адреса на 1 (или более) минуту (а), но просто продолжаете отправлять клиенту несоответствие пользователя / пароля
Другой способ - разделить логины пользователя и администратора. скажем, вы создаете основную форму для входа в систему и помещаете рядом с ней фальшивую кнопку для входа в систему администратора, которая всегда будет говорить «Неверный пароль». и сделать какую-то скрытую веб-страницу для реального входа в систему администратора: D
Автор этой статьи делает серьезные предположения о количестве запросов, которые могут обрабатывать «обычные» веб-приложения. Если ваш сайт находится на выделенном сервере с хорошо написанным кодом, он вполне может обрабатывать 1000 запросов в секунду, не беспокоясь. Старый сервер без какой-либо оптимизации может обрабатывать только 10 запросов в секунду, прежде чем он начнет останавливаться. Автору пришлось выбрать число, на котором он будет строить свои расчеты, и 100 кажется разумным местом для начала.
Если вы пытаетесь защититься от грубой силы или атак по словарю, вы можете использовать различные методы, такие как тар-питтинг, как упоминалось в TessellatingHeckler, или временные блокировки учетной записи, как это предлагается в статье. Я даже видел системы, которые просто игнорируют запросы с любого IP-адреса, который он видит, отправляя запросы с превышением определенной скорости.
Что касается исходного вопроса, злоумышленник захочет иметь возможность попробовать как можно больше паролей, НЕ останавливая сервер, так что это не значит, что вам нужно иметь возможность "защищаться" от определенного количества запросов в секунду, как злоумышленник ограничит скорость своих собственных инструментов, если увидит, что это вызывает замедление работы сервера, потому что в их интересах не привлекать к себе внимания. Просто спроектируйте свое приложение так, чтобы оно могло обрабатывать ожидаемую нормальную нагрузку плюс некоторый разумный запас для роста и случайных всплесков трафика.
Если вас беспокоят обычные DDoS-атаки, это совсем другое дело и не имеет ничего общего с запросами в секунду для попыток ввода пароля.
Как нам ответить на вопрос о «большинстве» веб-приложений? Для начала, большинство из них, вероятно, находятся во внутренней сети компании, но также у вас, вероятно, закончится «большинство» к тому времени, когда вы дойдете до веб-приложений, работающих на 2+ серверах.
В любом случае, я не думаю, что в нем говорится, что вы будете получать только 100 запросов в секунду, так что это все, от чего вам нужно защищаться, как звучит ваш вопрос, но скорее вы можете обрабатывать только 100 запросов в секунду (что составляет 60000 / минута), так что этот уровень является хорошим компромиссом.
Если ваше приложение может обрабатывать 1000 входов в секунду, возможно, стоит переосмыслить ситуацию.
В статье не упоминается тар-питтинг, который представляет собой практику замедления ответов на вход, поэтому грубая форсировка становится невозможной - вы, возможно, видели это сами, когда пытались войти в систему 5 раз, и после этого каждый раз, когда вы вводите пароль, он остается там. целую вечность, прежде чем сказать вам, что это не удалось, и после 10 попыток задержка становится больше. Продолжайте пытаться, и он продолжает замедляться, но уйдите и вернитесь через двадцать минут, и это снова быстро.
Это может сделать практически невозможным брутфорс.