間違ったパスワードを入力した後に大きな遅延があるのはなぜですか？

パスワードに関する奇妙な（私によると）ことに気づきました。たとえば、ログイン中に間違ったパスワードを入力した場合、システムから通知されるまで数秒の遅延が発生します。sudo間違ったパスワードを使用しようとすると、シェルが「Sorry、try again」と言うまで待つ必要があります。

なぜ間違ったパスワードを「認識する」のにそんなに時間がかかるのだろうか？これは私が使用しているいくつかのディストリビューション（およびOSXでも）で見られているため、ディストリビューション固有のものではないと思います。

これはセキュリティの問題であり、実際に実現するのにそれほど時間はかかりません。これにより解決される2つの脆弱性：

1. これはログイン試行を抑制します。つまり、システムがクラッキングしようとするほど速くシステムを叩くことができません（1秒間に100万回試行されますか？わかりません）。

2. 資格情報が間違っていることを確認したらすぐにそれを行った場合、資格情報を無効にするためにかかった時間を使用して、資格情報の一部が正しいかどうかを推測し、推測時間を劇的に短縮できます。

これらの2つのことを防ぐために、システムがそれを行うのに一定の時間を要するだけで、PAMで待機時間を構成できると思います（Michaelsの回答を参照）。

セキュリティエンジニアリング（2ed、amazon | 1ed、無料）は、これらの問題のより良い説明を提供します。

これは、総当たり攻撃を制限するための意図的なものです。通常、FAIL_DELAY設定エントリを探し/etc/login.defsて値を変更することで変更できます（3デフォルトは秒です）が、ファイル内のコメントは、PAMが少なくとも1 2秒の遅延を強制するように聞こえます

最新のLinuxシステムでは、その理由はpam_unix.soがこのような遅延を課しているためです。既報の通り、これは変更することにより、2秒まで設定することができます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ディストリビューション（arch）が設定する方法は、sshdによって使用さsystem-authれるまったく同じファイルがに含まれますsystem-remote-login。

sudoの遅延はログに記録され、ローカルユーザーのみが使用し、とにかくローカルの攻撃者がバイパスできるため、sudoの遅延を削除しても安全ですが、リモートログインの場合はこの遅延を削除したくないでしょう。もちろん、共有されたsystem-authファイルだけを含まないカスタムsudoを書くことで修正できます。

個人的には、sudoの遅延（およびSIGINTの無視）は大きな間違いだと思います。パスワードを誤って入力したことを知っているユーザーは、プロセスを強制終了できず、イライラすることはありません。もちろん、sudoはSIGTSTPをキャッチしないため、Ctrl-Zでsudoを停止できます。停止後、kill -9（SIGKILL）でkillできます。やるのは面倒です。そのため、自動化された攻撃は、擬似端末のsudoを非常に高いレートで発射できます。しかし、この遅延は正当なユーザーを苛立たせ、ルートシェルを終了するのではなく、ルートシェルを一時停止して、再びsudoを行わないようにすることを奨励します。