Почему проверка неправильного пароля должна занимать больше времени, чем проверка правильного?

Этот вопрос меня всегда волновал.

В Linux при запросе пароля, если вы введете правильный пароль, он проверяет сразу, почти без задержки. Но, с другой стороны, если вы введете неправильный пароль, проверка займет больше времени. Это почему?

Я наблюдал это во всех дистрибутивах Linux, которые когда-либо пробовал.

На самом деле это сделано для предотвращения попыток перебора миллионов паролей в секунду. Идея состоит в том, чтобы ограничить скорость проверки паролей, и существует ряд правил, которые следует соблюдать.

• Успешная пара пользователь / пароль должна быть успешной немедленно.
• Там должно быть не различима разница в причинах отказа , которые могут быть обнаружены.

Последнее особенно важно. Это означает, что никаких полезных сообщений вроде:

Your user name is correct but your password is wrong, please try again

или же:

Sorry, password wasn't long enough

Нет даже разницы во времени в ответе между причинами отказа «неверный пользователь и пароль» и «действительный пользователь, но неверный пароль».

Каждый сбой должен предоставлять точно такую ​​же информацию, текстовую или другую.

Некоторые системы идут еще дальше, увеличивая задержку при каждом сбое или допуская только три сбоя, а затем с большой задержкой перед разрешением повторной попытки.

Это заставляет угадывать пароли дольше.

Я не уверен, но довольно часто можно интегрировать задержку после ввода неправильного пароля, чтобы усложнить атаки. Это делает атаку практически невозможной, потому что вам потребуется много времени, чтобы проверить всего несколько паролей.

Даже попытка ввести несколько паролей - даты рождения, имя кота и тому подобное - превращается в никуда.

В основном для защиты от грубой силы и словарных атак.

Из Руководства разработчика приложений Linux-PAM :

Планирование задержек

extern int pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec);

Эта функция предлагается Linux-PAM для облегчения задержек по времени после неудачного вызова pam_authenticate () и до того, как управление будет возвращено приложению. При использовании этой функции прикладной программист должен проверить, доступна ли она с помощью,

#ifdef PAM_FAIL_DELAY
    ....
#endif /* PAM_FAIL_DELAY */

Как правило, приложение запрашивает аутентификацию пользователя с помощью Linux-PAM посредством вызова pam_authenticate () или pam_chauthtok (). Эти функции вызывают каждый из составных модулей аутентификации, перечисленных в соответствующем файле конфигурации Linux-PAM. В соответствии с указаниями этого файла один или несколько модулей могут выйти из строя, в результате чего вызов pam _... () вернет ошибку. Желательно, чтобы также была пауза перед продолжением приложения. Основная причина такой задержки - безопасность: задержка в первую очередь препятствует атакам по словарю методом грубой силы, но также помогает предотвратить атаки по таймеру (по скрытому каналу).

Это очень простой, практически не требующий усилий способ значительно повысить безопасность. Рассматривать:

1. Система Aне имеет задержки. У злоумышленника есть программа, которая создает комбинации имени пользователя и пароля. При скорости тысяч попыток в минуту требуется всего несколько часов, чтобы попробовать каждую комбинацию и записать все успешные входы в систему.

2. Система Bгенерирует 5-секундную задержку после каждого неверного предположения. Эффективность атакующего была снижена до 12 попыток в минуту, что эффективно препятствует атаке методом грубой силы. Чтобы найти действительный логин, вместо часов могут потребоваться месяцы. Если бы хакеры были такими терпеливыми, они бы стали законными. :-)

Задержки неудачной аутентификации уменьшают количество попыток входа в систему. Идея о том, что если кто-то пытается использовать словарь или грубую силу для одной или нескольких учетных записей пользователей, злоумышленнику потребуется дождаться задержки сбоя и, таким образом, вынудить его потратить больше времени и дать вам больше шансов обнаружить его.

Вам также может быть интересно узнать, что в зависимости от того, что вы используете в качестве оболочки входа в систему, обычно есть способ настроить эту задержку.

В GDM задержка устанавливается в файле gdm.conf (обычно в /etc/gdm/gdm.conf). вам нужно установить RetryDelay = x, где x - значение в секундах.

Большинство дистрибутивов Linux в наши дни также поддерживают определение FAIL_DELAY в /etc/login.defs, что позволяет вам установить время ожидания после неудачной попытки входа в систему.

Наконец, PAM также позволяет вам установить атрибут nodelay в вашей строке auth, чтобы обойти задержку сбоя. ( Вот статья о PAM и Linux )

Я не думаю, что это может быть так просто, как предполагают ответы.

Если ответ на правильный пароль (какое-то значение) происходит немедленно, разве вам не нужно просто ждать дольше этого значения, чтобы узнать, что пароль неправильный? (по крайней мере, вероятностно знать, что подходит для взлома) И в любом случае вы бы запускали эту атаку параллельно ... это все один большой приветственный коврик DoS?

То, что я пробовал раньше, казалось, сработало, но на самом деле нет; если вам не все равно, вы должны просмотреть историю редактирования вики ...

Что делает работу (для меня) в том, чтобы как снизить значение задержки pam_faildelay.so = Х в файле /etc/pam.d/login (я опустил его на 500000, половина второго), а также добавить NODELAY (а предшествует пробел) до конца строки в common-auth , как описано Габриэлем в его ответе.

auth [success=1 default=ignore] pam_unix.so nullok_secure nodelay

По крайней мере, для меня (debian sid), только одно из этих изменений не сократит задержку значительно ниже 3 секунд по умолчанию, хотя можно увеличить задержку, изменив только значение в /etc/pam.d/login.

Такой хрени хватит, чтобы взрослый мужчина плакал!

В Ubuntu 9.10 и, я думаю, в новых версиях файл, который вы ищете, находится в

/etc/pam.d/login

отредактируйте строку:

auth необязательный pam_faildelay.so delay = 3000000

замените число 3 на другое, которое вы можете захотеть.

Обратите внимание, что для аутентификации 'nodelay', Я ДУМАЮ, вы должны отредактировать файл

/etc/pam.d/common-auth

тоже. На линии:

auth [успех = 1 по умолчанию = игнорировать] pam_unix.so nullok_secure

в финал добавить 'nodelay' (без кавычек). Но это последнее объяснение по поводу «нодлея» - вот что я думаю.

Я хотел бы добавить примечание с точки зрения разработчиков. Хотя это не будет очевидно невооруженным глазом, умный разработчик прервет запрос на совпадение, когда совпадение будет найдено. По сути, успешный матч завершится быстрее, чем неудачный. Потому что функция сопоставления будет сравнивать учетные данные со всеми известными учетными записями, пока не найдет правильное совпадение. Другими словами, предположим, что имеется 1 000 000 учетных записей пользователей, упорядоченных по идентификаторам; 001, 002, 003 и так далее. Ваш идентификатор - 43 001. Итак, когда вы вводите правильное имя пользователя и пароль, сканирование останавливается на 43 001 и выполняет вход в систему. Если ваши учетные данные неверны, сканирование выполняется для всех 1 000 000 записей. Разница во времени обработки на двухъядерном сервере может составлять миллисекунды. В Windows Vista с 5 учетными записями пользователей это будет в наносекундах.

Я согласен. Это произвольное программное решение. Установка задержки на одну секунду вместо трех на самом деле не повредит взлому пароля, но сделает его более удобным для пользователя.

Технически, эта преднамеренная задержка предназначена для предотвращения атак, подобных «атаке линеаризации» (есть и другие атаки и причины) .

Чтобы проиллюстрировать атаку, рассмотрим программу (без этой преднамеренной задержки), которая проверяет введенный серийный номер, чтобы увидеть, соответствует ли он правильному серийному номеру , которым в данном случае оказывается « xyba » . Для эффективности программист решил проверять по одному символу за раз и выйти, как только будет обнаружен неправильный символ, перед началом также проверяется длина.

Обработка правильной серийной длины займет больше времени, чем неправильная серийная длина. Еще лучше (для злоумышленника), серийный номер с правильным первым символом займет больше времени, чем серийный номер с неправильным первым символом. Последовательные шаги во времени ожидания обусловлены тем, что каждый раз, когда возникает еще один цикл, сравнение выполняется при правильном вводе.

• Таким образом, злоумышленник может выбрать строку из четырех символов , причем строка, начинающаяся с x, занимает больше всего времени. (по предположениям)
• Затем злоумышленник может зафиксировать символ как x и изменить второй символ, и в этом случае он обнаружит, что y занимает больше всего времени.
• Затем злоумышленник может исправить первые два символа как xy и изменить третий символ, и в этом случае он обнаружит, что b занимает больше всего времени.
• Затем злоумышленник может исправить первые три символа как xyb и изменить четвертый символ, и в этом случае они обнаружат, что a занимает больше всего времени.

Следовательно, злоумышленники могут восстановить серийный номер по одному символу за раз.

Linearization.java.

Linearization.docx, пример вывода

Серийный номер состоит из четырех символов, и каждый символ имеет 128 возможных значений. Тогда существует 128 ⁴ = 2 ²⁸ = 268 435 456 возможных серийных номеров . Если злоумышленник должен случайным образом угадать полные серийные номера, он угадывает серийный номер примерно за 2 ²⁷ = 134 217 728 попыток, что является огромным объемом работы . С другой стороны, с помощью линеаризации атаки выше, в средней только 128/2 = 64 догадок требуется для каждой буквы, на общую ожидаемую работу около 4 * 64 = 2 ⁸ = 256 догадок, который представляет собой тривиальное количество работы.

Большая часть письменного боевого искусства адаптирована из этого (взято из книги Марка Стэмпа «Информационная безопасность: принципы и практика»). Кроме того, приведенные выше расчеты не учитывают количество предположений, необходимых для определения правильной серийной длины.