アカウント名:
パスワード:
仮にパスワードが（8文字ではなく）4文字と決まっていたとする。
* アルファベット大文字(26種類)* アルファベット小文字(26種類)* 数字(10種類)* 記号(33種類)
として、4種の文字をを全て含める場合→26×26×10×33×4! = 5,353,920通り
文字種の制約がない場合→95^4 = 81,450,625通り
文字種の縛りを加えることによってパスワードの候補が大幅に減ってしまう（この例だと94%減る）。文字数を大きくすることでこの効果は小さくなっていく。つまりパスワードの最大文字数を最大8文字とか10文字とかに制約しておきながら文字種の縛りを加えているサイトはアホだということになる。# 最小文字数こそ設定すべきだと思うのだが……
長さ制限さえしなければ他に制限があっても個人的にはOKかな。１２文字とか１６文字とか、この辺りまでの制限があるサービス結構あるのよね。６４文字で登録したいのに。
1KiBとか2KiBとかあたりで長さ制限しておかないと、2時間の4k動画をBase64エンコードしたようなパスワード設定されちゃうから……
256bitなり512bitなりのハッシュを送信・登録するようにすればいいんじゃない？
「先頭〇〇〇〇文字まで認識します」でOK。
お前んとこではパスワードをハッシュ化しねえの？
当然ハッシュするだろうけど、認証の際に毎回GBクラスの文字列を送ってこられると困る、って話かと。
ハッシュ生成をサーバでやる場合、トラフィックは食われるな。まぁそんなもんパスワードじゃなくてもHTTPリクエストにゴミ載せて送りつけるだけで同じことだけど。
保存はハッシュでも照合するときは全部受け取ってハッシュしないといけないじゃん
どうでもいい（そして、正しい作法に従ったパスワード管理されているか疑わしい）サービスのアカウントの登録とかは、(date; ls -l) | md5sumとかで出てきたMD5の値をパスワードにして、アカウント登録確認メールを自分あてフォワードして、そこにパスワード書き込んじゃってるんで、32文字でいいや。
メールアカウントがやられたら全滅では？
全部で〇〇通りという理屈は、ユーザーがランダムにパスワードを生成している場合にしか通用しないよ
現実に、例えば「4桁以上10桁以下、文字種の縛りなし」のシステムを作ったら、可能な総数はだいたい 95^10 ≒ 6*10^19 通りでものすごく多いけど、ユーザーは面倒くさがって小文字だけで 4 文字のパス作るし、攻撃者もユーザーの心理を理解して 26^4 = 456976 通りで総当たり攻撃かけるよ
でも、縛りを入れればいいかと言うとそういうわけでもない例えば「8桁以上、文字種の縛り無し」から「8桁以上、大文字小文字の両方を使う」に変えたとして、2^8 = 256 倍安全になるかといえばそんなことはないユーザーは password → Password に変えてやり過ごすだけだから
何よりもまず大事なのは、8〜10桁以上の範囲で、ユーザーにパスワードのランダムな生成を強制すること文字種の縛りを入れる入れないなんてのは正直どっちでもいいレベルの些末な問題
こういう人になんて言って説明して上げるとわかってくれるんですかね
ムダ。だから解決策は文字数を増やすこと。人間はランダムな文字列なんて覚えられないから、意味のある単語を使う。ランダムな順列組み合わせの個数なんて、パスワードの安全性には寄与しない。＃JavaScriptとかLaTeXとかならまだしも、普通は「先頭のみ大文字」とかだろう。
エニグマ暗号機は最初に何文字かを初期設定する必用があるけど、「ランダムに設定すること」としてた陸軍は「はいるひとらー」を使う人が多くて、暗号解読チームは「はいるひとらー」に随分助けられたってさ。
＃乱数表を使ってた海軍の方は、解読できなかったとさ。偶然それを入手するまで。
完全に間違ったことを言ってるわけでもないよ。パスワードを長くしろ、人為を除いたランダムパスフレーズを強要しろパターン数を増やしたところで"password"を設定するバカは駆逐できない要約するとこんなところ。
4文字固定文字種自由の仕様だったら、10000回以内の試行で攻略できるユーザーはかなり多いと思いますよ。
password→Password→Passw0rd→P@ssw0rd→P@ssw0-d最後の1段階で一気にセキュリティレベルが上がった感じ
pasuwa-doもよろしく。
# 最小文字数こそ設定すべきだと思うのだが……
パスワード文字数でオーバーフローが実装される予感
# 駄目なやつは斜め上でやらかすものだもの
4文字以下と制限をゆるくした方がパスワードの候補は増えますが…候補の数だけで比べるのは、ユーザーがランダムなパスワードを作成する前提での話かとユーザーがランダムなパスワードを作成してくれないから、わざわざ混ぜる制限処理を入れたと思うし混ぜる制限をいれた人は減ることは気が付いてるはずだ、それよりもう少しランダムになった方がましと判断したんだろう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
こういうことか (スコア:5, 参考になる)
仮にパスワードが（8文字ではなく）4文字と決まっていたとする。
* アルファベット大文字(26種類)
* アルファベット小文字(26種類)
* 数字(10種類)
* 記号(33種類)
として、4種の文字をを全て含める場合
→26×26×10×33×4! = 5,353,920通り
文字種の制約がない場合
→95^4 = 81,450,625通り
文字種の縛りを加えることによってパスワードの候補が大幅に減ってしまう（この例だと94%減る）。
文字数を大きくすることでこの効果は小さくなっていく。
つまりパスワードの最大文字数を最大8文字とか10文字とかに制約しておきながら文字種の縛りを加えているサイトはアホだということになる。
# 最小文字数こそ設定すべきだと思うのだが……
Re: (スコア:0)
長さ制限さえしなければ他に制限があっても個人的にはOKかな。
１２文字とか１６文字とか、この辺りまでの制限があるサービス結構あるのよね。６４文字で登録したいのに。
Re:こういうことか (スコア:1)
1KiBとか2KiBとかあたりで長さ制限しておかないと、2時間の4k動画をBase64エンコードしたようなパスワード設定されちゃうから……
Re: (スコア:0)
256bitなり512bitなりのハッシュを送信・登録するようにすればいいんじゃない？
Re: (スコア:0)
「先頭〇〇〇〇文字まで認識します」でOK。
Re: (スコア:0)
お前んとこではパスワードをハッシュ化しねえの？
Re: (スコア:0)
当然ハッシュするだろうけど、認証の際に毎回GBクラスの文字列を送ってこられると困る、って話かと。
Re: (スコア:0)
ハッシュ生成をサーバでやる場合、トラフィックは食われるな。
まぁそんなもんパスワードじゃなくてもHTTPリクエストにゴミ載せて送りつけるだけで同じことだけど。
Re: (スコア:0)
保存はハッシュでも照合するときは全部受け取ってハッシュしないといけないじゃん
Re: (スコア:0)
どうでもいい（そして、正しい作法に従ったパスワード管理されているか疑わしい）サービスのアカウントの登録とかは、
(date; ls -l) | md5sum
とかで出てきたMD5の値をパスワードにして、アカウント登録確認メールを自分あてフォワードして、そこにパスワード書き込んじゃってるんで、32文字でいいや。
Re: (スコア:0)
メールアカウントがやられたら全滅では？
Re: (スコア:0)
全部で〇〇通りという理屈は、ユーザーがランダムにパスワードを生成している場合にしか通用しないよ
現実に、例えば「4桁以上10桁以下、文字種の縛りなし」のシステムを作ったら、
可能な総数はだいたい 95^10 ≒ 6*10^19 通りでものすごく多いけど、
ユーザーは面倒くさがって小文字だけで 4 文字のパス作るし、
攻撃者もユーザーの心理を理解して 26^4 = 456976 通りで総当たり攻撃かけるよ
でも、縛りを入れればいいかと言うとそういうわけでもない
例えば「8桁以上、文字種の縛り無し」から「8桁以上、大文字小文字の両方を使う」に変えたとして、2^8 = 256 倍安全になるかといえばそんなことはない
ユーザーは password → Password に変えてやり過ごすだけだから
何よりもまず大事なのは、8〜10桁以上の範囲で、ユーザーにパスワードのランダムな生成を強制すること
文字種の縛りを入れる入れないなんてのは正直どっちでもいいレベルの些末な問題
Re: (スコア:0)
こういう人になんて言って説明して上げるとわかってくれるんですかね
Re:こういうことか (スコア:1)
ムダ。だから解決策は文字数を増やすこと。
人間はランダムな文字列なんて覚えられないから、意味のある単語を使う。
ランダムな順列組み合わせの個数なんて、パスワードの安全性には寄与しない。
＃JavaScriptとかLaTeXとかならまだしも、普通は「先頭のみ大文字」とかだろう。
エニグマ暗号機は最初に何文字かを初期設定する必用があるけど、
「ランダムに設定すること」としてた陸軍は「はいるひとらー」を使う人が多くて、
暗号解読チームは「はいるひとらー」に随分助けられたってさ。
＃乱数表を使ってた海軍の方は、解読できなかったとさ。偶然それを入手するまで。
Re: (スコア:0)
完全に間違ったことを言ってるわけでもないよ。
パスワードを長くしろ、人為を除いたランダムパスフレーズを強要しろ
パターン数を増やしたところで"password"を設定するバカは駆逐できない
要約するとこんなところ。
Re: (スコア:0)
4文字固定文字種自由の仕様だったら、10000回以内の試行で攻略できるユーザーはかなり多いと思いますよ。
Re: (スコア:0)
password→Password→Passw0rd→P@ssw0rd→P@ssw0-d
最後の1段階で一気にセキュリティレベルが上がった感じ
Re:こういうことか (スコア:1)
pasuwa-doもよろしく。
Re: (スコア:0)
# 最小文字数こそ設定すべきだと思うのだが……
パスワード文字数でオーバーフローが実装される予感
# 駄目なやつは斜め上でやらかすものだもの
Re: (スコア:0)
4文字以下と制限をゆるくした方がパスワードの候補は増えますが…
候補の数だけで比べるのは、ユーザーがランダムなパスワードを作成する前提での話かと
ユーザーがランダムなパスワードを作成してくれないから、わざわざ混ぜる制限処理を入れたと思うし
混ぜる制限をいれた人は減ることは気が付いてるはずだ、それよりもう少しランダムになった方がましと判断したんだろう