Skip to content

Instantly share code, notes, and snippets.

@mala
Created July 3, 2026 09:33
  • Select an option

Select an option

パスワード入力のmaxlengthで長いパスワードで登録できたつもりになってた問題2026

2012年版 https://gist.github.com/mala/4129717

https://togetter.com/li/2716116

15文字に切り詰めてパスワードを入力せよという案内を元に、なぜかパスワードが平文で保存されているという主張をする人がいる。これは全く発生している事象と関連がなく、根拠がない。

パスワードを任意の長さに切り詰めることが出来るということは平文あるいは復号可能な形式で保存されているからという推測のようだが、そもそも常識的に考えて、元々長かったパスワードが登録されていたところに、サーバー側で15文字の短いパスワードに勝手に更新する必要性がどこにあるというのか。そのような仕様変更を何のために行うというのか。

ファクトチェック

以前は15桁に制限されていて最近仕様が変更されたのはSBIベネフィットシステムズでその前提で調査する。

パスワードは10桁~64桁まで設定できます。 ※セキュリティ強化に伴い、2026年6月21日よりルールが変更となりました。

現行の登録時の説明 "なお、パスワードは10~64文字で、英大文字・英小文字・数字・記号のうち3種以上を組み合わせることが必要です。"

古いバージョン "なお、パスワードは6桁から15桁の半角英数字であることが必要です"

入力フォームがどうなっていたのかを調べる。

現在はmaxlength=64が設定されている

一つ前のバージョンだとmaxlength=15

2012年にNICOSで起きていたのと状況として同じで、maxlengthによって、もとよりユーザーが登録したかったパスワードが全桁有効でなかった。64文字までパスワードを受け付けるようになったため、以前長いパスワードを登録したつもりになっていたユーザーは、手動で15文字に切り詰めないと以前のパスワードと一致しなくなった。

maxlengthによって元から切り詰められた文字数のパスワードが登録されていた場合、平文で保存されていようと可逆暗号化だろうとハッシュ化だろうと等しく同じ問題が起きる。つまり、どのようにパスワードが保存されているかとは、一切関連がない。

結論

maxlengthを使うと入力したつもりの文字列と、実際に送信される文字列が異なるということが起きるので、使い方には注意をしたほうが良いでしょう。バリデーションエラーとして失敗すべきところが、黙って既定文字数に切り詰められて成功することになる。

案内が不親切であろうといった批判は正当であっても、平文で保存されているという主張には何ら根拠がなく、そのような放言をする人は信用しないほうが良い。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment