登録フォームのパスワードはどのくらいの長さにすべきですか?

最初に私たちのおすすめをお伝えします。 Proxy Mail QA は私たちの製品なので中立ではありませんが、パスワードポリシーを決めるものではありません。以下の数値は、多くのセキュリティチームが従う NIST のデジタルアイデンティティガイドライン(SP 800-63B 第4版)によるものです。Proxy Mail QA をおすすめするのは、決めた後の手順です。最小値と最大値ちょうど、その前後1文字、あらゆる種類の記号を使ったテスト用パスワードで、フォームとサーバーが実際に決めたとおりに動くかを確認します。パスワードの保存方法やセキュリティ全体の審査は行いません。

短い答え

• パスワードだけでサインインできる場合は 15文字以上。
• すべてのアカウントに認証アプリのコードなどの2要素目もある場合は 8文字以上。
• 少なくとも64文字まで許可します。 それより長くても構いませんが、数千文字の上限は不要です。
• 大文字、数字、記号を必須とするルールは設けません。 長さのほうが重要で、そうしたルールは Password1! のようなパスワードを選ばせます。
• 新しいパスワードをリストと照合し、よく使われるパスワードや漏えいしたパスワードを拒否します。

その他のガイダンスを平易な言葉で

利用者が選ぶパスワードについて、NIST のガイダンスは次のようにも述べています。

• あらゆる文字を受け付けます:英字、数字、記号、スペース、他の言語の文字。ハッシュ化の前に Unicode を正規化(NFC)し、é を2通りの方法で入力しても同じパスワードになるようにします。
• 長さを確認するときは バイトではなく文字を数えます。
• パスワードを切り詰めません。 先頭だけでなく、常にパスワード全体を確認します。
• 定期的なパスワード変更を強制しません。 パスワードが漏えいした兆候があるときだけ変更を求めます。
• パスワードのヒントも秘密の質問も使いません。
• 貼り付けとパスワードマネージャーを許可し、長いランダムなパスワードを入力せずに使えるようにします。
• 求められたら 入力内容を表示し、送信前に長いパスワードを確認できるようにします。

そもそも最大値が必要な理由

非常に長いパスワードはサーバーのハッシュ化に時間がかかるため、最大値があればメガバイト単位のパスワードを送られるのを防げます。実際に使われる長さより十分大きく設定してください。NIST が許可を推奨する最小は64で、128や256がよく使われます。

ハッシュアルゴリズムに注意してください。bcrypt はパスワードの最初の72バイトしか読まず、残りは無視します。そのため、先頭が同じ2つの長いパスワードは互いのアカウントにサインインできてしまいます。1文字が複数バイトになることもあるため(é は2バイト、絵文字は4バイト)、72バイトは72文字より少ない場合があります。次のいずれかを行ってください。

• そのような制限のない Argon2id(または scrypt)を使う。
• 最大値を72バイトに収まる長さにする。
• 長いパスワードで bcrypt を使い続ける必要がある場合は、セキュリティチームが承認する方法で先にパスワードをハッシュ化する。

ルールをブラウザが読める場所に置く

<label for="password">Password</label>
<p id="password-rules">At least 15 characters. Any letters, numbers, symbols or spaces.</p>
<input id="password" name="password" type="password" autocomplete="new-password" minlength="15" maxlength="128" aria-describedby="password-rules" required />

• minlength と maxlength があれば、ブラウザが早めに警告でき、パスワードマネージャーは条件に合うパスワードを作れます。maxlength は貼り付けたテキストを黙って切り詰めるため、パスワードマネージャーが作る長さより十分大きく設定してください。
• autocomplete="new-password" は、パスワードマネージャーに新しい強力なパスワードを提案するよう伝えます。
• ルールは、間違えた後だけでなく、入力する前に表示します。
• 同じルールをサーバー側でも適用します。 ブラウザのチェックは便利なだけで、誰でも回避できます。
• 認証サービス(Supabase Auth、Clerk、Firebase Authentication、Auth0 など)を使っている場合は、その設定でも最小値を設定してください。多くは初期値がずっと短く、ページには15と書かれているのにサービスは6文字を受け付けるというのはよくあるバグです。

フォームが決めたとおりに動くか確認する

get_password_variants(MCP)、qa.passwordVariants()(npm)、GET /v1/variants/passwords(REST API)は、ルール(min_length、max_length、symbols を許可するかどうか)を受け取り、新しいテスト用パスワードを3つのグループに分けて返します。

注意すべきは72バイトのペアです。1つ目で作ったアカウントに2つ目のパスワードでサインインできる場合、アプリはパスワードを切り詰めています。

これらは手動でも、エージェントからでも、テストでも実行できます。

• 手動で: Proxy Mail QA for Chrome なら、パスワード欄のカードに 境界値パスワード が表示され、その欄の minlength と maxlength に合わせた「受け付けられるべき」と「拒否されるべき」のリストがあります。通常のパスワードもそのルールに合っています。
• エージェントから: Qoder で Proxy Mail QA を接続して(Marketplace):

Our password policy is 15 to 128 characters, any characters allowed. Using Proxy Mail QA,
get_password_variants with min_length 15 and max_length 128, and try each one on
https://staging.acme.dev/signup with a new test address (use a plus tag for each).
For accepted ones, verify the account and sign in with the same password.
Give me a table: what it tests, accepted or refused, the message shown, and whether
signing in worked.

• テストで: await qa.passwordVariants({ minLength: 15, maxLength: 128 }) は accept、reject、decide を返します。それぞれ { tests, value } のリストで、Playwright や Cypress でループ処理できます。

拒否されたパスワードでエラーがまったく表示されない場合は、登録フォームでパスワードのエラーが表示されないのはなぜですか?をご覧ください。

ここで Proxy Mail QA が行わないこと

• ポリシーを選ぶこと、または適用される法律や基準を満たしているかを判断すること。
• パスワードの保存方法の確認や、その他のセキュリティのテスト。それはセキュリティ審査やペネトレーションテストで行います。
• 漏えいしたパスワードのブロックリストのテスト。password1234567 などのよく知られたものをいくつか自分で試してください。

出典:NIST SP 800-63B-4、およびその認証器に関するセクション。