ありがちなパスワードを「強い」パスワードと判断してしまうパスワード強度メーター 28
あてにしてはいけないやつ 部門より
昨年、パスワードの強度を判定するツールの問題点が話題になったが、jQueryプラグインとして提供される人気のパスワード強度メーターでは現在もあまり改善されていないようだ（Naked Security、Guardian、Register）。
デジタルコンサルタント会社、英Compound EyeのMark Stockley氏は昨年、スラドで紹介したカナダ・コンコルディア大学の研究とは異なる方法でパスワード強度メーターを調査し、Naked Securityで結果を発表している。先日新たに掲載された記事によれば、前回の調査から1年以上たった現在も状況は変わっていないという。
判定に問題のあるパスワード強度判定ツールの弱点は、文字種や文字数の多さといったエントロピーにばかり注目するところだ。Stockley氏の行ったテストは、jQueryプラグインとして公開されているパスワード強度メーターで人気の高いもの5本を選び、よく使われるパスワード上位10,000件のリストから特定の条件を満たすパスワード5本を選んで判定させるというものだ。パスワード強度メーターはGoogleで「jquery strength meter」を検索し、上位5本を選んでいる。
選ばれたパスワードは「abc123 （14位、英字と数字の組み合わせで最上位）」「trustno1 （29位、英字と数字の組み合わせで2位）」「ncc1701 （158位、エンタープライズ号の登録番号）」「iloveyou! （8,778位、英数字以外の文字種が使われた中で最上位）」「primetime21 （8,280位、英字と数字の組み合わせで一番長い）」となっている。これらのパスワードはパスワードクラックツール「John the Ripper」で1秒以内にクラックできてしまうという。
これらのパスワードは確実に弱いパスワードだが、5本のパスワード強度メーターは少なくとも1つのパスワードでパスワード強度「中」と判定している。今回使用したパスワード強度メーターのうち2本は前回と同じものだが、前回とまったく同じ結果が出ている。今回はDropboxなどでも使われ、評価の高いオープンソースのパスワード強度メーター「zxcvbn」を比較対象として同じテストを行っており、こちらはすべて「非常に弱い」と判定したとのこと。
やっぱりDifiant (スコア:3)
NCC-1764と'-'も入れておく。
Re: (スコア:0)
ここに付けるのが良いか迷ったけど、
たまに見る a → @ o→0 と言った換字や スペース、ハイフン、アンダースコア、etcの変更
なんて操作は 人間よりプログラムの方が何千何万倍？も素早く楽々しらみつぶし
実行できる操作で、
単純な辞書攻撃プログラムにオプション実装されてても不思議じゃなく
パスワード強度向上には殆ど寄与しないと想像しているのだが、どうなんでしょうか？
よし (スコア:3, おもしろおかしい)
二つのパスワードを入力して戦わせる、パスワードバトラーを開発しよう。
＃ヒロインは男の娘で
Re:よし (スコア:2)
「強い」パスワードが共有されてしまう罠…
仕様の問題じゃない？ (スコア:2)
なにを強いとするか、なにを弱いとするか、仕様次第でしょう。
Re: (スコア:0)
よく使われるパスワード上位100件くらいは「強い」と判定しないような仕様が望ましいですね。
Re: (スコア:0)
しようと言ってしまえばそれまでなんですが実用性にかける仕様って意味があるんでしょうか。
私の場合そんなことを気にする時期は過ぎました。
Re:仕様の問題じゃない？ (スコア:2)
文字数文字種だけで強度を判定する仕様でも実用性あると思うけどなぁ。
手入力が前提で、不規則だけど(それ故に)あまり長くしたくないパスワードを作るときなんか凄い役に立つよ。
Re:仕様の問題じゃない？ (スコア:2)
だろうとなんだろうと、よくあるクラック辞書ですぐ破られるのは、強度があるとは言えないから、やっぱ問題
手入力が不規則っていう幻想は持つのはやめたほうがいい
# Abc!23がなんだって?
M-FalconSky (暑いか寒い)
Re:仕様の問題じゃない？ (スコア:3)
説明不足だったようで申し訳ない。
「不規則」というのはパスワードジェネレータで生成されたような文字列のことですね。
例えば今自分がツールで生成した「i>8q[Dptlj7lk6q[diw8@dvF」みたいなやつ。
まあ手入力前提の環境だとこう不規則で長いのはキツいので、こういう感じだけどもっと短いのを使うわけなんですが、それが自分の望むパスワード強度になっているかどうかをチェックするのには、文字数文字種だけで強度を判定する仕様でも十分じゃないかなという話です。
Re: (スコア:0)
強度ってのは攻撃に対する強度なので、攻撃手法が変われば強度算出の手法も変わります。
「文字数文字種だけ」の推定ってのは、概ね総当たり攻撃に対する強度ってことですよね？
しかし、「自分の望むパスワード強度」ってそれなのでしょうか？望みは一般的に行われる攻撃に対する強度ではないですか？
何をもって「一般的」とするかってのもありますが、少なくとも辞書攻撃を考慮しないのは片手落ちだと思います。
この記事ではtop10,000から選んだとありますが、1万なんて英小文字26種ですら3文字の組み合わせで既に越えます。
Re:仕様の問題じゃない？ (スコア:2)
辞書攻撃が有効だって分かってるのに辞書使ってパスワード作る方がちょっとどうかしてるんじゃないですかね。
判定サイトの辞書に載ってなければ攻撃者の辞書にも載ってないなんて保証も無いんだし、辞書攻撃をそもそも無意味にした方が良いのでは？
憶えやすいからって手を抜くからそこに付け込まれちゃうんですよ。
Re: (スコア:0)
いまさらだけど誤解する書き方でした。
「むしろ、ツールを使わず自分で作ったパスワードが実はあるあるだったとかを、辞書を使って検知する方がよっぽど有用に思います。」
というつもりでした。
1password (スコア:0)
zxcvbnを使っている（それだけじゃないらしいが）1passwordで試してみたらどれも最弱だった。
最後の数字を1文字消したほうが強度が高い評価だった。それでも弱いのだが。
iloveyouとiloveyou!は当たり前だがどっちも最弱。
タレコミにある通り、辞書が弱いのだろう。というか辞書使ってないのかも。
Re:1password (スコア:1)
選ばれたパスワード5個、zxcvbn.jsの中にしっかり書いてありますね。それは最弱判定出るわな…このテスト、パスワードチェッカーの搭載している辞書をテストしている以上の意味がないのではないだろうか。サンプル5個はあまりに少なくない？
Re: (スコア:0)
>Dropboxなどでも使われ
って間違ってはないけど、Dropboxが作ってるんだからそりゃ使ってるよね。
Re: (スコア:0)
すいません。1passwordはzxcvbnは使って無いみたい。
なんで勘違いしたのだろうか？
Re: (スコア:0)
zxcvbnのソース眺めてきたけど、英語圏にロックした辞書が入ってたよ。
キー配列でDvorakとかは入ってはいるが言語別になってないので記号群は全滅。
そして文字ごとの符号差(a,b,c,e→1,1,2みたいな)検出をやってるのに、
定形パスワード辞書の中に連番系のがぞろそろと……もったいねぇ……
パスワード+URL (スコア:0)
パスワードに、そのパスワードを聞いてくるサイトのURL文字列をつける方法があります。
一見強度が強そうに見えますが、サイトのURLは攻撃者も知りうる情報なので、案外弱いかも。
URLつける前の状態で十分な強度が必要ですね。
Re:パスワード+URL (スコア:1)
そもそもそのURLが毎回一緒とは限らないのでは？
なんかURLにトークンついてるときありますよね。
Re: (スコア:0)
これって別にWebサイトのログインパスワードに特定した話じゃないですよね。
Windowsのログオンパスワード等だったらURLは関係ないんでどうしましょう。
aaaaa (スコア:0)
パスワード強度…たったの5か…ゴミめ
Re: (スコア:0)
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa~
It's Over 9000!
Re: (スコア:0)
エラーメッセージさん「パスワードは○○文字以内にしてください」
Re: (スコア:0)
AppleのiCloudのパスワードは同じ文字2文字までみたいです。
pinで手垢に有利と思って（9000文字では無いですが）同じ文字
複数にしたら怒られました。
jquery上のって条件がきついんじゃ？ (スコア:0)
よくあるパスワードを例外処理して点数が低くなるようにするには、それを網羅したできるだけ大きな辞書を搭載しなきゃいけないが、ブラウザ上でっていう条件があると、チェック前に何ギガもデータをダウンロードさせるわけにもいかない。結局データが少なくてすむ（辞書から計算したn-gramの出現確率くらい？）エントロピー方式の判定法を使うくらいしかいい方法がなくて、特定の文字列の点数を下げさせるようないいアルゴリズムがないってことなんじゃないのだろうか。
もともとあった巨大な辞書データを、通信に耐えられるくらいに削減しているのだから、その分判定の鋭さはなくなってしまう。これは情報学的にも仕方ないことなのでは？
John the ripper が1秒以下で破れた Out-of-the-box の方法って、インクリメンタル法のことかな？色々やり方があるはずだけど、辞書法ではないよね？辞書から取り出した単語が辞書に入っているか調べるだけだったら、そりゃ1秒以下のはずだし…？
20XX年問題 (スコア:0)
なんかやたらとzxcvbnが持ち上げられてるから重箱の隅をつついてみた。
1900年より前の歴史上の日付とかはここには掛からないし、2020年以後も無視されるのであまり長く使うと漏れる。
recent_year: /19\d\d|200\d|201\d/g
こっちはこっちで2050年と境界値が一致してない。
DATE_MAX_YEAR = 2050
キーボード上の連続判定用ぽいデータは英字配列固定、かな。JPキーボードで記号列使うと抜けれそう。
adjacency_graphs =
qwerty: {"!": ["`~", null, null, "2@", "qQ", null], …
コード中に辞書ゴリ押し…まぁ仕方ないんだけど、容量と強度のバランスは見合う物にできるのかどうか。
というか、文字差分検出も実装してるっぽいから12345678みたいなのは辞書不要だろ、容量的に件数厳しいのにこんなの入れるな。
frequency_lists =
passwords: "123456,password,12345678,qwerty…
英語圏以外の名前は辞書マッチしない可能性が高そうなので、英語圏以外ではちょい不味い。
female_names: "mary,patricia,…
male_names: "james,john,robert,…
サニタイズ言うなとか言われないかな(ドキドキ)
sanitized_inputs = []
メッセージとかも英語だから英語圏以外で使うならローカライズもしないと微妙？
trustno1 (スコア:0)
trustme!にしとけば良かったかもしれないのに