JSSEC セキュリティコラム
25年12月号「パスワード管理ツールの活用」
～ 安全な認証を行うためには ～
JSSEC副会長・理事
KDDI株式会社 本間 輝彰
私たちが日常的に使用するスマートフォン、その便利さの裏には思わぬ落とし穴が潜んでいます。それが、スマートフォン利用者をターゲットにしたサイバー犯罪です。本コラムでは、利用者自身を含め身近なスマートフォンユーザーに起こりうるサイバー攻撃の実態を掘り下げ、その手口と対策について解説していきます。
だんぜん“Chrome”、“Safer with Google”というキャッチフレーズを使って、Google社がパスワード管理ツール（パスワードマネージャ）の宣伝広告などにより、パスワード管理ツールの認知度が上がっています。
パスワード管理ツールは、（National Institute of Standards and Technology）が公開しているNIST SP800-63B-4※1でも利用が推奨されています。
本コラムではパスワード管理ツールの利用が推奨される背景を踏まえ、サービス提供者が実施すべき認証機能の実装についての推奨内容を紹介します。本コラムを参考に、安全なインターネットでのサービスの利用につながれば幸いです。
※1 https://csrc.nist.gov/pubs/sp/800/63/b/4/final
パスワード管理ツール推奨の背景
パスワード管理ツールの利用については、米国のセキュリティ機関である CISA（Cybersecurity and Infrastructure Security Agency：サイバーセキュリティ・インフラセキュリティ庁） が発表したモバイル通信におけるベストプラクティス Mobile Communications Best Practices Guidance※2（2024年12月18日公表、2025年11月24日にVer.2公表）において、“4. Use a password manager to store all passwords.” として、パスワード管理ツールの利用が推奨されています。
また、NIST SP 800-63B-4（2025年7月公開）でも 3.1.1.2. Password Verifiers の中で、認証を提供する側（verifier：サービス提供者等）が、利用者によるパスワードマネージャおよび自動入力機能の使用を許可することを必須としています。あわせて、パスワードマネージャの利用を促進する観点から、パスワード入力時の貼り付け（paste）を許可することも推奨しています。
Verifiers SHALL allow the use of password managers and autofill functionality. Verifiers SHOULD permit claimants to use the “paste” function when entering a password to facilitate password manager use when password autofill APIs are unavailable. Password managers have been shown to increase the likelihood that subscribers will choose stronger passwords, particularly if the password managers include password generators [Managers].
パスワード管理ツールを使用しない場合、パスワード管理において以下の課題があると考えられます。
● 利用者がパスワードを手動入力する場合、入力を容易にするため、短く単純なパスワードを設定しがちである。
● パスワードを覚える負担を避けるため、推測されやすい安易なパスワードを設定しがちである。
● 複数サービスで異なるパスワードを設定・管理することが負担となり、パスワードの使い回しが発生しがちである。
攻撃者は、こうした運用が一定数存在することを理解しており、ブルートフォースアタック、パスワードリスト攻撃（漏えい済み認証情報の悪用）、フィッシング攻撃などを通じて認証情報の搾取を狙ってきます。
このような背景の中、パスキー（FIDO2）の提供が推奨されている一方で、サービスの対応状況、既存システムの制約、運用面・サポート面の事情等により、パスキーの導入が困難なケースが存在するのも事実です。したがって、これらのサービスにおいては、より安全にパスワードを管理する仕組みとして、パスワード管理ツールの利用が推奨されます。
パスワード管理ツールを使うことで、利用者は下記の恩恵を受け、ユーザビリティも大きく向上すると考えられます。
● パスワードを自動入力可能となる。
● パスワードを覚えておく必要がなくなる。
● サービス毎に異なるパスワードの設定・管理が容易になる。
● パスワードの自動生成により、複雑で推測されにくいパスワードの設定が容易になる。
さらに、パスワード管理ツールの中には、ワンタイムパスワード（TOTP等）による多要素認証に対応しているものもあり、対応した場合は、認証コードの入力負担も軽減されます。
また、パスワードを自動入力する運用とすることで、利用者は「自動入力されない」場合に、ドメイン相違等に気づくきっかけとなり、不正サイトの可能性を疑う契機になる場合もあります。
加えて、多くのパスワード管理ツールはクラウド同期等により複数デバイス間で保管庫（Vault）を共有できるため、スマートフォンだけでなくPCでも同様にパスワードの参照・自動入力が可能となります。
※2 https://www.cisa.gov/resources-tools/resources/mobile-communications-best-practice-guidance
サービス提供者に求められる条件
パスワード管理ツールの利用を実効的なものとするためには、利用者側の努力に加え、サービス提供者側が Web／スマホアプリの双方において、パスワードマネージャやOS標準の自動入力機能を阻害しない設計を行う必要があります。サービス提供者に求められる主な条件は以下のとおりとなります。
1. 共通要件（Web／アプリ共通）
● パスワード入力欄への貼り付け（paste）を許可し、セキュリティ対策を理由に一律禁止しない（パスワード管理ツール利用を阻害しない）。
● パスワード管理ツール／OSの自動入力（Autofill）を妨げる実装を行わない（独自制御の過剰なキー入力制限、クリップボード禁止の一律適用、特殊な入力部品の乱用等）。
● ログイン画面の構造・項目（ID/パスワード等）を標準的に保つ（独自の分割入力、毎回変わる項目名や順序、入力ステップの過剰分割等により自動入力が失敗しないようにする）。
・利用者IDを「****-****」のように複数フィールドへ分割して入力させるUI（例：ID前半／後半の別入力）は、パスワード管理ツールやOS標準AutofillがIDを1つの資格情報として認識できず、自動入力や保存・更新が正常に動作しない原因となるため、原則として避けることが推奨される。
● パスワード変更／再設定の導線を整備し、利用者が長く複雑なパスワードやランダム生成パスワードを無理なく設定できるUIとする。
2. Web（ブラウザ）に関する要件
● input type="password" 等の標準的なフォーム部品を用い、パスワード管理ツールが認識できるようにする。
● autocomplete 属性を適切に設定する（例：ログインは username / current-password、新規設定は new-password 等）。
※ 一律で autocomplete="off" としない。
● ログインID（メールアドレス等）・パスワードの入力欄に対し、画面上のラベルやname属性等の意味が分かる実装とし、パスワード管理ツールが項目判定を誤らないようにする。
● 不要なスクリプトでフォーム送信や入力挙動を過度にカスタマイズしない（自動入力の検知・反映を阻害しない）。
3. スマホアプリ（iOS/Android）に関する要件
● OS標準の自動入力フレームワークに沿って実装する。
・iOS：Password AutoFill / Associated Domains など、資格情報の関連付けが可能な設計
・Android：Autofill Framework、Credential Manager等に適合する設計
● WebView内ログインを用いる場合でも、自動入力が機能する設計（関連付け、入力欄の標準化、不要な制限排除）とする。
● メールアドレス／ユーザー名／パスワード等の入力欄は、OSが種別判定できるよう 適切な入力タイプ（text/email/password等）やヒント属性を設定する。
● 独自キーボードや特殊な入力コンポーネントを使う場合でも、自動入力・貼り付けができることを要件として担保する（どうしても不可の場合は代替手段を提示する）。
4. 多要素認証（MFA）に関する要件
● ワンタイムパスワード（TOTP等）入力欄についても、可能な範囲で OSのコード自動入力（SMSのワンタイムコード提案等）や貼り付けを阻害しない。
● 「MFAだから」という理由で、パスワード入力の貼り付け禁止・自動入力禁止といった無関係な制限を追加しない（利用者の弱いパスワード選択や使い回しを助長するため）。
5. 互換性の検証・運用要件
● 主要なパスワード管理ツールおよび主要ブラウザ／OS（iOS/Android/Windows/macOS）において、以下が成立することを受入基準としてテストする。
・保存（Save）ができる
・自動入力（Autofill）ができる
・パスワード変更後に更新（Update）ができる
● UI変更やログインフロー変更時に、自動入力が壊れていないことを回帰テストする（継続運用要件として扱う）。
また、一部サービスではパスワードの最大長が短い、または記号を許容しない等の制約があり、パスワード管理ツールが生成する強力なパスワードをそのまま適用できない場合がある。パスワード管理ツールの効果を最大化するため、サービス提供者は十分な最大長の確保および記号を含む幅広い文字種の許容等、生成パスワードを阻害しない受け入れ設計を行う必要があり、以下条件の対応も求められる。
6. パスワード条件
● 設定可能なパスワード長は十分に大きく設定可能とする（例：少なくとも64文字以上を許容する）。
・短い最大長（例：12～16文字上限）は、生成パスワードやパスフレーズ利用を阻害原因となる。
● 最大長超過時にサイレントに切り捨て（truncate）しない。超過はエラーとして明示し、利用者が修正できるようにする。
・サイレントに切り捨てると、パスワード管理ツールで管理するパスワードの不整合が発生に、認証失敗の原因となる。
● 最小長はセキュリティ水準に応じて定めつつ、利用者に長いパスワード利用を促せるUIとする（生成パスワードやパスフレーズが入力しやすい）。
● パスワードにおいて、幅広い文字種（少なくともASCII印字可能文字）を許容する（記号を禁止しない）。
● 不要な「利用可能記号の限定」や「特定記号禁止」を設けない（設ける場合は理由と代替策を明確化する）。
● 文字種強制（大文字必須・記号必須等）を過度に設けず、長さ中心の設計とする（管理ツール＋長いランダムの利点を活かす）。
・NIST SP 800-63B-4 では、認証を提供する側（Verifiers / CSPs）に対し、パスワードについて文字種の組合せを要求する等の構成規則（composition rules）を課してはならないとしている。
“Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.”
まとめ
フィッシング詐欺やパスワードリスト攻撃等により認証情報が搾取され、アカウントが悪用される事例が増加する中、認証の安全性を高めるうえで「パスワードをいかに安全に管理・運用するか」は重要な課題です。利用者が手動でパスワードを管理する場合、短く単純なパスワードの設定、推測されやすいパスワードの選択、複数サービス間での使い回しが起こりやすく、結果として攻撃に対して脆弱になりがちです。これらの課題に対する現実的な対策として、パスワード管理ツールの活用が有効です。
パスワード管理ツールの利用は、CISAのガイダンスにおいて推奨されているほか、NIST SP 800-63B-4でも認証を提供する側（verifier）がパスワードマネージャや自動入力機能の利用を許容し、貼り付け操作も妨げないことが求められています。さらに同文書では、従来一般的だった「大文字・小文字・数字・記号の組合せ必須」といった構成規則（composition rules）を課さない考え方が示されており、長く強力なパスワード（およびパスワード管理ツールによる生成・自動入力）を活かす設計への転換が進んでいます。現在はクラウド同期等により、スマートフォンだけでなくPCでも同一の保管庫（Vault）を利用できる環境が整っており、利用者が一意で強力なパスワードを安全かつ利便性高く運用しやすくなっています。
一方で、パスワード管理ツールの効果を最大化するためには、利用者側だけでなく、サービス提供者側の対応が不可欠です。具体的には、Web/アプリ双方で自動入力・貼り付けを阻害しないこと、IDの分割入力など自動入力が失敗しやすいUIを避けること、また生成される強力なパスワードを受け入れられるよう十分な最大長や記号を含む文字種を許容すること等が求められます。したがって、認証の安全性とユーザビリティを両立するためにも、サービス提供者側においてパスワード管理ツール対応を計画的に推進することが推奨されます。