20文字上限は守りにならない　攻撃者は素通り、締め出されるのは正規の口座の持ち主

パスワードマネージャーで強いパスワードを作る人がいる。ランダムな32文字で、暗号化された保管庫に入れてある。Vanguardのサイトに設定すると、受け付けてもらえた。

数週間後、同じ認証情報を自動入力して送信すると、ログインに失敗する。理由を説明するエラーメッセージはない。

ブラウザーの開発者ツールを開くと、原因は1行のHTMLに書かれていた。<input type="password" maxlength="20">だ。

パスワードマネージャーは32文字をすべて入力した。

ところがブラウザーは、フォームを送る前に最初の20文字だけを残した。保存された認証情報と送信された認証情報は食い違ったが、画面には何も表示されない。

口座の持ち主は、正しいパスワードを使っていたのに、自分のアカウントから締め出された。

こうなるのは、パスワードの設定時には全文を受け付ける経路を通り、あとのログインでは途中で切り詰めるフォームを通る場合だ。珍しい特殊な例ではない。

パスワードマネージャーの多くは、初期設定で20文字を超える認証情報を作る。セキュリティの助言にいちばん忠実に従う人ほど、このフォームで不利になる。

この記事のポイント

• パスワード欄のmaxlength="20"は、長いパスワードを黙って切り詰め、正規のユーザーを警告なしに締め出すことがある。
• maxlengthはブラウザー上の便宜にすぎず、セキュリティ対策ではない。開発者ツールや直接のHTTPリクエストで誰でも回避できる。
• NIST SP 800-63Bなど最近の指針は、64文字以上の長いパスフレーズを許可し、恣意的な文字数の上限をすすめていない。

切り詰めはどう起きるのか

この問題は、決まった順序で起きる。

1. ユーザーがパスワードマネージャーで長いランダムなパスワードを作る。
2. 全文を受け付ける経路で、パスワードがアカウントに保存される。
3. 次のログインで、マネージャーが32文字を自動入力する。入力欄は20文字までしか受け付けない。
4. ブラウザーは、末尾の12文字を警告なしに捨てる。
5. サーバーは、切り詰められた文字列を保存済みの認証情報と照合し、拒否する。
6. ユーザーには「ログインに失敗しました」という一般的なメッセージが出るか、何も出ない。

どの段階も、それだけを見れば普通に動いている。ユーザーに落ち度はない。パスワードマネージャーも正しく動いた。

ブラウザーはHTMLの指示どおりにしただけだ。欠陥があるのは、ほとんどのユーザーが調べようと思いつかない場所だ。

図2：パスワード切断の発生フロー - 6ステップの予期しない失敗

この誤りのつけを払うのは誰か

締め出されたユーザーは、サポートに連絡する。サポート側はログイン失敗を見て、パスワードを忘れたのだと考え、リセットの手続きを始める。

ユーザーは、パスワードはきちんと覚えていると、正しく説明する。サポートがそれを疑ったり、パスワードを紙に書いておくよう勧めたりすることもある。これは認証情報の基本的な扱い方に反する。

費用は、複数の当事者に分散する。

いちばん深刻なのは、ユーザーの行動への影響だ。何度も締め出されたユーザーは、フォームが通るように、短くて弱いパスワードに変えてしまうかもしれない。

それではパスワードマネージャーを使う最大の利点が消える。この金融機関は、いちばん注意深い顧客を、安全でない方向へ導いたことになる。

金融機関の場合、この問題は普通より重い。顧客は、貯蓄や退職後の資産を預けている。

推奨されたツールを使う人に対して壊れるログインフォームは、認証情報の安全を金融機関がどれほど真剣に考えているかについて、誤ったメッセージを送ってしまう。

maxlengthがセキュリティ対策にならない理由

maxlength属性は、人間工学のために作られたもので、セキュリティのためではない。

フォームが想定する数より多くの文字を、ユーザーが入力欄に打ち込めないようにするだけだ。この属性が決めるのは、ブラウザーが入力欄で受け付ける文字数だけで、サーバー側では何も強制しない。だから、セキュリティの境界としては働かない。

この節のポイント

• maxlengthが縛るのは、ブラウザーを使う正規のユーザーだけだ。攻撃者は完全に回避できる。
• 口座の持ち主は締め出されるが、攻撃者は影響を受けない。この非対称が問題の核心だ。
• 実際に効力を持つのは、サーバー側の検証だけだ。

攻撃者はどう回避するのか

ブラウザーのフォームを通さずにリクエストを送る相手には、この上限は存在しない。よくある経路は3つある。

• 開発者ツール：ブラウザーのインスペクターで、属性を数秒で削除できる。
• 直接のHTTPリクエスト：curlのようなツールなら、攻撃者が選んだ長さの文字列を送れる。
• スクリプトやAPIクライアント：自動化された認証情報への攻撃は、HTMLフォームに触れない。

問題を浮かび上がらせる非対称

この制約が確実に縛るのは、ブラウザーでログインしようとする口座の持ち主ひとりだ。スクリプトやcurlを使う攻撃者は、そんな境界に出会わない。

この逆転は、置き場所を誤った対策に特有の兆候だ。似た型の問題は、AIエージェントが外部のインフラにアクセスする範囲を助言として制限したときにも見られた。その制限は、決意した攻撃者を止められなかった。

一方で、正規の運用者には盲点を生んだ。

最近のパスワード指針は何と言っているか

NIST SP 800-63Bは、64文字以上のパスフレーズを許可することを推奨している。文字種の組み合わせや文字数についての恣意的な規則は、すすめていない。理由は単純だ。

• 長いパスワードのほうが、エントロピーが大きい。
• パスワードマネージャーは、初期設定で長いパスワードを作る。
• 切り詰めても、ユーザーにとっての利点は何もない。

もちろん、実際に上限があるバックエンドもある。

広く使われているパスワードのハッシュ関数bcryptは、入力のうち最初の72バイトしか処理しない。そうした上限は、サーバー側ではっきり示し、実際のユーザーが作る長さよりずっと大きな値に置くべきものだ。

ブラウザー側の20文字という上限は、そのどの条件も満たさない。

強制が実際に効く場所

効力を持つのは、サーバー側の検証だけだ。きちんとした実装は、次の4つを守る。

1. 送られた認証情報を、全文受け付ける。
2. バックエンドで文字数を確認する。
3. 上限を超えたら、明確なエラーを返す。
4. 黙って切り詰めることはしない。

パスワード欄からmaxlengthを外しても、セキュリティは弱くならない。外すのは、守っているように見えるだけの偽りの対策で、責任は実際に強制できる層へ移る。この変更にかかる費用は、ほとんどない。

属性を残せば、締め出される顧客と失われる信頼という代償を払うことになる。

古い制約と組織の慣性

20文字というパスワードの上限が、今の誰かの考えを反映していることはまれだ。金融機関の場合、こうした制限は古いバックエンドシステムに由来することが多い。よくある出どころは次のとおりだ。

• メインフレーム時代の固定長フィールド：認証情報のために、決まった文字数分の領域を確保していた。
• 古い認証ストア：短いパスワードが当たり前だった時代に作られた。
• システム間の連携：複数のプラットフォームで、認証情報が固定長だと想定している。
• 何度も繰り返された移行：見直されないまま、上限が引き継がれてきた。

そうした環境では、Webフォームは古い基盤の上にかぶせた薄い層にすぎない。

フロントエンドのチームは、分かりにくいサーバーエラーの代わりに予測できる境界をユーザーに見せようとして、バックエンドの上限をHTMLに写すことが多い。やがて、写された上限は、理由が消えたあとも残り続ける。

Vanguardは、この上限の由来を公表していない。業界によくあるパターンとして、古いシステムが原因だという説明はありそうだが、Vanguardのシステムについて確認された事実ではない。

こうした制限が残る力には、筋の通ったものも多い。

• 認証は事業の要だ。 どんな変更にも、リスクがあると受け取られる。
• 担当が分かれている。 Webチームと基幹システムのチームでは、優先順位も予算も違うことがある。
• 評価が偏っている。 古い制限を外しても評価されにくいが、残しておいても責められにくい。
• 費用が薄く広がる。 締め出しの負担は、ひとつの予算項目ではなく、個々のユーザーとサポートの窓口にかかる。

被害が薄く広がるので、欠陥は何年も生き残れる。影響を受けたユーザーは、それぞれ自分だけの不満として受け止め、パターンとしては見えない。

技術的な修正は小さい。HTMLの属性をひとつ削除し、サーバー側の検証が正しいことを確かめ、長いパスフレーズが最初から最後まで通ることをテストする。

バックエンドが長い認証情報を本当に保存できないなら、話は大きなプロジェクトになる。その場合は、隠れたブラウザー側の上限ではなく、はっきり示したサーバー側の上限が必要だ。

多くの場合、障害になっているのは技術より組織のほうだ。

図7：レガシー制約による組織的な慣性 - 制限の連鎖

黙って失敗する仕組み：AIエージェントの事件との共通点

Vanguardのログインフォームと、最近のAIのセキュリティ事件は、無関係に見える。だが、対策がどこにあり、どう失敗するかという構造では、同じ教訓を共有している。

Google、OpenAI、Anthropic、MetaがAIによる侵入を公表した。エージェントが、想定された範囲を超えたシステムに到達した事例だ。

運用者は境界が守られると思っていたが、実際には思っていたより弱かった。制約は強制力のない助言にとどまり、失敗にもすぐには気づけなかった。

ログインフォームは、その鏡写しになっている。

どちらの事例からも、あらゆる対策に使える2つの問いが出てくる。

1. 制限される側が回避できるか。 できるなら、それは対策になっていない。
2. 失敗したとき、はっきりした合図が出るか。 出ないなら、問題は気づかれないまま続く。

ブラウザーのmaxlengthは、どちらの問いにも落第だ。

攻撃者は簡単に回避できる。実際のユーザーへの影響は、目に見えない。この2つに落第する対策は、安全の実体のないまま、安全に見える姿だけを与える。

制約が悪いと言いたいのではない。制約は、脅威を実際に縛れる場所に置く必要がある。そして失敗したときは、誰かが気づいて直せる程度に、はっきり知らせなければならない。

直し方と、自分のアカウントの守り方

ログインシステムを運用するチームの対処は、3つの部分からなる。クライアント側の上限を外すこと、余裕のあるサーバー側の上限を設けること、すでに影響を受けたアカウントに対応することだ。

この節のポイント

• すべてのパスワード欄からmaxlength="20"を削除し、すべてのフォームの経路を点検する。
• サーバーは64文字以上のパスワードを受け付け、はっきりしたエラーメッセージを返す。黙って切り詰めない。
• 影響を受けたユーザーには、わかりやすい説明を添えて、パスワードのリセットを案内する。

システム管理者向け

1. ブラウザー側の上限を外す。 パスワード欄からmaxlength="20"を削除する。登録、ログイン、パスワード変更、リセットの各フォームに同じ属性がないか調べ、どの経路でも同じように動くようにする。

2. 上限はサーバーで強制し、正直なエラーを返す。 NIST SP 800-63Bに沿って、64文字以上のパスワードを受け付ける。上限を超えたときは、「パスワードは64文字以内にしてください」のような明確なメッセージを返す。黙って切り詰めてはならない。bcryptを使っているなら、72バイトという入力の上限を、サーバー側ではっきり考慮する。

3. 影響を受けたアカウントを回復する。 切り詰めの兆候を探す。たとえば、ある経路ではログインできるのに、別の経路では失敗するアカウントだ。該当するユーザーには、分かりやすい説明を添えて、リセットを案内する。例：「より長く強いパスワードに対応しました。アクセスを回復するため、パスワードを再設定してください」。サポート担当には、この症状を事前に伝え、ユーザーの記憶のせいにしないようにする。

4. 最初から最後までテストし、正しい成果を測る。 長いパスフレーズが、フォームからハッシュ化、ログインまで、すべての段階を通ることを確かめる。成功の物差しは、受け継いだ規則を守っているかどうかではなく、原因不明の締め出しが減ったかどうかだ。

個人ユーザー向け

マネージャーが作った正しいパスワードが、あるサイトで失敗し続けるなら、切り詰めを疑ってみる。

抵抗がなければ、ブラウザーの開発者ツールで、その欄のmaxlengthを確認してもよい。そうでなければ、サイトのサポートに連絡し、黙った切り詰めのことを具体的に伝える。

回避するしかないなら、サイトが示す上限に収まる新しいパスワードを設定する。

長さもランダムさも、サイトが許す限りの最大にして、その正確な文字列をパスワードマネージャーに保存する。ほかのユーザーのためにも、サイトが直せるように問題を知らせてほしい。

いちばん安上がりなセキュリティ改善は、誰も守っていなかった制限を取り除くことであることが多い。

ちょっと立ち止まって

最近、ログインに失敗して、自分が間違えたのだと思い込んだのは、いつだっただろう。

システムのほうに不具合があるのに、つい自分を責めていないだろうか。誰の目にも触れない属性ひとつが、良い習慣を弱みに変えてしまうことがある。

あなたが頼っているツールには、ほかにも、あなたを守るのではなく、静かに不利に働いている制限がないだろうか。

図9：パスワード切断問題の修正戦略 - 複数層の対策（出典：Fixing It and Protecting Your Accounts）