アカウント名:
パスワード:
> 現代ではパスワードクラック技術が向上しておりそれ技術の向上と関係あるの?
元々、耐性としては・長さが一番・複雑さが2番だったんだが、昔は長いのが入れられないことも多かったし、クラック技術も未熟だったのでそこまで耐性が求められず、長いのは打つのがだるいからか覚えにくいからか、複雑なパスワードが好まれた。# どっちが先か知らないが、昔は「長いパスワード」が入れられるシステムが少なかったし
今は複雑なだけでは対クラック性が足りなくなり、長さが必要になってきた
長いほうがいい、開き直ってしまえばパス「ワード」は諦めてパス「フレーズ」パス「センテンス」にすりゃ少々長くても間違えない忘れないからそんなにコストは上がらないし、はじめっからこっち薦めておけばよかった
って事でしょう
昔はメモリやストレージが高価で節約が美徳だったから、折角同じ7bit ASCIIなら8文字くらいに収めてユーザには記号で複雑さを稼いでもらうというのが当然だった鍵長と考えれば英数大小と記号で8文字なら7*8=56bitに対して、記号を抜いて16文字なら6*16=96bitだからな
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどなハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
ハッシュの長さが短くてパスワードの長さに制限がなければ同じハッシュを再現できる可能性が高まるので、やはりパスワードの入力長は制限があったほうが良いと思う。
> ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
そんなことはまったくない
たとえば「1」というパスワードを使った場合、ハッシュ値はそこそこ長くなるが、悪意あるものがブルートフォースで攻撃し始めた途端に攻撃が成立するパスワード(=ハッシュ値が一致する文字列、今回の場合は「1」)を割り出せてしまう
ハッシュにしたとしてもパスワードのデータ長をある程度長くすることは必要
実際に、「パスワードフィールドには長々と文字を入力できるが、実際には過去互換性のためそのうち先頭8文字しか使わない仕様だった。 そのうえで内部への保存はパスワード平文ではなくハッシュ値だった。 結果としてパスワード長8文字を超える強度のパスワードは使えない仕様だった」という仕様だったOS(というかAPI仕様)は存在する
という話の流れで、
たとえば「1」というパスワードを使った場合、ハッシュ値はそこそこ長くなるが、悪意あるものがブルートフォースで攻撃し始めた途端に攻撃が成立する
>だったんだが、昔は長いのが入れられないことも多かったし、
銀行ATMは今でも数字4桁ドコモの認証も一緒年寄りはほぼみんな生年月日に設定それ以外は覚えられないから
サーファーは 1173 が多いんだとか
良い波->イイナミ->1173
だそうです。
…ということは、肉好きは 1129になるのか?!なんて連想してしまいました。
銀行ATMにしろ、ドコモの認証にしろ、・一定回数間違えたらアカウントにロックかけることでブルートフォースへの対策にしてる・ATMであればキャッシュカード必須だし、監視カメラのあるATM機にアクセスするので足がつきやすい・ドコモの認証は、ドコモの回線からの接続に限定し、さらにICCID単位でロックをかけられるので、ブルートフォースをで攻撃できるIDが非常に限定的という要素を無視して、単なる数字4桁の脆弱さと同一視するのはいかがなものかと。
> それ技術の向上と関係あるの?
総当たり攻撃を考えれば、関係あると思います。しかし、後述するように現時点ではどうかと思いますが。
例えば、英大文字・小文字・数字・記号が 26+26+10+15=77 種類だとして、良くある最低 6文字だとか 8文字だとかと、英小文字のみの 12文字、英小文字数字の 12文字を比較すれば、
77^6 ≒2.1×10^11 英大文字・小文字・数字・記号 6文字 77^8 ≒1.2×10^15 英大文字・小文字・数字・記号 8文字 26^12≒9.5×10^16 英小文字のみ 12文字 36^12≒4.7×10^18 英小文字・数字 12文字
ただ、「複数の英単語を単純に並べた文字数の多いパスワード」はこれを想定した攻撃を考えると、12文字程度では足りない気がします。仮にパスワードに使用する単語の語彙が 1万とすれば、3語では 10^12、4桁以下の数字(11110通り)を入れても 3語では、9.4×10^12 にすぎません。少なくとも 4語は必要と思われます。これは 12文字では足りませんが、パスワード文字数に制限があるサイトも多いので、難しいように思います。
10,000^3=1.0×10^12 英単語1万語から 3語 10,000^4=1.0×10^16 英単語1万語から 4語 (10,000+11,110)^3≒9.4×10^12 英単語1万語と4桁以下の数字から 3語 (10,000+11,110)^4≒2.0×10^17 英単語1万語と4桁以下の数字から 4語
したがってパスワードの文字数に上限がある場合も多いことを考えると、単語や数字だけでは不足で、例えば好きなフレーズの単語先頭文字とかを入れるべきでしょう。
しかし、昨今では、パスワードを共有する相手サイトごとにパスワードを変えるべきですから、「複数の英単語を単純に並べた文字数の多いパスワード」はすでに時代遅れでは?と思います。サイトごとに異なるパスワードの自動生成を一部なりとも導入すべきでしょう。
# 計算に間違いがあればご指摘願います。
同感です。
さらに、単語の使用頻度は単語ごとに非常に差があり、頻出単語で考えるとせいぜい語彙は数千程度、さらに文法や慣用句を考慮した予測も利用可能であることを考えると、長いパスフレーズの複雑さを、12文字程度の複雑なパスワードより高めるには、それなりに長いパスフレーズにする必要があると思います。
で、これをサービスごとに別々に考える必要がありますと。
結果として、有名な歌詞の一部などを使い始める人が出てきて、パスワード時代と同じ議論にならないでしょうか。
「パスフレーズなら予測困難なパスワードが容易に作成できる」「パスフレーズなら覚えやすいためPostItに書かずに済む」…本当ですかね?
NIST のガイドラインを読むと,文字数に関しては,システム側は最低8文字をユーザーに要求して,ユーザーが望むならば64文字までは許容するべきである.とかかれていますね(上限は設けないものの,ユーザー側からMB級の文字列を入力されると,ハッシュの計算量が増大になるのでシステム側で制限が必要と注あり).
一方で,システムがランダムな文字列を発行する場合は,最低6文字を求めていますので,
> 77^6 ≒2.1×10^11 英大文字・小文字・数字・記号 6文字
程度がガイドラインが示す最低限の目安なんじゃないでしょうか.
dicewareという単語の組み合わせだけのパスワードでも暗号学的にも強度が保証出来る生成ツールがありますね。http://www.hyuki.com/diceware/ [hyuki.com]このdicewareでパスワードを生成した場合は1単語あたり12.92bitのランダム性があるので求める強度から簡単に必要な単語数を知ることが出来ます。
技術的な話をすれば、ダイスウェアの各単語は 12.92 ビットのエントロピー(パスフレーズの安全さをはかる尺度)を生む。5単語のダイスウェアパスフレーズは少なくとも 64.6 ビットのエントロピーを持つ。6単語なら 77.5 ビットである。7単語なら 90.4 ビットである。ランダムに一文字を置き換えると、エントロピーは約 10 ビット増加する。いうまでもないことだが、これはパスフレーズを秘密にしておくことを前提としている。
完全な「ダイスウェア単語一覧」 は 7776 個の短い英単語、省略形、そして思い出しやすい文字列からできている。
2^12.92≒7750 ですから、私の計算で仮定している語彙一万語より少ないため、もうすこしランダム性が低い計算になるだけだと思います。私の計算の語彙一万語(約13.29bit)から英単語を選ぶというのも完全にランダムでなければ(たとえば有名な格言だのセリフだのを使うと)計算は無意味になります。
# 7776個って計算が面倒ですね。もうすこし頑張って 8192個(13bit) まで単語を選べなかったんでしょうか。
diceware [hyuki.com] の説明では、
完全な「ダイスウェア単語一覧」 に含まれる各単語の平均長は4.2文字である。最も長い単語は 6 文字である。
とありますね。これ以上増やしてしまうと、長い英単語が入ってしまい、ユーザが思い出せなくなるのでしょう。
まぁ、いけてるレインボーテーブル使ったり?
クラック技術というよりは、「全般的な技術の向上」でしょうね。クラッキング技術自体はそれ程向上していないと思う。新たなセキュリティホールを利用した・・・とかはあっても、今まで思いがけなかった方法でクラッキングされる可能性って、レノボの話題以降目新しい方法で話題ってなかったような・・・・(これ自体も、新しい技術でもなかったけど)
処理の高速化/並列化が容易に実現できるので、ブルートフォースとか容易になってるとか。アタックに使うパターンもネットで大量に入手できるようになったとか。攻撃する側も、実行して放っておけば「いつか当たる」と思えるので、楽でしょうねぇ「環境の変化」が大きな要因だと思いますね。
文字数が長ければ、組み合わせパターン数が天文学的に増えるので、モノが流出しない限り安全な場合が多いのはもともと言われてるわけですし、今更> 「複数の英単語を単純に並べた文字数の多いパスワード」のほうが安全度が高いこんなこと言わなくてもねぇ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
算数のお時間 (スコア:0)
> 現代ではパスワードクラック技術が向上しており
それ技術の向上と関係あるの?
Re:算数のお時間 (スコア:3)
元々、耐性としては
・長さが一番
・複雑さが2番
だったんだが、昔は長いのが入れられないことも多かったし、
クラック技術も未熟だったのでそこまで耐性が求められず、
長いのは打つのがだるいからか覚えにくいからか、複雑なパスワードが好まれた。
# どっちが先か知らないが、昔は「長いパスワード」が入れられるシステムが少なかったし
今は複雑なだけでは対クラック性が足りなくなり、長さが必要になってきた
長いほうがいい、開き直ってしまえばパス「ワード」は諦めてパス「フレーズ」
パス「センテンス」
にすりゃ少々長くても間違えない忘れないからそんなにコストは上がらないし、
はじめっからこっち薦めておけばよかった
って事でしょう
Re:算数のお時間 (スコア:2)
Re: (スコア:0)
昔はメモリやストレージが高価で節約が美徳だったから、折角同じ7bit ASCIIなら8文字くらいに収めてユーザには記号で複雑さを稼いでもらうというのが当然だった
鍵長と考えれば英数大小と記号で8文字なら7*8=56bitに対して、記号を抜いて16文字なら6*16=96bitだからな
Re: (スコア:0)
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどな
ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
Re:算数のお時間 (スコア:1)
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどな
ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
ハッシュの長さが短くてパスワードの長さに制限がなければ
同じハッシュを再現できる可能性が高まるので、
やはりパスワードの入力長は制限があったほうが良いと思う。
Re: (スコア:0)
> ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
そんなことはまったくない
たとえば「1」というパスワードを使った場合、ハッシュ値はそこそこ長くなるが、
悪意あるものがブルートフォースで攻撃し始めた途端に攻撃が成立するパスワード
(=ハッシュ値が一致する文字列、今回の場合は「1」)を割り出せてしまう
ハッシュにしたとしてもパスワードのデータ長をある程度長くすることは必要
実際に、
「パスワードフィールドには長々と文字を入力できるが、実際には過去互換性のためそのうち先頭8文字しか使わない仕様だった。
そのうえで内部への保存はパスワード平文ではなくハッシュ値だった。
結果としてパスワード長8文字を超える強度のパスワードは使えない仕様だった」
という仕様だったOS(というかAPI仕様)は存在する
Re: (スコア:0)
昔はメモリやストレージが高価で節約が美徳だったから、折角同じ7bit ASCIIなら8文字くらいに収めてユーザには記号で複雑さを稼いでもらうというのが当然だった
鍵長と考えれば英数大小と記号で8文字なら7*8=56bitに対して、記号を抜いて16文字なら6*16=96bitだからな
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどな
ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
という話の流れで、
そんなことはまったくない
たとえば「1」というパスワードを使った場合、ハッシュ値はそこそこ長くなるが、
悪意あるものがブルートフォースで攻撃し始めた途端に攻撃が成立する
Re: (スコア:0)
>だったんだが、昔は長いのが入れられないことも多かったし、
銀行ATMは今でも数字4桁
ドコモの認証も一緒
年寄りはほぼみんな生年月日に設定
それ以外は覚えられないから
サーファー (スコア:0)
サーファーは 1173 が多いんだとか
良い波->イイナミ->1173
だそうです。
…ということは、
肉好きは 1129
になるのか?!なんて連想してしまいました。
Re: (スコア:0)
Re: (スコア:0)
銀行ATMにしろ、ドコモの認証にしろ、
・一定回数間違えたらアカウントにロックかけることでブルートフォースへの対策にしてる
・ATMであればキャッシュカード必須だし、監視カメラのあるATM機にアクセスするので足がつきやすい
・ドコモの認証は、ドコモの回線からの接続に限定し、さらにICCID単位でロックをかけられるので、ブルートフォースをで攻撃できるIDが非常に限定的
という要素を無視して、単なる数字4桁の脆弱さと同一視するのはいかがなものかと。
Re:算数のお時間 (スコア:2)
> それ技術の向上と関係あるの?
総当たり攻撃を考えれば、関係あると思います。しかし、後述するように現時点ではどうかと思いますが。
例えば、英大文字・小文字・数字・記号が 26+26+10+15=77 種類だとして、良くある最低 6文字だとか 8文字だとかと、英小文字のみの 12文字、英小文字数字の 12文字を比較すれば、
77^6 ≒2.1×10^11 英大文字・小文字・数字・記号 6文字
77^8 ≒1.2×10^15 英大文字・小文字・数字・記号 8文字
26^12≒9.5×10^16 英小文字のみ 12文字
36^12≒4.7×10^18 英小文字・数字 12文字
ただ、「複数の英単語を単純に並べた文字数の多いパスワード」はこれを想定した攻撃を考えると、12文字程度では足りない気がします。仮にパスワードに使用する単語の語彙が 1万とすれば、3語では 10^12、4桁以下の数字(11110通り)を入れても 3語では、9.4×10^12 にすぎません。少なくとも 4語は必要と思われます。これは 12文字では足りませんが、パスワード文字数に制限があるサイトも多いので、難しいように思います。
10,000^3=1.0×10^12 英単語1万語から 3語
10,000^4=1.0×10^16 英単語1万語から 4語
(10,000+11,110)^3≒9.4×10^12 英単語1万語と4桁以下の数字から 3語
(10,000+11,110)^4≒2.0×10^17 英単語1万語と4桁以下の数字から 4語
したがってパスワードの文字数に上限がある場合も多いことを考えると、単語や数字だけでは不足で、例えば好きなフレーズの単語先頭文字とかを入れるべきでしょう。
しかし、昨今では、パスワードを共有する相手サイトごとにパスワードを変えるべきですから、「複数の英単語を単純に並べた文字数の多いパスワード」はすでに時代遅れでは?と思います。サイトごとに異なるパスワードの自動生成を一部なりとも導入すべきでしょう。
# 計算に間違いがあればご指摘願います。
Re: (スコア:0)
同感です。
さらに、単語の使用頻度は単語ごとに非常に差があり、頻出単語で考えるとせいぜい語彙は数千程度、
さらに文法や慣用句を考慮した予測も利用可能であることを考えると、長いパスフレーズの複雑さを、
12文字程度の複雑なパスワードより高めるには、それなりに長いパスフレーズにする必要があると思います。
で、これをサービスごとに別々に考える必要がありますと。
結果として、有名な歌詞の一部などを使い始める人が出てきて、パスワード時代と同じ議論にならないでしょうか。
「パスフレーズなら予測困難なパスワードが容易に作成できる」「パスフレーズなら覚えやすいためPostItに書かずに済む」
…本当ですかね?
Re: (スコア:0)
NIST のガイドラインを読むと,文字数に関しては,システム側は最低8文字をユーザーに要求して,ユーザーが望むならば64文字までは許容するべきである.とかかれていますね(上限は設けないものの,ユーザー側からMB級の文字列を入力されると,ハッシュの計算量が増大になるのでシステム側で制限が必要と注あり).
一方で,システムがランダムな文字列を発行する場合は,最低6文字を求めていますので,
> 77^6 ≒2.1×10^11 英大文字・小文字・数字・記号 6文字
程度がガイドラインが示す最低限の目安なんじゃないでしょうか.
Re: (スコア:0)
dicewareという単語の組み合わせだけのパスワードでも暗号学的にも強度が保証出来る生成ツールがありますね。
http://www.hyuki.com/diceware/ [hyuki.com]
このdicewareでパスワードを生成した場合は1単語あたり12.92bitのランダム性があるので求める強度から簡単に必要な単語数を知ることが出来ます。
技術的な話をすれば、ダイスウェアの各単語は 12.92 ビットのエントロピー(パスフレーズの安全さをはかる尺度)を生む。5単語のダイスウェアパスフレーズは少なくとも 64.6 ビットのエントロピーを持つ。6単語なら 77.5 ビットである。7単語なら 90.4 ビットである。ランダムに一文字を置き換えると、エントロピーは約 10 ビット増加する。いうまでもないことだが、これはパスフレーズを秘密にしておくことを前提としている。
Re:算数のお時間 (スコア:2)
dicewareという単語の組み合わせだけのパスワードでも暗号学的にも強度が保証出来る生成ツールがありますね。
http://www.hyuki.com/diceware/ [hyuki.com]
このdicewareでパスワードを生成した場合は1単語あたり12.92bitのランダム性があるので求める強度から簡単に必要な単語数を知ることが出来ます。
完全な「ダイスウェア単語一覧」 は 7776 個の短い英単語、省略形、そして思い出しやすい文字列からできている。
2^12.92≒7750 ですから、私の計算で仮定している語彙一万語より少ないため、もうすこしランダム性が低い計算になるだけだと思います。私の計算の語彙一万語(約13.29bit)から英単語を選ぶというのも完全にランダムでなければ(たとえば有名な格言だのセリフだのを使うと)計算は無意味になります。
# 7776個って計算が面倒ですね。もうすこし頑張って 8192個(13bit) まで単語を選べなかったんでしょうか。
Re:算数のお時間 (スコア:1)
完全な「ダイスウェア単語一覧」 は 7776 個の短い英単語、省略形、そして思い出しやすい文字列からできている。
# 7776個って計算が面倒ですね。もうすこし頑張って 8192個(13bit) まで単語を選べなかったんでしょうか。
diceware [hyuki.com] の説明では、
完全な「ダイスウェア単語一覧」 に含まれる各単語の平均長は4.2文字である。最も長い単語は 6 文字である。
とありますね。これ以上増やしてしまうと、長い英単語が入ってしまい、ユーザが思い出せなくなるのでしょう。
Re: (スコア:0)
まぁ、いけてるレインボーテーブル使ったり?
Re: (スコア:0)
クラック技術というよりは、「全般的な技術の向上」でしょうね。
クラッキング技術自体はそれ程向上していないと思う。
新たなセキュリティホールを利用した・・・とかはあっても、今まで思いがけなかった方法でクラッキングされる可能性って、レノボの話題以降目新しい方法で話題ってなかったような・・・・(これ自体も、新しい技術でもなかったけど)
処理の高速化/並列化が容易に実現できるので、ブルートフォースとか容易になってるとか。
アタックに使うパターンもネットで大量に入手できるようになったとか。
攻撃する側も、実行して放っておけば「いつか当たる」と思えるので、楽でしょうねぇ
「環境の変化」が大きな要因だと思いますね。
文字数が長ければ、組み合わせパターン数が天文学的に増えるので、モノが流出しない限り安全な場合が多いのはもともと言われてるわけですし、今更
> 「複数の英単語を単純に並べた文字数の多いパスワード」のほうが安全度が高い
こんなこと言わなくてもねぇ