アカウント名:
パスワード:
パスワードの桁数を限定する理由がよくわかりませんよね。DB の定義を CHAR(8) にしてそのまま保存しているのでしょうか?ハッシュ化して保存するのであれば桁数なんて影響無いですし。
ちょっと不思議な出来事ですね。
例えば、昔の UNIX で、DES を利用した暗号化形式だと、ASCII の文字コード(7bit)をつなげて DES の鍵(56bit)して使う、という事をしているから、原理的に最大8文字で、もし、9文字以上のパスワードだったら、先頭から8文字文だけを使って DES の鍵とする、という事をします。
おもいっきり邪推すると、この「古典的な形式」でパスワードを保存していて、「9文字以上は切り捨て」とやっていたのを、「パスワード長が9文字以上だったら弾く」という処理を追加したのかな、と。 で、パスワード長を長くしたいと思った場合、「古典的な形式」とは言え、保存されているパスワード情報から平文を戻すには時間が掛かるし(本当にそうだとしたら、一応、ソルト付きなのでレインボーテーブルは使えないから、ブルートフォースしかない)、もし9文字以上のパスワードを設定している人がいても、実際に有効なのは8文字目までで、9文字め以降は、そもそも切り捨てられているから、仮に平文のパスワードを戻した上で、9文字以上が使える形式で保存しようとしても、ユーザが覚えている9文字目以降の文字が復元できないことになります。
で、一旦、9文字以上のパスワードを拒否することで、必ず8文字以下の状況を作り、その上で、パスワード長の拡張対応をするようにした、とか...。
ただ、もし、9文字以上にする予定があるのだとしたら、素直に、新規、及び、パスワード変更のタイミングで新しい形式で保存し、既存ユーザでパスワードを変更していない人には、変更を促すようにした上で、旧形式で認証する、というのが正しいと思うんだけど。
そういうのをなくすために PBKDF2 のような規格があると思うのですが、ちゃんと使っている所は少なそうですねぇ・・・
昔電車内で聞いた世間話。
おばさんがパスワードを忘れたから、忘れた人用のページで再発行。「面倒くさいことさせられた上に、今までのパスワードと違うから何度も再発行しちゃった」「よくよく見てみたら勝手にパスワード変えられちゃってるのね。酷い話よ」「同じパスワードにしてくれないとまた忘れる。せっかく他の所とパスワード合わせてるのに」とこんな感じ。(要約)
パスワード忘れてないじゃん。
話を聞いてたらパスワードは『名前』とか『誕生日』とか『利用するサービス名』とかを組み合わせた何かしらの法則をもたせてたらしい。コレ書かないとイミフだったねごめん。
じじいの昔話じゃ.
昔はの, 9文字目より先は無視する, 「です」というやつが当たり前のようにのさばっていた時代があったんじゃ.
当時はいろいろ厳しい時代じゃった, 今の若いもんにいうてもピンとこんようじゃが.
その名残かもしれんのう.
これ結構知られてない(忘れられている・引き継がれてない)んですね。UNIXでも使われてたのに参考: http://www.atmarkit.co.jp/aig/02security/des.html [atmarkit.co.jp]
# 暗号化方式変えるための1ステップなのかなーって気がしないでもない
crypt関数のこと?DESのせいじゃないんだけど…
初期の crypt 関数は、前述の「DES を使って、パスワード文字列を不可逆な文字列にする」という処理をしていました。
今でも、この古典的な形式を扱えたと思いますが、今の crypt 関数はいろいろ拡張されて、MD5 や SHA-256 を使った形式にも対応している、といったのが現状です。 手前味噌ですが、glibc の crypt 関数が MD5 を使った時の処理 [hatena.ne.jp]を調べた事があります。 あと、DES を使った古典的な処理に関して、ここ [wikipedia.org]に記述がありました。
パスワードを DES の鍵として、固定の内容を暗号化、というのは分かっていたんだけど、その「固定の内容」は、上の Wikipedia の記述を読むと、オールゼロのデータだったんですね。(encrypt an all-bits-zero block)
やっぱ実装の問題で、DESのせいじゃないんだ。
よかった、やっぱ実装の問題でDESのせいじゃなかったのか。
うちの会社のイントラも、シングルサインオンが「セキュリティ向上のためにパスワードは8桁”ちょうど”だけに設定してください。」という謎システムになっています。情シスに「なんで8文字を超えたら駄目なのか?」と聞いても「セキュリティ上の理由でそうなってます」のコピペ回答しか返ってこず、しかたなく使ってますが…
「8文字を超えたら駄目なのか」じゃなくて「8文字以上が入力可能なシステムはむろんの事、8文字以下が入力可能なシステムよりもパスワードのバリエーションが少なく脆弱という見方も可能な状態なのだが、なぜセキュリティ向上などという嘘を付くのか」って聞いて見て欲しいな。# 任意のパスワードが設定可能な時点で、8文字以下もOKだと弱いパスワードで満足する奴が居るからって言い訳は通用しない。
8文字丁度なんて、攻撃する側からすればとても良い情報だよね。
そうでもない。
使える文字を ASCII 図形文字(英数記号と半角スペース)の 95 文字とすれば、
「8文字以下」が「必ず8文字」であった時に、少なくなるバリーションは、950 + 951 + 952 + .... + 957 = 70,576,641,626,496。減った割合は 70,576,641,626,496 / 6,704,780,954,517,120 = 1.05 %。 実は、大差ない。
「8文字以下」という事が分かっている事は大きな情報だけど、「必ず8文字」は意外にインパクトが小さい。
「セキュリティ上の理由」とは言ったが「セキュリティ向上」とは言ってない。
うん、なんだ、いま自分が扱ってるシステムがまさにコレなんだが・・・残念ながら理由はないんだでも理由はありませんとは言えんので適当に誤魔化すと「セキュリティ上の理由」になるんだ。
#旧システムから移行する際に根拠無く仕様だけ引き継いだ可能性が濃厚。
難しくてよくわかんないですが、bcrypt を使え!って事らしいです。http://yorickpeterse.com/articles/use-bcrypt-fool [yorickpeterse.com]
ハッシュは使っちゃ駄目みたいですよ難しくてよくわかんないですが、bcrypt を使え!って事らしいです。
この話ははじめて聞きました。興味深いので後でじっくりと読ませていただきます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
パスワードの桁数 (スコア: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 のような規格があると思うのですが、
ちゃんと使っている所は少なそうですねぇ・・・
Re:パスワードの桁数 (スコア:3, 興味深い)
昔電車内で聞いた世間話。
おばさんがパスワードを忘れたから、忘れた人用のページで再発行。
「面倒くさいことさせられた上に、今までのパスワードと違うから何度も再発行しちゃった」
「よくよく見てみたら勝手にパスワード変えられちゃってるのね。酷い話よ」
「同じパスワードにしてくれないとまた忘れる。せっかく他の所とパスワード合わせてるのに」
とこんな感じ。(要約)
Re:パスワードの桁数 (スコア:2, すばらしい洞察)
パスワード忘れてないじゃん。
Re:パスワードの桁数 (スコア:1)
話を聞いてたら
パスワードは
『名前』とか『誕生日』とか『利用するサービス名』とかを組み合わせた
何かしらの法則をもたせてたらしい。
コレ書かないとイミフだったねごめん。
Re:パスワードの桁数 (スコア:1)
じじいの昔話じゃ.
昔はの, 9文字目より先は無視する, 「です」というやつが当たり前のようにのさばっていた時代があったんじゃ.
当時はいろいろ厳しい時代じゃった, 今の若いもんにいうてもピンとこんようじゃが.
その名残かもしれんのう.
Re:パスワードの桁数 (スコア:2, 参考になる)
これ結構知られてない(忘れられている・引き継がれてない)んですね。UNIXでも使われてたのに
参考: http://www.atmarkit.co.jp/aig/02security/des.html [atmarkit.co.jp]
# 暗号化方式変えるための1ステップなのかなーって気がしないでもない
Re: (スコア:0)
crypt関数のこと?
DESのせいじゃないんだけど…
Re:パスワードの桁数 (スコア:3, 興味深い)
初期の crypt 関数は、前述の「DES を使って、パスワード文字列を不可逆な文字列にする」という処理をしていました。
今でも、この古典的な形式を扱えたと思いますが、今の crypt 関数はいろいろ拡張されて、MD5 や SHA-256 を使った形式にも対応している、といったのが現状です。
手前味噌ですが、glibc の crypt 関数が MD5 を使った時の処理 [hatena.ne.jp]を調べた事があります。
あと、DES を使った古典的な処理に関して、ここ [wikipedia.org]に記述がありました。
パスワードを DES の鍵として、固定の内容を暗号化、というのは分かっていたんだけど、その「固定の内容」は、上の Wikipedia の記述を読むと、オールゼロのデータだったんですね。(encrypt an all-bits-zero block)
Re: (スコア:0)
やっぱ実装の問題で、DESのせいじゃないんだ。
Re: (スコア:0)
よかった、やっぱ実装の問題でDESのせいじゃなかったのか。
Re: (スコア:0)
うちの会社のイントラも、シングルサインオンが
「セキュリティ向上のためにパスワードは8桁”ちょうど”だけに設定してください。」
という謎システムになっています。
情シスに「なんで8文字を超えたら駄目なのか?」と聞いても「セキュリティ上の理由でそうなってます」のコピペ回答しか返ってこず、
しかたなく使ってますが…
Re: (スコア:0)
「8文字を超えたら駄目なのか」じゃなくて「8文字以上が入力可能なシステムはむろんの事、8文字以下が入力可能なシステムよりもパスワードのバリエーションが少なく脆弱という見方も可能な状態なのだが、なぜセキュリティ向上などという嘘を付くのか」って聞いて見て欲しいな。
# 任意のパスワードが設定可能な時点で、8文字以下もOKだと弱いパスワードで満足する奴が居るからって言い訳は通用しない。
Re: (スコア:0)
8文字丁度なんて、攻撃する側からすればとても良い情報だよね。
Re:パスワードの桁数 (スコア:2)
8文字丁度なんて、攻撃する側からすればとても良い情報だよね。
そうでもない。
使える文字を ASCII 図形文字(英数記号と半角スペース)の 95 文字とすれば、
950 + 951 + 952 + .... + 958 = 6,704,780,954,517,120 通り。
「8文字以下」が「必ず8文字」であった時に、少なくなるバリーションは、950 + 951 + 952 + .... + 957 = 70,576,641,626,496。減った割合は 70,576,641,626,496 / 6,704,780,954,517,120 = 1.05 %。
実は、大差ない。
「8文字以下」という事が分かっている事は大きな情報だけど、「必ず8文字」は意外にインパクトが小さい。
Re: (スコア:0)
「セキュリティ上の理由」とは言ったが「セキュリティ向上」とは言ってない。
うん、なんだ、いま自分が扱ってるシステムがまさにコレなんだが・・・残念ながら理由はないんだ
でも理由はありませんとは言えんので適当に誤魔化すと「セキュリティ上の理由」になるんだ。
#旧システムから移行する際に根拠無く仕様だけ引き継いだ可能性が濃厚。
ハッシュは使っちゃ駄目みたいですよ (スコア:0)
パスワードの桁数を限定する理由がよくわかりませんよね。
DB の定義を CHAR(8) にしてそのまま保存しているのでしょうか?
ハッシュ化して保存するのであれば桁数なんて影響無いですし。
ちょっと不思議な出来事ですね。
難しくてよくわかんないですが、bcrypt を使え!
って事らしいです。
http://yorickpeterse.com/articles/use-bcrypt-fool [yorickpeterse.com]
Re:ハッシュは使っちゃ駄目みたいですよ (スコア:2)
ハッシュは使っちゃ駄目みたいですよ
難しくてよくわかんないですが、bcrypt を使え!
って事らしいです。
この話ははじめて聞きました。興味深いので後でじっくりと読ませていただきます。