# 貼り付けを受け付けないパスワード欄 Source: https://easeweb.dev/learn/password-paste Topics: ページの構造 > ログイン時に、情報の暗記や書き写しを求めない (WCAG 3.3.8; EN 301 549 5.3) The fix: パスワードを、利用者が保管しているままの形で入れられるようにします。貼り付けを禁止するハンドラーを外し、autocomplete="username" と autocomplete="current-password" でパスワード管理ツールが入力できるフォームにするか、パスワードの段階を変えられない場合は、メールで届くログイン用のリンクのような、パスワードのいらない方法をその横に用意します。 Test with: keyboard, screen reader, password manager, autofill References: https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html https://www.w3.org/WAI/WCAG22/Techniques/failures/F109 https://www.w3.org/WAI/WCAG22/Techniques/html/H100 https://www.w3.org/WAI/WCAG22/Techniques/general/G218 https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete https://pages.nist.gov/800-63-4/sp800-63b.html https://www.troyhunt.com/the-cobra-effect-that-is-disabling/ https://www.chromium.org/developers/design-documents/create-amazing-password-forms/ よくある問題を再現した学習用のサンプルです。実在のクライアントの診断結果ではありません。コードは出発点となる実装例のため、実際の製品でも確認してください。ここでは支援技術でのテスト結果は報告していません。 ## 場面 ある電力会社のアカウントのページは、メールアドレスとパスワードを求めます。パスワード管理アプリでパスワードを管理している人が、アプリを開いて、アプリに作らせた長いランダムなパスワードをコピーし、パスワード欄に貼り付けます。何も入りません。欄が貼り付けを禁止しているからです。安全でない場所からパスワードを貼り付けさせないようにと、何年も前に誰かが加えた制限です。ブラウザーに組み込まれたパスワード管理機能なら、欄を埋められることもあります。自動入力は貼り付けではないからです。しかし、このブラウザーには入力できない別の端末のパスワード管理ツールも、パスワードを書き留めたメモも、コピーと貼り付けで使うものです。残る方法は、一方の画面でパスワードを読み、点しか表示されないもう一方の欄に1文字ずつ打ち込むことだけです。 この段階でのつまずき方は、ほかにもあります。 - `maxlength="12"` の欄では、貼り付けや自動入力で入れた20文字のパスワードが最初の12文字で切れ、パスワードが違うと表示される。 - 銀行が、合言葉の2文字目、6文字目、最後の文字をそれぞれメニューから選ばせる。パスワード管理ツールでは入力できず、記憶を頼りに文字を数えるしかない。 - ページが指紋か顔の認証しか用意せず、パスワードもほかの方法もない。3.3.8はこれをテストとみなさないが、それを使えない人は締め出され、EN 301 549の5.3項もこれを認めていない。 ## 確認できる問題 達成基準3.3.8「アクセシブルな認証（最低限）」はレベルAAで、WCAG 2.2で新しく加わりました。ログインのどの段階も、パスワードを覚えることや書き写すことのような認知機能テストを求めてはいけません。ただし、その段階に、テストのいらない別のログイン方法か、テストを助ける仕組みがあれば構いません（残る2つの例外、物の認識と、本人がサイトに提供した内容の識別は、パスワードには当てはまりません）。達成基準の注記は、その仕組みの例として、利用者の代わりにパスワードを保管するパスワード管理ツールと、コピーと貼り付けの2つを挙げています。そして達成基準の解説書は、認証の欄への貼り付けを妨げると書き写すしかなくなるため、不適合になるとはっきり書いています。 失敗例F109は、同じことを逆の側から述べています。パスワードは、作ったときの形のまま、丸ごと入れられなければなりません。貼り付けを拒む欄、パスワードを途中で切る欄、一部の文字を別々の欄で求める入力は、書き写しのいらない別の方法を同じログインで選べない限り、不適合です。ページはハンドラー1つで貼り付けをすべて無効にできますが、ブラウザーは無効にしたことを何も示しません。欄が空のままになるだけです。 ## 利用者への影響 この問題に突き当たるのは、まさにセキュリティの助言どおりにしている人です。サイトごとに違う長いパスワードを使い、頭ではなくパスワード管理ツールに保管している人です。 ## 自動チェックとAIの限界 どの欄にもラベルがあるため、axeなどの自動チェックはフォームを合格にします。貼り付けを試すルールはありません。EaseWebの診断は、フォームに1つだけあり、新しいパスワード用ではないパスワード欄それぞれに1文字を貼り付け、貼り付けを無効にして何も入れない欄を報告します。フォームは送信しません。パスワード管理ツールがフォームを入力できるか、メールのリンクのような別の方法が最後まで動くかは分からないため、どちらも人が試す必要があります。AIのコードアシスタントにログインを「より安全に」と頼むと、パスワード欄に貼り付けの禁止を加えることがあります。ログインのフォームを頼むと、各欄の役割をパスワード管理ツールに伝える `autocomplete` 属性を省くこともあります。 ## 修正前：貼り付けを禁止するパスワード欄 ```html
``` `onpaste="return false"` があると、キーボードでも、コンテキストメニューでも、パスワード管理アプリからでも、欄への貼り付けはすべて無効になります。拒んだことは、欄のどこにも示されません。パスワードを入れる方法は、覚えておくか、手で書き写すかしか残りません。 ## 修正後：貼り付けも自動入力もできるパスワード欄 ```html
``` 貼り付けのハンドラーがなくなれば、パスワードはほかのテキストと同じように入ります。貼り付けも、ドラッグも、自動入力も使えます。これは達成方法H100の形です。メールアドレスとパスワードはどちらもラベルの付いた本物の入力欄で、同じフォームの中にあります。`autocomplete="username"` と `autocomplete="current-password"` は、それぞれの欄に何が入るかをブラウザーとパスワード管理ツールに伝えます。そのため、ブラウザーやツールは両方の欄への入力や、新しいパスワードの保存を提案できます。スクリプトはいりません。 ## 修正後：パスワードはそのままに、パスワードのいらない方法を加える ```html
``` 2つ目のボタンはフォームを別の宛先に送り、サーバーはログイン用のリンクをメールで送ります。覚えることも打つことも、メールアドレスのほかにはありません。これは達成方法G218の形で、パスワード欄は変わらなくても、この別の方法があれば3.3.8を満たします。ベンダーが運営するログインのように、パスワードの段階を変えられない場合のための方法です。パスワードでログインする人は、今までどおり貼り付けられません。リンクも、メールを確認でき、期限が切れる前に開ける間しか使えません。 ## どの方法を選ぶか どちらも3.3.8を満たします。パスワードを貼り付けや自動入力で入れられるようにしてください。誰もが使う段階そのものを、より少ないコードで直せます。メールのリンクを加えても、パスワードの段階は難しいままです。できれば、メールのリンクやパスキーも合わせて用意してください。パスワードをまったく扱えない人の助けになります。貼り付けの禁止を残すのは欄を変えられない場合だけにし、その場合は、別の方法がパスワードと同じくらい見つけやすいようにします。 ## 実装の判断 貼り付けを止めても、パスワードは安全になりません。セキュリティ研究者のTroy Huntが集めた、サイトが挙げてきた理由は、どれも成り立ちません。 - パスワードを次々に試すプログラムを止めるため。そうしたプログラムは欄に直接入力するか、フォームをサーバーへそのまま送るので、貼り付けを使いません。止められるのは人だけです。 - クリップボードを読むマルウェアからパスワードを守るため。端末にいるマルウェアは、パスワードを打つときのキー操作も同じように記録できます。 - サイトの上限より長いパスワードを貼り付けたとき、気づかないうちに途中で切れないようにするため。直すべきは上限のほうで、上限をなくすか、欄の横に示します。 実際に貼り付けの禁止がもたらすのは、打てる程度に短いパスワードを選ばせることです。パスワード管理ツールが作る長いランダムなパスワードは、そのどれよりもずっと強力です。米国国立標準技術研究所（NIST）のデジタルアイデンティティのガイドラインも、パスワード管理ツールと自動入力を認めなければならず、パスワードの貼り付けも認めるべきだとしています。 欄を `type="text"` に切り替えたり戻したりする「パスワードを表示」ボタンは、打った内容を確かめる助けになり、達成基準の解説書も勧めています。`aria-pressed` を持つ本物のボタンにして、パスワードが表示されているかどうかをスクリーンリーダーが伝えられるようにします。 ログインの欄に `autocomplete="off"` を付けないでください。保存した内容を提案しないようブラウザーに求める指定です。ただし、ほとんどのブラウザーは、ログインの欄ではこの指定を無視します。また、メールアドレスとパスワードを別々のページに分ける場合は、2ページ目にユーザー名を入れた隠し欄を置きます。そうしないと、パスワード管理ツールが何を入力すればよいか分からないことがあります。 端末の指紋、顔、PINでログインするパスキーも、3.3.8を満たす別の方法です。達成基準の解説書は、Windows HelloやFace IDのような端末自身の認証を、認知機能テストとして扱っていません。パスキーは、ほかのすべての方法の代わりではなく、パスワードと並べて用意してください。指紋や顔だけがログインの方法だと、それを使えない人が締め出されます。EN 301 549の5.3項も、特定の生体的特徴を、利用者を識別する唯一の手段にしないよう求めています。 SMSやメールで届くコードも同じ種類の段階で、同じように貼り付けを確かめる必要があります。[貼り付けられないワンタイムコードの入力欄](/ja/learn/one-time-codes)を参照してください。ゆがんだ文字のように、ログインの前に解かせるパズルも同じ基準の対象です。[パズルを解く以外に通れないCAPTCHA](/ja/learn/captcha)を参照してください。 ## 修正の確認 1. パスワード管理アプリやメモに保存したパスワードをコピーし、Ctrl + VかCommand + Vとコンテキストメニューの両方で欄に貼り付け、パスワード全体が入ってログインできるか確認する。 2. ブラウザーのパスワード管理機能に保存したパスワードを提案させ、メールアドレスとパスワードの両方が入力されるか確認する。 3. メールのリンクのような別の方法がある場合は、最初から最後まで使い、パスワードなしでログインできるか確認する。 4. スクリーンリーダーでも、キーボードだけでも、ページが用意するそれぞれの方法でログインし、すべての欄とボタンにたどり着け、ラベルとともに読まれるか確認する。 OS、ブラウザー、パスワード管理ツールと支援技術のバージョン、ビルド、実施日、各手順の実際の結果を記録してください。ログインのフォームや、それを作る部品ライブラリーを変更した際は、再度確認します。 ## 制限 このサンプルは、どのログインでも同じ結果になることを保証するものではありません。対象はパスワードの段階です。コード、秘密の質問、パズルなど、ログインのほかの段階にも同じ確認が必要です。この基準の対象は既存のアカウントへのログインで、アカウントの作成は含みませんが、同じ理由から、パスワードを設定する欄も貼り付けを受け付けるべきです。メールのリンクが期限内に届くかは利用者のメール次第で、ページからは確かめられません。利用者が頼りにしているパスワード管理ツールやその他のツールで、ログイン全体を確認してください。 --- このガイドをコーディングエージェントで使う: MCP https://easeweb.dev/mcp（設定は https://easeweb.dev/ja/services/developers）