Чому після введення неправильного пароля виникає велика затримка?

Я помічаю дивну (ну, на мою думку) річ щодо паролів. Наприклад, якщо я введу неправильний пароль під час входу, буде кілька секунд затримки, перш ніж система скаже мені про це. Коли я намагаюся sudoз невірним паролем, мені також доведеться почекати, перш ніж оболонка скаже "Вибачте, спробуйте ще раз".

Цікаво, чому так довго потрібно «розпізнати» неправильний пароль? Це було помічено в декількох дистрибутивах, які я використовую (і навіть OSX), тому я думаю, що це не конкретна річ.

— phunehehe
джерело

Я помітив це не тільки в терміналі, але і при первинному вході в сеанс після запуску або коли ноутбук знаходиться в режимі сну. Розблокування правильного пароля моментально, проте, радий, що це питання порушено :)

— krozaine

Відповіді:

Це справа безпеки, адже насправді це не потрібно багато часу, щоб усвідомити це. Це вирішує дві вразливості:

ця спроба входу в систему дроселів означає, що хтось не може збити систему так швидко, як може спробувати зламати її (1М спроби в секунду? Не знаю).
Якщо це було зроблено, як тільки він перевірив, що ваші облікові дані були невірними, ви можете використати кількість часу, яке знадобилося для того, щоб визнати недійсними ваші облікові дані, щоб допомогти здогадатися, чи частина ваших облікових даних була правильною, різко скоротивши час здогадок.

щоб запобігти цим двом речам, система вимагає певного часу, щоб зробити це, я думаю, ви можете налаштувати час очікування за допомогою PAM ( див. відповідь Майкласа ).

Техніка безпеки ( 2ed, amazon | 1ed, безкоштовно ) дає набагато краще пояснення цих проблем.

— ксенотерацид
джерело

// offtopic g його не помилка, її особливість ;-)

— echox

Ваше партнерське посилання було автоматично переписано на SE, btw.

— Желатин

@Thepang: Див. Розділ 2 , особливо §2.4 та §2.5.3.3.

— Жиль

Різниця між ранньою та пізньою відмовою при порівнянні хешу пароля вимірюється в наносекундах. При правильному кодуванні (постійне порівняння часу в пам'яті) різниці взагалі немає. Це не виправдання для додавання затримки.

— CodesInChaos

Я згоден з CodesInChaos: Другий пункт відповіді невірний. Насправді відбувається наступне: 1. обчислюється хеш вашого введення; 2. що хеш порівнюється із збереженим хешем (кожен байт його, навіть якщо різниця вже знайдена); Зауважте, що ці два кроки ні в якому разі не швидші чи повільніші залежно від того, чи був ви введений пароль правильним. (і як уже вказували інші, додавання тривалості сну не зафіксувало б атаку часу, якщо це можливо)

— приклад

Це навмисно, щоб спробувати обмежити грубе насильство. Зазвичай ви можете модифікувати його, шукаючи FAIL_DELAYзапис конфігурації /etc/login.defsта змінюючи його значення (моє значення 3за замовчуванням секунд), хоча коментар у цьому файлі дозволяє звучати, як PAM примусить принаймні 2секунди затримки незалежно від того, що

— Михайло Мрозек
джерело

Це для того, щоб запобігти більш ніж просто насильницькі дії. але бонусні бали за те, що знати, де його налаштувати.

— ксенотерацид

Я думаю, що fail_delay також налаштовується в /etc/pam.d/login. Шукайтеpam_faildelay.so delay=

— Стівен Д

що заважає вам написати обгортку для sudo, яка запускає новий екземпляр sudo, коли спроба не спрацює, скажімо, за 0,1 секунди?

— Янус Троельсен

У сучасних системах Linux причиною є те, що pam_unix.so накладає таку затримку. Як повідомлялося раніше, це може бути налаштоване до двох секунд, змінюючи FAIL_DELAYв /etc/login.defs. Якщо ви хочете додатково зменшити затримку, вам слід надати pam_unix.so опцію "nodelay". Наприклад, у моїй системі, якщо ви відстежуєте включення, починаючи з /etc/pam.d/sudo, ви виявите, що ви повинні відредагувати наступний рядок /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

і змініть це на це:

auth      required  pam_unix.so     try_first_pass nullok nodelay

На жаль, те, як мій дистрибутив (арка) Linux налаштовує речі, system-authвходить той самий файл system-remote-login, який використовує sshd.

Хоча безпечно усунути затримку на sudo, тому що це зареєстровано, використовується лише місцевими користувачами, а локальними зловмисниками так чи інакше обійти, ви, мабуть, не хочете усунути цю затримку для віддалених входів. Звичайно, ви можете це виправити, написавши користувальницьке sudo, яке не включає лише спільні файли-автори системи.

Особисто я вважаю, що затримка судо (і ігнорування SIGINT) є великою помилкою. Це означає, що користувачі, які знають, що вони неправильно ввели пароль, не можуть вбити процес і зірватися. Звичайно, ви все одно можете зупинити судо за допомогою Ctrl-Z, оскільки судо не вловлює SIGTSTP, а після його припинення ви можете вбити його з kill -9 (SIGKILL). Це просто прикро робити. Тож це означає, що автоматизована атака може вистрілити судів на псевдо-терміналах із надзвичайно високою швидкістю. Але затримка відлякує законних користувачів і спонукає їх призупинити їх кореневі оболонки замість того, щоб виходити з них, щоб уникнути необхідності знову судо.

— користувач3188445
джерело

Те саме з Федорою. Дивовижний аналіз

— Freedom_Ben

Блискуча відповідь. Я також думав, що FAIL_DELAY застаріло в сучасних робочих системах. Вам слід покладатися на шифрування розділів / жорстких дисків і нічого іншого. Зазвичай не існує другого користувача, який міг би спробувати виправити пароль root. Однак потенційно шкідливі програми можуть зловживати небезпечним FAIL_DELAY і таким чином отримати кореневий доступ.

— phil294

встановивши pam-unix nodelay, встановить час очікування до 0, а FAIL_DELAY ігнорується.

— phil294

Чому б не відключити затримку, а потім відключити віддалений вхід пароля (лише для SSH)? Чи не вирішує це проблему, не вводячи жодної вразливості безпеки?

— Радон Росборо