パスワード認証が抱える根本的な問題

従来のパスワード認証では、クライアントがパスワード（またはそのハッシュ）をサーバーに送信し、サーバーが保存された値と比較します。このモデルは単純ですが、サーバーに非常に大きなリスクが集中します。データベースが侵害されると、すべてのユーザーの認証情報が同時に漏えいします。

攻撃者がサーバーに侵入してパスワードデータベースを盗むと、レート制限なしでGPUの性能を最大限に利用したオフライン辞書攻撃を実行できます。最新のGPUは、bcryptやSHA-256のハッシュに対して毎秒数十億ものパスワード候補を試せるため、弱いパスワードやよく使われるパスワードは簡単に復元されてしまいます。

調査では一貫して、多数のユーザーが複数のサイトでパスワードを再利用していることが示されています。そのため、1つのサーバーが侵害されるだけで、他のサービスでも使える認証情報が漏えいします。Credential stuffing攻撃では、漏えいしたユーザー名とパスワードの組み合わせを人気のウェブサイトで自動的に試行し、1件の侵害を多数の被害へと拡大させます。

サーバー側でパスワードを強化しても（強力なハッシュ化、ソルト付与、レート制限など）、フィッシングに対する防御にはなりません。ユーザーが偽サイトにパスワードを入力すると、正規サーバーがどれほど適切にパスワードを保存していても、攻撃者は平文のパスワードを直接入手できます。現在、フィッシングは認証情報窃取の主流の手段です。

過去の情報漏えいで流出した、数十億件に及ぶユーザー名とパスワードの組み合わせが、ダークウェブ上で公開されています。攻撃者は自動化ツールを使い、これらの認証情報を金融機関、ECサイト、メールプロバイダーなどに対して大規模に試します。ユーザーが以前流出したパスワードを再利用している場合は、認証に成功します。

従来のパスワード認証では、ログイン処理中にサーバーがユーザーの平文パスワードを必ず知ることになります（ハッシュ化する前の、ほんの短い間だけであっても同様です）。そのため、すべてのサーバー運用者を、認証情報を悪用、記録、または誤って漏えいさせない存在として完全に信頼する必要があります。しかし、実際にはそれが保証されることはほとんどありません。

理想的な認証プロトコルでは、ユーザーはパスワードをサーバーに一切明かさずに、パスワードを知っていることを証明できます。さらにサーバー自身も正規のサーバーであることを証明します（相互認証）。これによりフィッシングを防止できます。サーバーのデータベースが侵害されても、攻撃者にとって役立つ情報は何も明らかになりません。

ゼロ知識証明は、この仕組みの理論的な枠組みを提供します。証明者は、秘密そのものを明かさずに、その秘密が正しいことを検証者に納得させられます。SRPやOPAQUEなどのパスワード認証プロトコルは、これらの原理を適用し、パスワードを直接送信したりサーバー側に保存したりせずに認証を実現します。

強力なパスワード認証プロトコルは、サーバーに保存されたデータが完全に侵害されても、オフライン辞書攻撃に耐えられる必要があります。つまり、保存された検証値をそのまま使ってユーザーになりすますことができず、サーバーの協力なしには効率的なオフラインパスワード推測もできない必要があります。

認証を必要とするサービスが何百もある場合、従来のモデルでは、他の場所でも再利用される可能性がある秘密情報を、すべてのサービス運用者に預けて信頼する必要があります。解決策は、パスワードの送信を完全になくし、再利用できない検証値だけを保存し、認証を特定のサーバーの識別情報に結び付けてフィッシングを防止することです。

現代的な解決策には、SRP（Secure Remote Password）、OPAQUE、FIDO2／パスキーなどがあります。それぞれが、この根本的な問題の異なる側面に対処します。SRPとOPAQUEは、サーバーがパスワードを知る必要をなくします。FIDO2／パスキーは、特定のオリジンに結び付いた公開鍵暗号を使い、パスワード自体を不要にします。

強力なサーバー側パスワードハッシュ（bcryptなど）で防止できない攻撃はどれですか？

従来のパスワード認証では、サーバーが知っている秘密情報を検証する必要があり、情報漏えい後にはオフラインでのクラッキングが可能になり、フィッシングにも弱いという問題があります。パスワードの再利用は、個別の情報漏えいをシステム全体の障害へと発展させます。理想的なシステムでは、秘密情報を送信せずに相互認証を行い、解読できない検証値だけを保存し、認証をサーバーの識別情報に結び付けます。