  |
DBを設計する場合、パスワードのカラムを何文字にするか決めなければならない
これを最大2万文字とかにできなくもないが、DB容量を圧迫するといった理由で8文字や10文字に限定していてもおかしくはない
MongoDBのようなオブジェクトDBなら別だがSQL系のDBならこの理由が最もあてはまりそうに思う
同様の理由で文字種にも制限をかけてそう（UTF-8とか送られたら面倒）
境界値テストとしては最大文字数を試さないといけないが無制限だとそれができなくなる
100文字でテストするとなると、仕様としては100文字が限界ということになって文字数制限をかけることになる
ただ、それなら8文字とかで制限している理由として弱い気がする
無制限ということは極端に言うと1GBのパスワードを受け付ける、ということになる
1GBのハッシュ値を計算するのはブラウザ側になるのだが、1GBのハッシュ値計算が重くて使えない、という苦情が来るかも知れない
ただ、これも1000文字とかにしてしまえば良くて、8文字にしている理由にはならない
ウォーターフォールで実装する場合に上位レイヤでの仕様を決めるのはプログラマーでない場合が多く
定型のエクセル仕様書に「パスワードの最大文字数」というセルがあって、そこにデフォルトで8という数字が入っている
上位レイヤで仮にそこに100とか1000とかの数字を入れたとき、下位レイヤで何が起こるかわからない
つまりそこに8と書いた人が現代にいるのではなく、誰も決定していないから文字数制限が起きている
下位レイヤでの実装側は平文保存の危険性を十分に理解しているのでハッシュ値（とソルトなど）を格納する
多分、仮説４だと思うが、仮説１でないことを信じたい。
確か bcrypt って 72文字の制限があるからだろ。
惜しい 72バイトね ASCII言語圏なら同じだろって？ うんまあそう
いうても今どきはbcryptに渡す前にパスワードをハッシュしとるやろ
それってエントロピーが下んねーか？
10
