■ 1. 主張と反論の概要
- パスワードを15文字に切り詰めて入力するよう案内されたことを根拠に、パスワードが平文で保存されていると主張する者がいる
- この主張は発生している事象と無関係であり、根拠がない
- 「切り詰めができる＝平文または復号可能な形式で保存されている」という推測に基づくが、サーバー側が既存の長いパスワードをわざわざ15文字に短縮更新する理由がなく、論理として成立しない
■ 2. ファクトチェック: SBIベネフィットシステムズの仕様変更
- 対象サービス: SBIベネフィットシステムズ（benefit401k）
- パスワードポリシーの変更内容:
- 変更前: 6桁～15桁の半角英数字
- 変更後: 10文字～64文字、英大文字・英小文字・数字・記号のうち3種以上の組み合わせが必要（2026年6月21日より適用）
- ログインフォームのmaxlength属性の変化:
- 変更前:
maxlength=15- 変更後:
maxlength=64■ 3. maxlength属性による問題のメカニズム
- HTMLフォームの
maxlength属性は、規定文字数を超えた入力をブラウザ側で黙って切り詰めて送信する- 旧仕様（maxlength=15）の下では、ユーザーが長いパスワードを入力しても、実際に登録・送信されていたのは先頭15文字のみであった
- 仕様変更（maxlength=64）後、以前に長いパスワードを登録したつもりのユーザーは、手動で15文字に切り詰めなければ以前のパスワードと一致しなくなった
- 同種の問題は2012年のNICOSでも発生していた
- パスワードの保存形式（平文・可逆暗号化・ハッシュ化）に関わらず、maxlengthによる切り詰めが発生していれば同じ問題が起きる
- すなわち、パスワードの保存方法とは一切関連がない
■ 4. 結論
maxlength属性を使用すると、ユーザーが入力したつもりの文字列と実際に送信される文字列が異なるという問題が生じるため、使用には注意が必要- バリデーションエラーとして失敗すべき入力が、黙って既定文字数に切り詰められたうえで成功扱いになる点が問題の本質
- 案内の不親切さに対する批判は正当であっても、平文保存の主張には根拠がなく、そのような根拠のない放言をする者の信頼性は低い