「大文字小文字が必須です」はパスワードを脆弱にする 68
ストーリー by hylom
8文字制限がもうダメ 部門より
8文字制限がもうダメ 部門より
あるAnonymous Coward曰く、
パスワードを強化するために「大文字/小文字/数字/記号を含めてください」といったサイトはよく見られるが、文字種を制限してしまうとすべて小文字/すべて大文字といった組み合わせが無くなるため、結果的に総当たり攻撃に弱くなるという（Webroot、lifehacker）。
特に文字数が8文字のように短い場合、上記全ての文字種を含めるようにすると、組み合わせ数が41%も減ってしまうという。対策としては文字種を増やすのではなく、パスワードをより長くすべきとしている。
こういうことか (スコア: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)
どうでもいい（そして、正しい作法に従ったパスワード管理されているか疑わしい）サービスのアカウントの登録とかは、
(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)
# 最小文字数こそ設定すべきだと思うのだが……
パスワード文字数でオーバーフローが実装される予感
# 駄目なやつは斜め上でやらかすものだもの
良かれと思ったことが裏目に出る (スコア:2)
"パスワードをxx日毎に更新してください。"とかも脆弱性の元
Re:良かれと思ったことが裏目に出る (スコア:2, すばらしい洞察)
そもそもパスワードをユーザー自身に決めさせるのが良くない。
Re: (スコア:0)
http(s) に公開鍵暗号方式が標準で欲しいとだいぶ前から思ってる。
Re: (スコア:0)
クライアント証明書じゃ駄目なの？
Re:良かれと思ったことが裏目に出る (スコア:2)
じゃ駄目っていうか、この文脈だとそれ同一のものを指してない？
そりゃあ組み合わせは増えるかもしれないが (スコア:1)
もしユーザーに全部大文字や小文字にしたがる傾向があるとすれば、組み合わせ数が増えるメリットより、
まず全部小文字・全部大文字で試行するブルートフォースアタックを受けたときの危険性増大というデメリットのほうがでかくなる。
元記事にある、「（パスワードを文字にするという）制約で1文字から7文字の長さのパスワードがすべて無効とされるからです。
それによって、パスワードを破るのに必要な時間がなんと2277秒、つまり38分弱も短くなります（3548分に対して）」というのも同じ。
「8文字じゃなくてもいいです」って言った日にゃ、3文字や4文字のパスワードに設定したバカが出てくるのがオチ。
「長いパスワードを使え」って結論はいいと思うけど、その前フリにしてもコレ必要な指摘か？って感じ。
水は低きに流れる (スコア:1)
まったくもって同意。
そもそも何も制限かけてなきゃ、楽なパスワードに逃げる人も増えるだろうから、英子文字のみのブルートフォースでも結構当たりを引けたりする。
そうなると、26通り^8桁 = 2088億通りくらいをまずは試せばよくなる。
でも、組み合わせを強制すると、最大パターン数からは多少目減りはするとしても、数千兆通りにまで増えるなら十分に効果はあるよね。
Re:水は低きに流れる (スコア:1)
あ、ACで投稿しちゃった...
Re: (スコア:0)
ブルートフォース・辞書攻撃できる時点で負け
Re: (スコア:0)
プラス辞書チェックは必要かもですね
パスフレーズ的には、辞書にある単語単品はNGだけど、ちょっと組み合せるのは強いのでアリという所かな
例
弱い celebrate
強い celebrate1231DOGBirthDay
https://password.kaspersky.com/jp/ [kaspersky.com]
で確認したら「よく使われる文字組み合わせがあります」は出るが
このパスワードは、一般的な家庭用コンピューターを使って 次に示す期間のうちに解読されてしまいます
弱 12秒
強 6088世紀
でした。
M-FalconSky (暑いか寒い)
Re: (スコア:0)
辞書ワードで12秒かかるのはおかしいのでは。。。
Re: (スコア:0)
元記事がどうもそういう仮定らしいが、パスワードが8文字限定でそれより長くても短くてもいけないってケースは特殊なんじゃないか？通常ブルートフォースをやるなら、文字数によっては全文字種は計算量的に不可能になるから、記号を落とすとか、全て小文字に仮定するとか制限をかけるものだし、たいていのクラッカーにはそれ用のオプションがあるぞ。全て小文字を許可すると、全て小文字にするユーザが必ず一定数いるという心理的な問題があるのを無視してないだろうか。
Re: (スコア:0)
>元記事がどうもそういう仮定らしいが、パスワードが8文字限定でそれより長くても
2018年発の大NTTデータ様のユーザ向けプロダクトのパスワードは8文字以下限定だった。下限は知らない
偉い人にはギリギリネジをまいといた（今までも何度もゆった）ので次回は更新されるかも。まあ５年後かな
パスワードを社内で共有するには (スコア:0)
弊社は
どうでもいいやつ ：特定ワード＋[0-9]+"!A"
普通：ランダムでユーザ別
本気：ちゃんとした長いランダムでユーザ別プラス隠し味
という運用です
なのに「パスワードなんだっったけけ？」「3 だよ 3」とかが飛び交ってばかりなのは何故かしら？
Re: (スコア:0)
共有パスワードといういかれた発想には疑問を持たないのだろうか？
Re: (スコア:0)
三省堂オンデマンド（例）とかのつもりだったのだが
アカウントもパスワード一個しかもちようないので
毎回全部ランダムにすべきところを手抜きしてるところを嗤って欲しかった
Re: (スコア:0)
別にいかれてない。複数人が同じ鍵を持つケースと別の鍵が必要なケースがあるだけの話。
Re: (スコア:0)
なのに「パスワードなんだっったけけ？」「3 だよ 3」とかが飛び交ってばかりなのは何故かしら？
共有パスワードといういかれた発想には疑問を持たないのだろうか？
今日言うパスワードなんですよ
配慮した記述 (スコア:0)
「大文字/小文字/数字/記号を含めてください」
を、よりセキュリティに配慮して書き直すと
「大文字/小文字/数字/記号をご使用になれます」
というわけですね。
Re:配慮した記述 (スコア:1)
>「大文字/小文字/数字/記号をご使用になれます」
それが普通だよね。
対策としては文字種を増やすのではなく、パスワードをより長くすべきとしている。
旧いシステムで、ながーいパスワード入れても最初の8文字しか認識されてないとか無かったっけ。
今は流石にそれはないか。
Re:配慮した記述 (スコア:1)
HIRATA Yasuyuki
Re:配慮した記述 (スコア:1)
つい最近までのVISAオンライン認証画面がそうでしたね。
Re: (スコア:0)
>旧いシステムで、ながーいパスワード入れても最初の8文字しか認識されてないとか無かったっけ。
昨今の話だと、モバイルSuicaの話かな？
アプデでパスワード20桁まで対応→内部は旧システム8桁のまま→ログイン不可大量発生
https://togetter.com/li/1269971 [togetter.com]
Re: (スコア:0)
それ「12345678」「ABCDEFGH」でもOKってことだよね？
Re: (スコア:0)
うん、オッケー
Re: パスワードをより長くすべきとしている。（タレコミ文） (スコア:0)
そう聞いたのでとあるパスワードを約20h文字に設定したんですよ。
そしたら毎回ながながしい文字列を入力するのが鬱陶しくって、当該サービスを利用する頻度が低下してしまって・・・
だから多少脆弱になっても頻繁にサービスを利用して欲しい、ってサイト側は思っているのかなと邪推。
Re: パスワードをより長くすべきとしている。（タレコミ文） (スコア:1)
複雑なルールはユーザビリティーの敵
ブラウザに覚えさせられればまだいいのだが、それができないようにされてると、記憶可能な簡単なパスワードにせざるをえなくなる
Re: (スコア:0)
トータル考えれば autocomplate=off は安全の担保になってないと思う
端末にアクセスされるようならキーロガーなりなんなりで終わるじゃない
単に不便にして安易なパスワードor安易な記録を推奨しているようにしか
Re: (スコア:0)
なってないよ
だから今のブラウザはautocomplate=offなんか無視してる
Re: (スコア:0)
その前にautocomplateって何だ
Re: パスワードをより長くすべきとしている。（タレコミ文） (スコア:2)
しかし > My great password is “cats and hippos are friends!”, みたいなのはAIに見破られるんじゃね？と危惧されている
「そこは『サーバルキャット』だろ、JK」と突っ込んでくるAIが出現するだろうか‥‥‥
salt的ななにかを1024bitぐらいにすれば (スコア:0)
レインボーには勝てる？
今のトレンドわがんね
銀行 (スコア:0)
数字４桁のパスワードのところもあったりするんだがどうなんだろうか？
口座番号やIPアドレスで不一致回数の上限を持っててロックするようにしているのだろうか？
そうするとパスワードが長い必要は無いだろうが、サーバー側の負荷が高くなる？
嫌がらせでロックされる事が多くなるのだろうか？
パスワード周りを決定する技術者は無能が多い (スコア:0)
そんな気がしませんか？
秘密の質問、定期的なパスワード変更、そして今回の文字種制限
強固なセキュリティと思って考えたのだろうけど、無意味あるいは逆効果だと否定されてる
そしてそんなものをどこもかしこも導入してる