アカウント名:
パスワード:
個人的なお話なのですが、僕はいくつかのパスワードを複数のシステムの中で適宜使い回しております。で、記号を含まないパスワードはなぜか見事に 7 文字と 17 文字ばかりで、一方、記号を含むと 14 文字とか 15 文字とかのパスワードもあります。
そしてなぜか今のところ、パスワードに記号を含めないことを条件にしているところばかり 8〜16 文字の制限があってヴァアアアですよヴァアアアア。
知らんがな。
＃原則論で言うならそもそも「パスワードを使い回すな」だし＃少なくとも文字数に関して文句言うことじゃない
でも文字数の上限はできるだけ多くすべきだよね
生パスワード入れる前提の容量計算も、大概なへっぽこだと思う
最もお手軽なハッシュsha1なら40Byteなので、40*10M = 400MBだね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
8〜16を考えた奴、本当出て来いよ (スコア:2, おもしろおかしい)
個人的なお話なのですが、僕はいくつかのパスワードを複数のシステムの中で適宜使い回しております。で、記号を含まないパスワードはなぜか見事に 7 文字と 17 文字ばかりで、一方、記号を含むと 14 文字とか 15 文字とかのパスワードもあります。
そしてなぜか今のところ、パスワードに記号を含めないことを条件にしているところばかり 8〜16 文字の制限があってヴァアアアですよヴァアアアア。
Hiroki (REO) Kashiwazaki
Re: (スコア:-1)
知らんがな。
＃原則論で言うならそもそも「パスワードを使い回すな」だし
＃少なくとも文字数に関して文句言うことじゃない
Re:8〜16を考えた奴、本当出て来いよ (スコア:1)
でも文字数の上限はできるだけ多くすべきだよね
Re:8〜16を考えた奴、本当出て来いよ (スコア:1)
ユーザ数1000万だと
255Bytes×10M = 2,550M = 2.5GBytes
2.5GBytesにしかならないじゃない。ユーザ数が10万だったら25MBytesにしかならないよ!?
まあ、パスワード文字列自体ではなくパスワードのハッシュを保存するはずだし、DBに保存する時には余計にディスク容量を使用するかもだけれどもこのくらいのオーダーだよね。
パスワード文字列に長い文字数を許可すると「パスワードがわからなくなるユーザの割合が増えて、ユーザサポートが大変になる、だからヘッポコパスワードにして楽にサポートできるようにしよう」なのかなぁ?
仕様決定の際に、何もわからない上役が「その方が安くできるんだろ?」みたいな感じで仕様を押し付けたんだろうか。
JALとANAの場合には特殊な企業文化が主な理由で、ヘッポコパスワード仕様が決められたんじゃないかと思ってしまっています(私の偏見ですが)。
Re: (スコア:0)
生パスワード入れる前提の容量計算も、大概なへっぽこだと思う
Re:8〜16を考えた奴、本当出て来いよ (スコア:1)
素晴らしい、ヨロシクお願いします！
Re: (スコア:0)
最もお手軽なハッシュsha1なら40Byteなので、
40*10M = 400MB
だね。