Mengapa ada penundaan besar setelah memasukkan kata sandi yang salah?

Saya perhatikan hal aneh (well, menurut saya) tentang kata sandi. Misalnya, jika saya mengetikkan kata sandi yang salah saat login, akan ada penundaan beberapa detik sebelum sistem memberi tahu saya demikian. Ketika saya mencoba sudodengan kata sandi yang salah, saya juga harus menunggu sebelum shell mengatakan "Maaf, coba lagi".

Saya heran mengapa perlu waktu lama untuk "mengenali" kata sandi yang salah? Ini telah terlihat pada beberapa distribusi yang saya gunakan (dan bahkan OSX), jadi saya pikir itu bukan distribusi yang spesifik.

— phhehehe
sumber

Saya perhatikan ini tidak hanya di terminal tetapi juga pada login sesi awal setelah startup atau ketika laptop dalam mode tidur. Membuka kunci kata sandi yang tepat adalah instan, senang melihat pertanyaan ini muncul :)

— krozaine

Jawaban:

Ini adalah masalah keamanan, sebenarnya tidak butuh waktu lama untuk menyadarinya. 2 kerentanan yang dipecahkan ini:

ini menghambat upaya masuk, yang berarti seseorang tidak dapat menggebrak sistem secepat itu bisa mencoba memecahkannya (1M mencoba sebentar? Saya tidak tahu).
Jika melakukannya segera setelah itu memverifikasi kredensial Anda salah, Anda dapat menggunakan jumlah waktu yang diperlukan untuk membatalkan kredensial Anda untuk membantu menebak jika bagian dari kredensial Anda benar, secara dramatis mengurangi waktu tebakan.

untuk mencegah 2 hal ini, sistem hanya perlu waktu untuk melakukannya, saya pikir Anda dapat mengkonfigurasi waktu tunggu dengan PAM ( Lihat jawaban Michaels ).

Rekayasa Keamanan ( 2ed, amazon | 1ed, gratis ) memberikan penjelasan yang jauh lebih baik tentang masalah ini.

— xenoterracide
sumber

// offtopic g ini bukan bug, ini fitur ;-)

— echox

Tautan afiliasi Anda secara otomatis ditulis ulang menjadi SE, btw.

— Gelatin

@Tepang, lihat bab 2 , khususnya §2.4 dan §2.5.3.3.

— Gilles

Perbedaan antara kegagalan awal dan akhir saat membandingkan hash kata sandi diukur dalam nanodetik. Dengan pengkodean yang tepat (perbandingan memori waktu konstan) tidak ada perbedaan sama sekali. Itu bukan alasan untuk menambahkan penundaan.

— CodesInChaos

Saya setuju dengan CodesInChaos: Poin kedua jawabannya salah. Apa yang sebenarnya terjadi adalah sebagai berikut: 1. hash input Anda dihitung; 2. hash itu dibandingkan dengan hash yang disimpan (setiap byte dari itu, bahkan jika perbedaan sudah ditemukan); Perhatikan, bahwa kedua langkah ini sama sekali tidak lebih cepat atau lebih lambat tergantung pada apakah kata sandi yang Anda masukkan benar. (dan seperti yang telah ditunjukkan oleh orang lain, menambahkan durasi tidur tidak akan memperbaiki serangan waktu jika memungkinkan)

— contoh

Ini disengaja, untuk mencoba dan membatasi kekerasan. Anda biasanya dapat memodifikasinya dengan mencari FAIL_DELAYentri konfigurasi /etc/login.defsdan mengubah nilainya (milik saya adalah 3detik secara default), meskipun komentar dalam file tersebut membuatnya terdengar seperti PAM akan memberlakukan setidaknya 2penundaan kedua tidak peduli apa pun yang terjadi.

— Michael Mrozek
sumber

Ini untuk mencegah lebih dari sekadar kekerasan. tetapi poin bonus untuk mengetahui di mana mengkonfigurasinya.

— xenoterracide

Saya pikir fail_delay juga dapat dikonfigurasi di /etc/pam.d/login. Carilahpam_faildelay.so delay=

— Steven D

apa yang mencegah Anda dari menulis pembungkus untuk sudo yang memulai contoh sudo baru setelah upaya tidak berhasil di dalam, katakanlah, 0,1 detik?

— Janus Troelsen

Pada sistem linux modern, alasannya adalah pam_unix.so memaksakan penundaan seperti itu. Seperti dilaporkan sebelumnya, ini dapat dikonfigurasi ke dua detik dengan mengubah FAIL_DELAYdi /etc/login.defs. Jika Anda ingin mengurangi penundaan lebih lanjut, Anda harus memberikan pam_unix.so opsi "nodelay". Misalnya, pada sistem saya, jika Anda melacak menyertakan mulai dari /etc/pam.d/sudo, Anda harus mengedit baris berikut /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

dan ubah ke ini:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Sayangnya, cara distro linux saya (arch) mengkonfigurasi hal-hal, system-authfile yang sama akan dimasukkan oleh system-remote-login, yang digunakan oleh sshd.

Meskipun aman untuk menghilangkan penundaan pada sudo, karena itu dicatat, hanya digunakan oleh pengguna lokal, dan bisa dilewati oleh penyerang lokal, Anda mungkin tidak ingin menghilangkan penundaan ini untuk login jarak jauh. Tentu saja Anda dapat memperbaikinya dengan menulis sudo khusus yang tidak hanya menyertakan file auth sistem bersama.

Secara pribadi, saya pikir keterlambatan pada sudo (dan mengabaikan SIGINT) adalah kesalahan besar. Ini berarti pengguna yang tahu bahwa mereka salah mengetik kata sandi tidak dapat menghentikan proses dan menjadi frustrasi. Tentu saja, Anda masih dapat menghentikan sudo dengan Ctrl-Z, karena sudo tidak menangkap SIGTSTP, dan setelah menghentikannya Anda dapat membunuhnya dengan kill -9 (SIGKILL). Itu hanya menjengkelkan untuk dilakukan. Jadi itu berarti serangan otomatis dapat menembakkan sudo pada terminal semu dengan kecepatan super tinggi. Tetapi penundaan itu membuat frustasi pengguna yang sah dan mendorong mereka untuk menangguhkan shell root mereka alih-alih keluar dari mereka untuk menghindari keharusan sudo lagi.

— pengguna3188445
sumber

Sama dengan Fedora. Analisis yang luar biasa

— Freedom_Ben

Jawaban yang brilian Saya juga berpikir FAIL_DELAY telah menjadi usang dalam sistem Desktop modern. Anda harus mengandalkan enkripsi partisi / hard drive dan tidak ada yang lain. Biasanya, tidak ada pengguna kedua yang mungkin mencoba brute force root password. Namun , program yang berpotensi berbahaya dapat menyalahgunakan FAIL_DELAY yang tidak aman dan karenanya mendapatkan akses root.

— phil294

mengatur pam-unix ke nodelayakan mengatur waktu tunggu ke 0 dengan cara, dan FAIL_DELAY kemudian diabaikan.

— phil294

Mengapa tidak menonaktifkan penundaan, dan kemudian menonaktifkan login kata sandi jarak jauh (hanya SSH)? Bukankah itu menyelesaikan masalah tanpa memperkenalkan kerentanan keamanan?

— Radon Rosborough