アカウント名:
パスワード:
パスワードの桁数を限定する理由がよくわかりませんよね。DB の定義を CHAR(8) にしてそのまま保存しているのでしょうか?ハッシュ化して保存するのであれば桁数なんて影響無いですし。
ちょっと不思議な出来事ですね。
例えば、昔の UNIX で、DES を利用した暗号化形式だと、ASCII の文字コード(7bit)をつなげて DES の鍵(56bit)して使う、という事をしているから、原理的に最大8文字で、もし、9文字以上のパスワードだったら、先頭から8文字文だけを使って DES の鍵とする、という事をします。
おもいっきり邪推すると、この「古典的な形式」でパスワードを保存していて、「9文字以上は切り捨て」とやっていたのを、「パスワード長が9文字以上だったら弾く」という処理を追加したのかな、と。 で、パスワード長を長くしたいと思った場合、「古典的な形式」とは言え、保存されているパスワード情報から平文を戻すには時間が掛かるし(本当にそうだとしたら、一応、ソルト付きなのでレインボーテーブルは使えないから、ブルートフォースしかない)、もし9文字以上のパスワードを設定している人がいても、実際に有効なのは8文字目までで、9文字め以降は、そもそも切り捨てられているから、仮に平文のパスワードを戻した上で、9文字以上が使える形式で保存しようとしても、ユーザが覚えている9文字目以降の文字が復元できないことになります。
で、一旦、9文字以上のパスワードを拒否することで、必ず8文字以下の状況を作り、その上で、パスワード長の拡張対応をするようにした、とか...。
ただ、もし、9文字以上にする予定があるのだとしたら、素直に、新規、及び、パスワード変更のタイミングで新しい形式で保存し、既存ユーザでパスワードを変更していない人には、変更を促すようにした上で、旧形式で認証する、というのが正しいと思うんだけど。
そういうのをなくすために PBKDF2 のような規格があると思うのですが、ちゃんと使っている所は少なそうですねぇ・・・
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
パスワードの桁数 (スコア:2)
パスワードの桁数を限定する理由がよくわかりませんよね。
DB の定義を CHAR(8) にしてそのまま保存しているのでしょうか?
ハッシュ化して保存するのであれば桁数なんて影響無いですし。
ちょっと不思議な出来事ですね。
Re:パスワードの桁数 (スコア:5, 参考になる)
例えば、昔の UNIX で、DES を利用した暗号化形式だと、ASCII の文字コード(7bit)をつなげて DES の鍵(56bit)して使う、という事をしているから、原理的に最大8文字で、もし、9文字以上のパスワードだったら、先頭から8文字文だけを使って DES の鍵とする、という事をします。
おもいっきり邪推すると、この「古典的な形式」でパスワードを保存していて、「9文字以上は切り捨て」とやっていたのを、「パスワード長が9文字以上だったら弾く」という処理を追加したのかな、と。
で、パスワード長を長くしたいと思った場合、「古典的な形式」とは言え、保存されているパスワード情報から平文を戻すには時間が掛かるし(本当にそうだとしたら、一応、ソルト付きなのでレインボーテーブルは使えないから、ブルートフォースしかない)、もし9文字以上のパスワードを設定している人がいても、実際に有効なのは8文字目までで、9文字め以降は、そもそも切り捨てられているから、仮に平文のパスワードを戻した上で、9文字以上が使える形式で保存しようとしても、ユーザが覚えている9文字目以降の文字が復元できないことになります。
で、一旦、9文字以上のパスワードを拒否することで、必ず8文字以下の状況を作り、その上で、パスワード長の拡張対応をするようにした、とか...。
ただ、もし、9文字以上にする予定があるのだとしたら、素直に、新規、及び、パスワード変更のタイミングで新しい形式で保存し、既存ユーザでパスワードを変更していない人には、変更を促すようにした上で、旧形式で認証する、というのが正しいと思うんだけど。
Re:パスワードの桁数 (スコア:1)
そういうのをなくすために PBKDF2 のような規格があると思うのですが、
ちゃんと使っている所は少なそうですねぇ・・・