OWASP チートシートシリーズ日本語版（非公式）

一覧 / 認証

認証

Authentication Cheat Sheet

原典
Authentication Cheat Sheet（OWASP Cheat Sheet Series）
原文
GitHub 上の Markdown
底本
bac04fb5（2026-07-29 時点）
ライセンス
CC BY-SA 4.0（原典と同一。訳文も同ライセンスで再配布できます）

はじめに

認証（AuthN）は、個人、実体、Web サイトが、自ら主張するとおりのものであることを、その主張を裏付ける一つ以上の認証手段（パスワード、指紋、セキュリティトークンなど）の正当性を判定することによって確かめる処理である。

デジタルアイデンティティは、オンラインの取引に関与する主体の一意な表現である。 デジタルアイデンティティは、あるデジタルサービスの文脈においては常に一意であるが、現実の特定の主体まで辿れる必要は必ずしもない。

身元確認（Identity Proofing）は、主体が実際に自ら主張するとおりの者であることを確立する。 この概念は KYC の考え方と関係し、デジタルアイデンティティを実在の人物に結びつけることを目的とする。

セッション管理は、サーバーが自身と対話する実体の状態を保つ処理である。 これは、取引の全体を通じてその後のリクエストにどう応じるかをサーバーが覚えておくために必要になる。 セッションはサーバー側でセッション識別子によって保たれ、この識別子はリクエストの送受信の際にクライアントとサーバーのあいだで受け渡される。 セッションは利用者ごとに一意であり、計算上きわめて予測しにくいものであるべきである。 この領域の最良の慣行についてさらに詳しくはセッション管理を参照する。

認証の一般的な指針

ユーザー ID

ユーザー ID の主要な役割は、システム内で利用者を一意に識別することである。 ユーザー ID は、予測可能なものや連番になるものを避けるため、ランダムに生成するのが理想である。 そうしたものはセキュリティ上のリスクになりうる。 ユーザー ID が露出しうる、あるいは外部の情報源から推測されうるシステムではとくにそうである。

ユーザー名

ユーザー名は、利用者が自ら選び、システムやサービスへのログイン時に自分を識別するために使う、覚えやすい識別子である。 利用者が選んだユーザー名がシステム内の一意な識別子も兼ねる場合、ユーザー ID とユーザー名は同じ意味で使われることがある。

登録時にメールアドレスが検証されるのであれば、利用者にはメールアドレスをユーザー名として使うことを許すべきである。 加えて、メールアドレス以外のユーザー名を選ぶ選択肢も与えるべきである。 メールアドレスの検証については入力値の検証のメールアドレスの節を参照する。

認証の仕組みと機微なアカウント

  • 機微なアカウント（バックエンド、ミドルウェア、データベースなど、システム内部で使われるアカウント）でのログインを、フロントエンドのユーザーインタフェースに対して許してはならない
  • 内部で使う認証の仕組み（IDP、AD など）を、保護されていないアクセス（公開アクセス、DMZ など）に使ってはならない

適切なパスワード強度の対策を実装する

認証にパスワードを使う際の主要な懸念はパスワードの強度である。 「強い」パスワードの方針は、手作業でも自動でもパスワードを推測することを困難、あるいはほぼ不可能にする。 強いパスワードを定めるのは次の性質である。

  • パスワードの長さ
    • パスワードの最小長はアプリケーションが強制するべきである。
      • MFA が有効な場合、8 文字未満のパスワードは弱いとみなされる（NIST SP800-63B）。
      • MFA が有効でない場合、15 文字未満のパスワードは弱いとみなされる（NIST SP800-63B）。
    • パスワードの最大長は、パスフレーズを許容するために少なくとも 64 文字にするべきである（NIST SP800-63B）。ハッシュアルゴリズムの実装によっては長いパスワードによるサービス妨害が生じうることに注意する。
    • 長いパスフレーズが有効なのは、正確なエントロピーの値によるのではなく、攻撃者の辞書や単語リストが網羅しなければならない推測の数を増やすからである。NIST は「利用者が選んだパスワードのエントロピーの推定は困難である」と述べ、文字種の構成やエントロピーの計算よりも、長さと拒否リストの確認（後述）を推奨している（NIST SP800-63B, Strength of Passwords）。エントロピーのビット数を強度の保証として利用者に示すことは避ける。
  • パスワードを黙って切り捨ててはならない。最大長を超えるパスワードの扱いについてはパスワードの保存を参照する。
  • Unicode と空白を含むすべての文字の使用を許可する。使える文字の種類を制限するパスワードの構成規則を設けるべきではない。大文字、小文字、数字、記号を必須にするべきではない。
  • パスワードの漏洩が起きたとき、侵害を把握した時点、あるいは認証手段の技術が変わったときに、資格情報のローテーションを行う。定期的なパスワード変更を要求することは避ける。代わりに強いパスワードを選ぶよう促し、多要素認証（MFA）を有効にする。NIST の指針によれば、検証側は恣意的な（定期的な、など）パスワード変更を強制するべきではない。
  • 利用者がより複雑なパスワードを作れるよう、パスワード強度メーターを設ける
  • よく使われるパスワードと過去に漏洩したパスワードを遮断する
    • Pwned Passwords は、過去に漏洩したパスワードと照合できるサービスである。API の詳細はこちらにある。
    • あるいは Pwned Passwords のデータベースをこの仕組みで入手し、自前で運用することもできる。
    • 他にもよく使われるパスワードの一覧はあるが、どれだけ更新されているかは保証されない。

さらに詳しい情報

安全なパスワード復旧の仕組みを実装する

パスワードを忘れた場合に利用者がアカウントへアクセスできる手段を、アプリケーションが備えているのは一般的である。 この機能の詳細はパスワードの再設定を参照する。

パスワードを安全な方法で保存する

適切な暗号技術を用いてパスワードを保存することは決定的に重要である。 この機能の詳細はパスワードの保存を参照する。

安全な関数でパスワードのハッシュを比較する

可能であれば、利用者が入力したパスワードと保存されたパスワードのハッシュの比較には、言語やフレームワークが提供する安全なパスワード比較関数（PHP の password_verify() など）を使うべきである。 それが不可能な場合は、比較関数が次を満たす状態にする。

  • 入力長の上限を持つ。非常に長い入力によるサービス妨害攻撃から守るためである。
  • 両方の変数の型を明示的に設定する。PHP の Magic Hashes のような型の混同を突く攻撃から守るためである。
  • 一定時間で返る。タイミング攻撃から守るためである。

パスワード変更の機能

パスワード変更の機能を開発するときは、次を満たすようにする。

  • 利用者が有効なセッションで認証されている。
  • 現在のパスワードの確認を行う。これは、パスワードを変更しているのが正当な利用者であることを確かめるためである。次の悪用の場面を考える。利用者が公共のコンピュータでログインし、ログアウトを忘れる。別の人がその有効なセッションを使えてしまう。現在のパスワードを確認しなければ、その別人がパスワードを変更できてしまう。

パスワードは TLS などの強固な通信路のみで送る

トランスポート層セキュリティを参照する。

ログインページと、その後の認証済みのページはすべて、TLS などの強固な通信路のみを通じてアクセスされなければならない。 ログインページで TLS などの強固な通信路を使わないと、攻撃者がログインフォームの action を書き換え、利用者の資格情報を任意の場所へ送らせることができる。 ログイン後の認証済みのページで使わないと、攻撃者が暗号化されていないセッション ID を見て、利用者の認証済みセッションを奪うことができる。

機微な機能では再認証を要求する

CSRF とセッションの乗っ取りを緩和するには、利用者のパスワードやメールアドレスのような機微なアカウント情報を更新する前、あるいは購入品を新しい住所へ送るような機微な取引の前に、そのアカウントの現在の資格情報を要求することが重要である。 この対策がないと、攻撃者は利用者の現在の資格情報を知らずに、CSRF や XSS の攻撃を通じて機微な取引を実行できてしまう。 加えて攻撃者は、利用者のブラウザへ一時的に物理的にアクセスするか、セッション ID を盗むことで、利用者のセッションを奪える。

リスク事象のあとの再認証

概要 アカウントの復旧、パスワードの再設定、疑わしい振る舞いの兆候のように、アカウントに高リスクの活動があった場合、再認証は決定的に重要になる。 この節は、利用者を保護して不正なアクセスを防ぐために、いつどのように再認証を発動させるのかを示す。 さらに詳しくは機微な機能では再認証を要求するの節を参照する。

再認証を発動させる場面

  • 疑わしいアカウントの活動 通常と異なるログインの兆候、IP アドレスの変化、端末の登録があったとき
  • アカウントの復旧 利用者がパスワードを再設定したり、機微なアカウント情報を変更したあと
  • 重要な操作 支払い情報の変更や、新しい信頼済み端末の追加のような高リスクの操作に対して

再認証の仕組み

  • 適応的認証 利用者の振る舞いと文脈に応じて変わる、リスクに基づく認証モデルを使う
  • 多要素認証（MFA） 機微な操作や事象に対して、追加の検証の層を要求する
  • チャレンジに基づく検証 質問や副次的な手段によって本人であることの確認を求める

実装上の推奨

  • 利用者の負担を最小にする 再認証が利用者体験を不必要に妨げない状態にする
  • 文脈を考慮した判断 地理的な位置、端末の種類、過去の兆候などの文脈に基づいて再認証の判断を行う
  • 安全なセッション管理 再認証のあとにセッションを無効化し、トークンをローテーションする。セッション管理を参照する

参考資料

  • セッション管理
  • OWASP ASVS 2.2.2：再認証の要件
  • NIST 800-63B：Digital Identity Guidelines。認証の保証水準

強固な取引認証を検討する

アプリケーションによっては、利用者が機微な操作を行ってよいかを確かめるために第二の要素を使うべきである。 詳しくは取引の認可を参照する。

TLS クライアント認証

TLS クライアント認証（双方向 TLS 認証）は、TLS のハンドシェイクの過程でブラウザとサーバーがそれぞれの TLS 証明書を送るものである。 証明書を用いて、検証可能な正当な認証局（CA）にその証明書が有効かを問うことでサーバーの真正性を検証できるのと同じように、サーバーはクライアントから証明書を受け取り、第三者の CA または自身の CA に対して検証することで利用者を認証できる。 そのためにサーバーは、利用者ごとに専用に生成した証明書を渡さなければならない。 そのとき subject に値を割り当て、その証明書がどの利用者を検証するものかを判定できるようにする。 利用者はその証明書をブラウザにインストールし、以後そのサイトで使う。

この方法が適しているのは次の場合である。

  • 利用者が単一のコンピュータやブラウザからのみサイトにアクセスすることが許容できる、あるいはむしろ望ましい場合。
  • 利用者がブラウザへの TLS 証明書のインストール作業に怯まない、または IT サポートなどの誰かが利用者の代わりにそれを行う場合。
  • サイトが追加の安全の段階を必要とする場合。
  • 企業や組織のイントラネット向けのサイトである場合にも適する。

一般の利用者が使う、広く公開されたサイトにこの方法を用いるのは、通常はよい考えではない。 たとえば Facebook のようなサイトにこれを実装するのはよい考えとはいえない。 この手法は利用者がパスワードを打つ必要をなくせる（したがって一般的なキーロガーによる窃取から守れる）が、パスワードと TLS クライアント認証を組み合わせて使うことを検討するのがよいと考えられている。

加えて、クライアントが SSL/TLS の復号を行う企業のプロキシの背後にある場合、そのサイトがプロキシで許可されていないかぎり、証明書による認証は壊れる。

さらに詳しくは Client-authenticated TLS handshake を参照する。

認証とエラーメッセージ

認証機能におけるエラーメッセージの実装が誤っていると、ユーザー ID とパスワードの列挙に使われうる。 アプリケーションは（HTTP と HTML の両方で）一般的な形で応答するべきである。

認証の応答

いずれの認証機構（ログイン、パスワード再設定、パスワード復旧）を使う場合も、アプリケーションは次のいずれであるかに関わらず、一般的なエラーメッセージで応答しなければならない。

  • ユーザー ID またはパスワードが誤っていた。
  • そのアカウントが存在しない。
  • そのアカウントがロックまたは無効化されている。

アカウント登録の機能も考慮に入れるべきであり、利用者が既に存在する場合についても同じ一般的なエラーメッセージの方針を適用できる。

目的は、攻撃者がアプリケーションに対して利用者の列挙を仕掛けられるような差異の手がかりを生じさせないことである。

興味深いのは、業務ロジック自体が処理時間に関する差異の手がかりをもたらしうる点である。 実際、実装によっては場合（成功と失敗）に応じて処理時間が大きく異なり、攻撃者がタイミング攻撃を仕掛けられることがある（たとえば数秒の差）。

ログイン機能の擬似コードによる例を示す。

  • 一つめの実装。「早期の脱出」を使う方法。
IF USER_EXISTS(username) THEN
    password_hash=HASH(password)
    IS_VALID=LOOKUP_CREDENTIALS_IN_STORE(username, password_hash)
    IF NOT IS_VALID THEN
        RETURN Error("Invalid Username or Password!")
    ENDIF
ELSE
   RETURN Error("Invalid Username or Password!")
ENDIF

利用者が存在しない場合、アプリケーションは直ちにエラーを投げることがはっきりわかる。 一方、利用者が存在してパスワードが誤っている場合は、エラーになるまでに明らかにより多くの処理が行われる。 その結果、同じエラーに対して応答時間が異なり、攻撃者はユーザー名の誤りとパスワードの誤りを区別できる。

  • 二つめの実装。「早期の脱出」に頼らない方法。
password_hash=HASH(password)
IS_VALID=LOOKUP_CREDENTIALS_IN_STORE(username, password_hash)
IF NOT IS_VALID THEN
   RETURN Error("Invalid Username or Password!")
ENDIF

このコードは利用者やパスワードが何であれ同じ処理を通るので、アプリケーションはおおよそ同じ応答時間で返せる。

利用者に一般的なエラーメッセージを返すことの問題は、利用者体験（UX）にある。 正当な利用者が一般的なメッセージに戸惑い、アプリケーションを使いづらく感じ、何度か試したあとにその煩雑さゆえに離れてしまうかもしれない。 一般的なエラーメッセージを返すかどうかは、アプリケーションとそのデータの重要性に基づいて決められる。 たとえば重要なアプリケーションでは、失敗した場合に利用者を常にサポートページへリダイレクトし、一般的なエラーメッセージを返すとチームが決めることもできる。

利用者の列挙そのものについては、自動化された攻撃への対策も有効である。 攻撃者が列挙を大規模に行うことを防ぐからである。 利用者体験を保たなければならないために一般的なエラーメッセージを返せない機能には、CAPTCHA の使用を適用できる。

誤った応答と正しい応答の例
ログイン

誤った応答の例

  • 「利用者 foo のログイン。パスワードが不正です。」
  • 「ログインに失敗しました。ユーザー ID が不正です。」
  • 「ログインに失敗しました。アカウントが無効です。」
  • 「ログインに失敗しました。この利用者は有効ではありません。」

正しい応答の例

  • 「ログインに失敗しました。ユーザー ID またはパスワードが不正です。」
パスワードの復旧

誤った応答の例

  • 「パスワード再設定のリンクを送信しました。」
  • 「このメールアドレスはデータベースに存在しません。」

正しい応答の例

  • 「そのメールアドレスがデータベースにあれば、パスワード再設定のメールを送信します。」
アカウントの作成

誤った応答の例

  • 「このユーザー ID は既に使われています。」
  • 「ようこそ。登録が完了しました。」

正しい応答の例

  • 「アカウントを有効化するリンクを、入力されたアドレスへ送信しました。」
エラーコードと URL

アプリケーションは認証試行の結果に応じて異なる HTTP のエラーコードを返すことがある。 肯定的な結果に 200 を、否定的な結果に 403 を返すかもしれない。 利用者には一般的なエラーページが表示されていても、HTTP の応答コードが異なることで、そのアカウントが正当かどうかの情報が漏れうる。

エラーの露出も差異の手がかりとして使われうる。 アプリケーション全体での各種エラーの扱いについてはエラー処理を参照する。

自動化された攻撃への対策

攻撃者が利用者のアカウントを侵害しようとする自動化された攻撃には、いくつもの種類がある。 最も一般的なものを以下に挙げる。

攻撃の種類説明
総当たり辞書やその他の情報源から得た複数のパスワードを、単一のアカウントに対して試す。
クレデンシャルスタッフィング別のサイトの侵害から得たユーザー名とパスワードの組を試す。
パスワードスプレー単一の弱いパスワードを、多数の異なるアカウントに対して試す。

これらの攻撃を防ぐために、さまざまな保護の仕組みを実装できる。 多くの場合、これらの防御は完全な保護を与えないが、多層防御の方針でいくつかを組み合わせて実装すれば、妥当な水準の保護に至れる。

以下の節は主に総当たり攻撃の防止に焦点を置くが、これらの対策は他の種類の攻撃にも有効である。 クレデンシャルスタッフィングとパスワードスプレーへの防御についてさらに詳しくはクレデンシャルスタッフィングの防止を参照する。

多要素認証

多要素認証（MFA）は、総当たり攻撃を含むパスワードに関する攻撃の大半に対して、はるかに最良の防御である。 Microsoft の分析によれば、アカウント侵害の 99.9% を止められたとされる。 したがって可能なかぎり実装するべきである。 ただしアプリケーションの利用者層によっては、MFA の使用を強制することが現実的でない、あるいは実現できないこともある。

MFA の実装についてさらに詳しくは多要素認証を参照する。

ログインの抑制

ログインの抑制は、通常の対話的な手段でパスワードを推測する試行を攻撃者が過剰に行うことを防ぐ安全機構であり、次の対策を含む。

  • 試行回数の上限
アカウントのロックアウト

これらの攻撃に対する最も一般的な保護はアカウントのロックアウトである。 一定回数ログインに失敗すると、以後一定期間はログイン試行ができなくなる。

失敗回数のカウンタは、送信元 IP アドレスではなくアカウント自体に結びつけるべきである。 攻撃者が多数の異なる IP アドレスからログインを試すことを防ぐためである。 安全性と使いやすさの釣り合いをとるうえで、アカウントのロックアウトの方針を実装する際に考慮すべき要素はいくつもある。

  • アカウントがロックされるまでの失敗回数（ロックアウトの閾値）
  • その試行が起きなければならない期間（観測窓）
  • アカウントがロックされる時間（ロックアウトの継続時間）

固定のロックアウト時間（10 分など）を実装する代わりに、指数的なロックアウトを使うアプリケーションもある。 ロックアウトの時間が非常に短い期間（1 秒など）から始まり、ログイン試行が失敗するたびに倍になる。

  • 各ロックアウトのあとに遅延させる時間（最大 2 回から 3 回。それを超えたら恒久的なロックアウト）

アカウントのロックアウトの仕組みを設計するときは、他の利用者のアカウントをロックしてサービス妨害を引き起こすことに使われないよう注意しなければならない。 その一つの方法は、アカウントがロックされていても、パスワードを忘れた場合の機能を使ってログインできるようにすることである。

CAPTCHA

有効な CAPTCHA を使うと、アカウントに対する自動化されたログイン試行を防ぐ助けになる。 ただし多くの CAPTCHA の実装には弱点があり、自動化された手法で解かれたり、解いてくれるサービスに外注されたりする。 したがって CAPTCHA の使用は、防止手段ではなく、総当たり攻撃をより時間と費用のかかるものにする多層防御の一対策とみなすべきである。

最初のログインから CAPTCHA を要求するのではなく、数回ログインに失敗したあとにのみ要求するほうが、利用者にとって親切かもしれない。

秘密の質問と記憶している語

秘密の質問や記憶している語を加えることも、自動化された攻撃からの保護に役立つ。 とくに、その語のうちランダムに選ばれた何文字かを入力させる場合に有効である。 ただしこれは多要素認証にはあたらないことに注意する。 どちらの要素も同じ（知っていること）だからである。 さらに秘密の質問はしばしば弱く、答えが予測しやすいので、注意して選ばなければならない。 これについてさらに詳しくは秘密の質問の選び方と使い方を参照する。

ログと監視

攻撃や失敗をリアルタイムに検出するため、認証機能のログと監視を有効にする。

  • すべての失敗が記録され、確認される状態にする
  • すべてのパスワードの失敗が記録され、確認される状態にする
  • すべてのアカウントのロックアウトが記録され、確認される状態にする

パスワードを必要としない認証プロトコルの利用

ユーザー名、パスワード、多要素認証の組み合わせによる認証は一般に安全とみなされるが、それが最良の選択とはいえない、あるいは安全とすらいえない用途もある。 その例は、モバイル端末、別のサイト、デスクトップなどから Web アプリケーションへ接続したいサードパーティのアプリケーションである。 この場合、サードパーティのアプリケーションに利用者とパスワードの組を保存させることは安全ではない。 攻撃対象領域が自分の制御の外にある相手側へ広がってしまうからである。 この用途や他の用途のために、利用者のデータを攻撃者に露出させることを防ぐ認証プロトコルがいくつも存在する。

OAuth 2.0 と 2.1

OAuth は、API への委譲されたアクセスのための認可の枠組みである。 OAuth 2.0 プロトコルも参照する。

注記：OAuth 2.1 は IETF のワーキンググループの草案であり、OAuth 2.0 と広く採用された最良の慣行を統合し、RFC 6749/6750 を置き換えることを意図している。このチートシートの指針は OAuth 2.0 と OAuth 2.1 の両方にあてはまる。参考：draft-ietf-oauth-v2-1-13、oauth.net/2.1

OpenID Connect（OIDC）

OpenID Connect 1.0（OIDC）は、OAuth の上にあるアイデンティティの層である。 クライアント（relying party）が ID トークン（署名された JWT）を用いてエンドユーザーの身元を検証する方法と、利用者のクレームを相互運用可能な形で取得する方法を定義する。 認証とシングルサインオンには OIDC を、API への認可には OAuth を使う。

OIDC の実装の指針

  • relying party 側で ID トークンを検証する。発行者（iss）、対象者（aud）、署名（プロバイダの JWK による）、有効期限（exp）を確認する。
  • よく保守されたライブラリや SDK と、プロバイダのディスカバリおよび JWKS のエンドポイントを優先する。
  • ID トークンを超える追加のクレームが必要な場合は UserInfo のエンドポイントを使う。

混同を避ける：**OpenID 2.0（「OpenID」）**は別の、レガシーな認証プロトコルであり、OpenID Connect に置き換えられて廃れたとみなされている。新しいシステムで OpenID 2.0 を実装するべきではない。参考：OpenID Foundation。廃れた OpenID 2.0 のライブラリ、OpenID 2.0 から OIDC への移行

SAML

Security Assertion Markup Language（SAML）は、しばしば OpenID と競合するものと考えられている。 最も推奨されるバージョンは 2.0 であり、機能が非常に充実しており強固な安全性を備える。 OpenID と同じく SAML はアイデンティティプロバイダを使うが、OpenID と違って XML に基づき、より柔軟性が高い。 SAML はブラウザのリダイレクトによって XML のデータを送る仕組みに基づく。 さらに SAML はサービスプロバイダから開始されるだけでなく、アイデンティティプロバイダから開始することもできる。 これにより利用者は、何もしなくても認証された状態を保ったまま異なるポータルを行き来でき、処理が意識されなくなる。

OpenID が消費者向けの市場の多くを占めた一方で、企業向けのアプリケーションではしばしば SAML が選ばれる。 企業級とみなされる OpenID のアイデンティティプロバイダが少ないからである（企業のアイデンティティに求められる高い基準を、利用者の身元の検証方法が満たしていないという意味である）。 SAML はイントラネットのサイトの内部で使われることのほうが多く、イントラネットのサーバーをアイデンティティプロバイダとして使う場合すらある。

ここ数年、SAP ERP や SharePoint（SharePoint は Active Directory Federation Services 2.0 を用いる）のようなアプリケーションが、Web サービスや Web アプリケーションで企業のフェデレーションが必要な場面において、シングルサインオンの実装として SAML 2.0 認証をしばしば優先される方法として採用してきた。

SAML のセキュリティも参照する。

FIDO

Fast Identity Online（FIDO）Alliance は、オンライン認証を助ける二つのプロトコルを作った。 Universal Authentication Framework（UAF）プロトコルと Universal Second Factor（U2F）プロトコルである。 UAF はパスワードのない認証に焦点を置き、U2F は既存のパスワードに基づく認証へ第二の要素を加えることを可能にする。 どちらのプロトコルも、公開鍵暗号によるチャレンジとレスポンスのモデルに基づく。

UAF は、指紋センサー、カメラ（顔の生体情報）、マイク（声の生体情報）、Trusted Execution Environment（TEE）、Secure Element（SE）など、端末上に存在する既存の安全技術を活用する。 このプロトコルは、これらの端末の能力を共通の認証の枠組みに差し込めるよう設計されている。 UAF はネイティブアプリケーションと Web アプリケーションの両方で機能する。

U2F は、認証用の暗号鍵を保存して署名に用いるハードウェアトークン（通常は USB）によって、パスワードに基づく認証を補強する。 利用者は同じトークンを複数のアプリケーションの第二要素として使える。 U2F は Web アプリケーションで機能する。 サイトの URL を用いて保存された認証鍵を引くことで、フィッシングに対する保護を与える。

FIDO2：FIDO2 と WebAuthn は、以前の標準（UAF と U2F）を包含し、現代のパスキー技術の基盤を形成する。 パスキーは、生体情報や端末の PIN のような端末内での利用者確認によって安全にログインすることを可能にし、多くの場合は端末間で資格情報を同期する。

ハードウェアに裏付けられた鍵の保存

一般的なプラットフォームのパスキーを含む多くの認証器では、秘密鍵は OS の安全な鍵マネージャによって生成され保存される。 プラットフォームと認証器に応じて、鍵は Windows の Trusted Platform Module（TPM）、Apple の端末の Secure Enclave、Android の Keystore や StrongBox のようなハードウェアに裏付けられた構成要素で保護されることもあり、他のソフトウェアに基づく仕組みで保護されることもある。

典型的な実装では、秘密鍵は持ち出せず認証器に結び付けられていることが意図されており、プラットフォームの安全モジュールがこの鍵を用いてサーバーのチャレンジに署名する。 しかし認証器によっては、持ち出しやサーバー側の保存を伴いうる資格情報の同期やバックアップに対応しており、すべての実装がハードウェアに裏付けられているわけではない。 relying party は、（認証器の属性やアテステーションなどによって）検証されないかぎり、鍵がハードウェアに裏付けられ持ち出せないものと想定するべきではない。

パスワードマネージャ

パスワードマネージャは、多数の異なる資格情報の管理を自動化するプログラム、ブラウザのプラグイン、Web サービスである。 ほとんどのパスワードマネージャは、利用者がサイト上で容易に使えるようにする機能を備えている。 (a) パスワードをログインフォームに貼り付けるか、(b) 利用者が入力する動作を模倣する。

Web アプリケーションは、次の推奨に従うことで、パスワードマネージャの仕事を必要以上に難しくしないようにすべきである。

  • ユーザー名とパスワードの入力には、適切な type 属性を持つ標準の HTML フォームを使う。
  • プラグインに基づくログインページ（Flash や Silverlight など）を避ける。
  • 適切なパスワード強度の対策を実装するの節で述べたように、妥当な最大長（少なくとも 64 文字）を実装する。
  • パスワードに任意の印字可能な文字を使えるようにする。
  • ユーザー名、パスワード、MFA の各欄への貼り付けを許可する。
  • Tab キーの一度の押下で、ユーザー名の欄とパスワードの欄を行き来できるようにする。

利用者の登録メールアドレスの変更

利用者のメールアドレスはしばしば変わる。 システムでこうした状況を扱うには、次の手順を推奨する。

注記：多要素認証がある場合、身元の証明がパスワードのみに頼るより強固になるため、手順はより緩やかになる。

利用者が多要素認証を有効にしている場合の推奨手順

  1. 利用者の認証 Cookie やトークンの有効性を確認する。有効でなければログイン画面を表示する。

  2. 登録メールアドレスの変更手順を利用者に説明する。

  3. 新しいメールアドレスの案を利用者に入力させ、システムの規則に適合していることを確かめる。

  4. 身元の検証のために多要素認証の使用を求める。

  5. 新しいメールアドレスの案を、保留中の変更として保存する。

  6. (a) システム管理者への通知と (b) 利用者の確認のために、有効期限のある nonce を二つ生成して保存する。

  7. それらの nonce を含むリンクを載せたメールを二通送る。

    • 現在のアドレスへ、変更が行われようとしていることを知らせ、想定外の活動を報告するリンクを添えた通知のみのメール。

    • 新しいアドレスの案へ、変更を確認するよう指示し、想定外の場合のためのリンクを添えた確認を要するメール。

  8. リンクからの応答をそれに応じて処理する。

利用者が多要素認証を有効にしていない場合の推奨手順

  1. 利用者の認証 Cookie やトークンの有効性を確認する。有効でなければログイン画面を表示する。

  2. 登録メールアドレスの変更手順を利用者に説明する。

  3. 新しいメールアドレスの案を利用者に入力させ、システムの規則に適合していることを確かめる。

  4. 身元の検証のために利用者の現在のパスワードを求める。

  5. 新しいメールアドレスの案を、保留中の変更として保存する。

  6. システム管理者への通知、利用者の確認、そしてパスワードに依拠するための追加の段階のために、有効期限のある nonce を三つ生成して保存する。

  7. それらの nonce へのリンクを載せたメールを二通送る。

    • 現在のアドレスへ、変更を確認するよう指示し、想定外の場合のためのリンクを添えた確認を要するメール。

    • 新しいアドレスの案へ、変更を確認するよう指示し、想定外の場合のためのリンクを添えた別の確認を要するメール。

  8. リンクからの応答をそれに応じて処理する。

上記の手順についての注記

  • Google はパスワードのみで保護されたアカウントについて異なる方法を採っており、現在のメールアドレスには通知のみのメールを送る。この方法にはリスクがあり、利用者の警戒を要する。

  • ソーシャルエンジニアリングに関する定期的な訓練は決定的に重要である。システム管理者とヘルプデスクの担当者は、定められた手順に従い、ソーシャルエンジニアリング攻撃を認識して対応できるよう訓練されるべきである。指針は CISA の "Avoiding Social Engineering and Phishing Attacks" を参照する。

適応的認証、リスクに基づく認証

より高度なアプリケーションの機能として、さまざまな環境上および文脈上の属性（アクセスを要求されているデータの機微さ、時刻、利用者の位置、IP アドレス、端末のフィンガープリントなどを含むがこれに限らない）に応じて、異なる認証の段階を要求できるものがある。

たとえば、ある端末からの最初のログインには MFA を要求し、その端末からのその後のログインには要求しないことができる。 あるいは、シングルサインオンの仕組みが利用者を認証して一日ログインしたままにしておき、プロフィールのページにアクセスしようとしたときには再認証を要求することもできる。

もう一つの選択肢は逆の方法である。 アプリケーションは、端末を識別するもの（以前と同じ IP アドレスからの、特定のモバイル端末のフィンガープリント、持続する Cookie とブラウザのフィンガープリントなど）だけで低リスクのアクセスを許し、機微な操作に対して段階的に強い認証を要求する。 たとえば、現在の口座残高を見ることは許すが、口座番号やその他は見せない。 取引を見る必要があるなら基本水準の認証を通し、送金をしたいなら MFA を要求する。

このような仕組みを実装するとき、検討すべき問いを挙げる。

  • 定める方針は、社内の方針、とくに規制上の方針と整合しているか。
  • セッションの開始時に、利用者や端末のどの属性（IP、地理的位置、端末のフィンガープリント、時刻、行動の生体的特徴など）を観測するのか。
  • それらの信号のうち、有効なセッションの途中で更新する必要があるのはどれで、どの頻度で行うのか。
  • 各信号の正確さをどう確保し、欠損や確度の低いデータをどう扱うのか。
  • 生の信号をリスクの階層へ変換する採点モデル（重み、閾値、機械学習、規則に基づく方式、混成）は何を使うのか。
  • そのモデルはどこで動かし（エッジ、API ゲートウェイ、中央のサービス）、遅延の許容量はどれだけか。
  • 各リスク階層にどの動作を対応づけるのか（許可、CAPTCHA、段階的な MFA、遮断、セッションの失効）。
  • 各動作に伴って利用者に見せるメッセージとエラーコードは何にするのか。
  • リスク判定の機構をコードやプラットフォームのどの層で呼び出すのか（ログインのコントローラ、ミドルウェア、API ゲートウェイ、サービスメッシュ）。
  • Web、モバイル、API のクライアントにまたがって、判断を一貫してどう伝播させるのか。
  • セッション途中のリスク確認で危険度が上がったとき、トークンや Cookie をどう変更、延長、失効させるのか。
  • 複数の同時に使われる端末やブラウザのタブのあいだで、状態をどう同期させるのか。
  • 疑わしい活動に対してどの監視と警報を用意するのか。利用者への通知方法も含める。