Почему большинство приложений так долго проверяют, что пароль неверный?
В частности, на ум приходят логины SSH и *NIX, хотя я видел это во многих различных приложениях, включая логины Windows. По-видимому, в веб-приложениях он встречается гораздо реже. Разве процесс не просто "хэширует входной пароль и сравнивает его с существующим хешем"? Разве это не будет стоить одинаково независимо от того, правильный пароль или нет? В *NIX вы можете убить попытку входа в систему без проблем, так что это на самом деле не является сдерживающим фактором для злоумышленника, совершающего повторные попытки.
2 ответа
Обычно в случае неудачного входа в систему существует случайное время ожидания. Это для предотвращения времени атаки. Если пароль будет храниться без хэширования (или используется слабый метод хеширования), это не позволяет злоумышленнику определить, сколько времени понадобилось системе для сравнения двух строк пароля. Предположим, что правильный пароль будет "abc". Теперь злоумышленник будет многократно пробовать пароли от "a" до "z" и видеть, что для пароля "a" время отказа в регистрации больше, чем для "b" - "z". Это связано с тем, что система должна сравнить два байта ("а" и нулевой байт) с реальным паролем, чтобы понять, что "а" не является правильным паролем. Затем злоумышленник попытается применить "aa" к "az", и он сможет понять, что для "ab" системе требуется больше времени, чтобы понять, что пароль неправильный. Используя этот метод, можно значительно сократить пространство поиска и, следовательно, сократить время, необходимое для подбора пароля. Если вы компенсируете это путем добавления псевдослучайного времени ожидания после сравнения паролей, измерение времени, которое потребовалось системе для сравнения двух паролей, становится более сложным. Тем более, если процесс входа в систему измеряет, сколько времени потребовалось для сравнения паролей, а затем вычесть их из случайного времени ожидания, чтобы предотвратить рисование информации путем обнаружения статистической аномалии. Очевидно, что если пароли хешируются с использованием методов сильного хеширования, для которых не существует радужных таблиц, это становится бессмысленным, поскольку нельзя целенаправленно генерировать пароли с определенным префиксом хеш-функции. Причина, по которой большинство веб-приложений не используют эту технику, заключается либо в том, что HTTP и обычные веб-серверы добавляют так много времени ко времени обработки, что такие атаки по времени становятся неосуществимыми, либо большинству веб-разработчиков просто наплевать;)
Кроме того, это также уменьшает количество возможных попыток ввода пароля для злоумышленника, так как вход в систему должен быть прерван до попытки использования следующего пароля для этого подключения (в случае ssh).
Один большой нарушитель в системе *nix UseDNS в sshd_config когда целевой хост не может получить доступ к DNS-серверу - он будет ожидать истечения времени ожидания разрешения имени, прежде чем идти дальше. Пытаться UseDNS no в sshd_config и посмотрим, улучшится ли это:-)