間違ったパスワードを入力すると、なぜ大幅に遅れるのですか？
私はパスワードについて奇妙な（まあ、私によれば）事柄に気づきました。たとえば、ログイン中に間違ったパスワードを入力した場合、システムから通知されるまでに数秒の遅延があります。間違ったパスワードでSudoを試そうとすると、シェルが「申し訳ありませんが、もう一度試してください」と言うまで待つ必要があります。
なぜ間違ったパスワードを「認識する」のに時間がかかるのでしょうか。これは私が使用するいくつかのディストリビューション（OSXでさえも）で見られたので、それはディストリビューション固有のものではないと思います。
これはセキュリティ上の問題であり、実際に実現するのにそれほど時間はかかりません。これが解決する2つの脆弱性：
これはログイン試行を抑制します。つまり、誰かがシステムをクラックしようとするのと同じ速さでシステムを叩くことはできません（1Mは1秒間に試行しますか？わかりません）。
資格情報が正しくないことが確認された直後にそれが行われた場合は、資格情報を無効にするのにかかった時間を使用して、資格情報の一部が正しいかどうかを推測し、推測時間を大幅に短縮できます。
これらの2つのことを防ぐために、システムが実行するのにある程度の時間がかかるだけですが、PAMで待機時間を構成できると思います（ Michaelsの回答を参照 ）。
セキュリティエンジニアリング（ 2ed、Amazon | 1ed、free ）は、これらの問題についてより良い説明を提供します。
これは、ブルートフォースを制限しようとする意図的なものです。通常は、FAIL_DELAYの/etc/login.defs構成エントリを探してその値を変更することで変更できます（デフォルトでは3秒です）。そのファイルのコメントはPAMのように聞こえます何があっても少なくとも2秒の遅延を強制します
最近のLinuxシステムでは、その理由はpam_unix.soがそのような遅延を課しているためです。以前に報告されたように、これはFAIL_DELAYの/etc/login.defsを変更することで2秒まで設定できます。遅延をさらに減らしたい場合は、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）でSudoを終了できます。それはやっかいなことです。つまり、自動化された攻撃は、疑似端末のsudoを超高速で発射する可能性があります。しかし、この遅延は正当なユーザーを苛立たせ、Sudoを再度実行する必要を回避するために、終了するのではなくルートシェルを一時停止することを奨励しています。