NISTの「パスワードには記号や数字を加え定期的に変更する」ルール策定者、間違っていたと後悔 126
ストーリー by hylom
諸悪の根源と言われても仕方が無い 部門より
諸悪の根源と言われても仕方が無い 部門より
あるAnonymous Coward曰く、
米国立標準技術研究所（NIST）で「パスワードには英大文字・小文字・数字・記号を使う」「定期的にパスワードを変更する」といったパスワード設定規則を作成したビル・バー氏が、このルールはほとんど間違っていたとして後悔しているという（ウォール・ストリート・ジャーナル）。
定期的にパスワードを変更することが無意味なことは昨今では頻繁に説明されており、セキュリティについて学んでいる人であれば意味が無く利用者に不便を強いるだけのルールであることはもはや常識だろう。
また、現代ではパスワードクラック技術が向上しており、そのため「英大文字・小文字・数字・記号を使った短いパスワード」よりも、「複数の英単語を単純に並べた文字数の多いパスワード」のほうが安全度が高いという。
よくある勘違い (スコア:5, すばらしい洞察)
無意味（というか有害）なのは、「定期的なパスワード変更を（システム側で）強制すること」です。
Re:よくある勘違い (スコア:4, 興味深い)
うちのシステムがそれだ。
三ヶ月に一回変更しないとログインできなくなる。
パスワードに単語らしきものが入っていると弾かれる。
変更履歴を持っていて一度使ったパスワードは二度と使えない。
パスワードを忘れた場合の再設定は書類を書いて対面認証。
そりゃ、ポストイットに書いてディスプレイに貼り付けが横行するわ。
Re: (スコア:0)
＞マイクロソフト のコーマック・ハーリー主任研究員は、人類が1日にパスワード入力に費やす時間が計1300年相当を超えていると話す。
日本の貢献度は高いと思う
弊社の場合 (スコア:3, 興味深い)
確かに高そうだ。毎日数十回もパスワードを入力させられてる弊社だけでも、会社全体では一日あたりで延べ40日分パスワード入力に時間を費やしてるって試算があった。
ちなみにこれはセキュリティ委員会で「いくらなんでも無駄すぎないか」という主張の補強に使われたのだが、「セキュリティは全てに優先する」ということで流されてた。
・・・ところで、同じパスワードを毎日数十回も打ち込むのって、それはそれでセキュリティリスクないのかなあ？
Re:弊社の場合 (スコア:1)
ロガーなしでも、
数字をあまり入力しない業務なのに一部の数字キートップだけ擦り減っていたりすると危険かも。
Re:弊社の場合 (スコア:1)
なるほど俺の彼女がキーボードまで掃除してくれる理由……
Re: (スコア:0)
うちはさらにパスワードの長さが16文字まで、変更画面では平文でパスワード表示だ
Re:よくある勘違い (スコア:2)
Re:よくある勘違い (スコア:2)
漏れてから気付くまでの期間が3ヶ月なり平均して1.5ヶ月なりより長ければ意味がありますけど、45日も入られ放題が続いた後で変更しても意味がないんじゃないでしょうか。
Re:よくある勘違い (スコア:2)
破るのに数時間かかる鍵があるとして、数十分間隔で変わるのと数か月間隔で変わるのだったら、後者に意味はありますか?
数か月のうち(数か月-数時間)の間は侵入不能なのだからそれでよい、と言えますか?
この議論の違和感 (スコア:2, すばらしい洞察)
根拠となる新たなエビデンスが一切ないこと。
NISTとかGoogleとか、権威のある組織が言い出しただけで、たくさんの人がそれに乗っかってあたかも事実のように言い出してる。
権威に乗っかってエビデンスを見ないって、セキュリティ専門家としては一番やっちゃダメなやつじゃね？
Re: (スコア:0)
根拠っていったって、数字だけで言うなら英数記号強制で20桁のパスワードを毎日変更するのが一番安全なのは間違いないんだけど
人間それやると絶対サボるからどこで折り合いをつけるかって話だからエビデンスなんか出しようがなくね？
Re: (スコア:0)
「人間は短くて複雑なパスワードはさぼるけど長いパスワードはさぼらない」っていうエビデンスを出せばいいと思った。
Re: (スコア:0)
サボっても単純に長い方が耐性が高いからマシって話でしょ
話は逸れるけど、パスワード記憶問題というと (スコア:2)
Appleのデバイスだと、Safariが自動でパスワードを提案してくれて、iCloudに保存しておくからユーザーは覚えなくてもいいよ〜
っていう機能があるんですが、Apple信者の私でも躊躇する機能。スラドで、Appleユーザーで、あれを使っている、という人の割合を知りたい。
#ケータイがAndroidなので困る、という理由も冷静に考えたらあった。
長いパスワードの上限 (スコア:1)
世にあるシステムってパスワードは何文字ぐらい受け付けられます？
開発者の方には「私の携わったシステムでは○文字でした」というのも聞いてみたい。
理論上はハッシュ化すれば元の文字列なんていくらでも、とは言え、実際のシステム的に入力の上限はありますよね。
私は最近携わった案件では、UTF-8でNFC正規化して4096バイト（漢字だろうが絵文字だろうが受け付けるが文字数は変化）、なんてのがありましたが。
Re:長いパスワードの上限 (スコア:1)
一応その辺は、ハッシュ処理のバージョニングも対応しているので、正規化方式を変えるときはハッシュ処理変更と同じ手順を踏むことになってます。
（正規化部分は処理系の文字処理とは独立なので不意の変更はない…はずだが将来どうなるだろうな）
面倒になって末尾数字が日付になるよね (スコア:0)
Admin1708とか…。
強度的にゼロに近そうｗ
アマゾンのパスワード変更ルール (スコア:0)
まず90日以内に変更しろ
ログイン文字列は英単語になさそうなやつにしろ
大文字小文字は必ず混在 記号も入れろ
混ぜてもいい数字は最大三桁まで
思いつかない奴はシステムが提案するパスワードを使え（覚えられない呪文）
＃パスワードは忘れても業務に全く支障がないのが判明したのでエーシー
いいよいいよ (スコア:0)
反省してんなら許してあげるよ
Re:いいよいいよ (スコア:2, 興味深い)
10年以上前に発表されたルールだと言うことを考えたら、そこまで反省するほどのものかな、という気はする。
2003年、って事は、64ビットCPUがようやく市場に出回り始めた辺り、
マルチコアやマルチスレッディングも黎明期(でintelとAMDが繰り広げてたクロック競争の末期と記憶している)だった訳で、
当時のマシンリソース考えたら辞書アタック可能な実在する単語の組み合わせより、
ブルートフォースに頼らざるを得ないランダム文字列かつ一桁あたりの文字種別が多い組み合わせのほうが、
と考えるのはそこまでおかしい話でもないんじゃないかな。
「複数の単語」って言ってもシステム側に8文字とか16文字とかの制限あるのが当たり前だった訳だし、
その状況で単語を組み合わせたところでせいぜい2つか3つがいいところだった訳だし。
問題はルールの内容そのものじゃなくて、10年前のルールを実情に照らし合わせる事もせずに掲げ続ける運用の方にあって、
そこが変わらない限りどんなルールを決めたところで10年後には同じ事言ってる、になるだけでしょう。
Re:いいよいいよ (スコア:1)
辞書アタックだろうがブルートフォースだろうが、マシンスペックに関係なく、「定期的変更の強制」は
理論上無意味かつ理論上有害なのは当時から指摘する人は結構いた。
簡単な話で aから（前から）順にアタックされているか、ｚから（後ろから）アタックされているかはわからない。
変更を強制することで、「次にアタックされる方へ二分の一の確率でパスワードを近づけてしまう。変更しなければそのまま」
よって有害でしかない。結構前から言われてました
Re:いいよいいよ (スコア:1)
ヒジキには鉄分が豊富に含まれているに決まってる、…
え? 鉄分は豊富だろ? 何言ってるんだー (鉄鍋でヒジキを煮ながら
# 目からうろこだよほんとに
Re:いいよいいよ (スコア:1)
確かにヒジキは栄養豊富であるが同時にヒ素が多く含まれているので、小皿1杯食べると約1時間寿命が縮むって聞いたよ。食べるのやめたほうがいいんじゃない？
それぐらいなら免疫がつくってもンよ! (ﾊﾟｸﾊﾟｸｰ
Re:いいよいいよ (スコア:1)
忍者の修行だかなんだったかフィクションで毒を微量取り込み続けることで耐性が！みたいなのがあったな。
人体は不完全なのだから、そんなわけがない。
だが、浪漫としてはアリだ。
# 体は大人！頭脳は少年！
Re:いいよいいよ (スコア:1)
すべてステンレス製の釜ということだが、待って欲しい。
フェライト系ステンレス(磁石にくっつくやつ)であれば、鉄分は豊富になるのではないか?
日本の釜はオーステナイト系ステンレスだから鉄分が少ないのではないか?
だとすると、もっとクロムとかニッケルとか、ひじき分が多くてもよくはないか?
# ひじき分 イコール シュークリーム分 的な何か
Re: (スコア:0)
いや、そこまで言うほど常識かな？個人レベルではそうかもしれないけど、組織レベルだとこういうことを言ってる人は結構いるような。
Re: (スコア:0)
反省して、そこで止まったらあきませんなぁ
ちゃんと間違ってたから、と大きく声を上げて、無駄な風習を止めさせてください……
算数のお時間 (スコア:0)
> 現代ではパスワードクラック技術が向上しており
それ技術の向上と関係あるの？
Re:算数のお時間 (スコア:3)
元々、耐性としては
・長さが一番
・複雑さが2番
だったんだが、昔は長いのが入れられないことも多かったし、
クラック技術も未熟だったのでそこまで耐性が求められず、
長いのは打つのがだるいからか覚えにくいからか、複雑なパスワードが好まれた。
# どっちが先か知らないが、昔は「長いパスワード」が入れられるシステムが少なかったし
今は複雑なだけでは対クラック性が足りなくなり、長さが必要になってきた
長いほうがいい、開き直ってしまえばパス「ワード」は諦めてパス「フレーズ」
パス「センテンス」
にすりゃ少々長くても間違えない忘れないからそんなにコストは上がらないし、
はじめっからこっち薦めておけばよかった
って事でしょう
Re:算数のお時間 (スコア:2)
Re: (スコア:0)
昔はメモリやストレージが高価で節約が美徳だったから、折角同じ7bit ASCIIなら8文字くらいに収めてユーザには記号で複雑さを稼いでもらうというのが当然だった
鍵長と考えれば英数大小と記号で8文字なら7*8=56bitに対して、記号を抜いて16文字なら6*16=96bitだからな
Re: (スコア:0)
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどな
ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
Re:算数のお時間 (スコア:1)
昔も今も根本的に、可逆値でユーザーのパスワードを記録することが間違いなんだけどな
ハッシュにするのであればデータ長は固定にできるから、パスワードのデータ長をどうこう言う必要は本来ない
ハッシュの長さが短くてパスワードの長さに制限がなければ
同じハッシュを再現できる可能性が高まるので、
やはりパスワードの入力長は制限があったほうが良いと思う。
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:算数のお時間 (スコア: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)
クラック技術というよりは、「全般的な技術の向上」でしょうね。
クラッキング技術自体はそれ程向上していないと思う。
新たなセキュリティホールを利用した・・・とかはあっても、今まで思いがけなかった方法でクラッキングされる可能性って、レノボの話題以降目新しい方法で話題ってなかったような・・・・（これ自体も、新しい技術でもなかったけど）
処理の高速化／並列化が容易に実現できるので、ブルートフォースとか容易になってるとか。
アタックに使うパターンもネットで大量に入手できるようになったとか。
攻撃する側も、実行して放っておけば「いつか当たる」と思えるので、楽でしょうねぇ
「環境の変化」が大きな要因だと思いますね。
文字数が長ければ、組み合わせパターン数が天文学的に増えるので、モノが流出しない限り安全な場合が多いのはもともと言われてるわけですし、今更
> 「複数の英単語を単純に並べた文字数の多いパスワード」のほうが安全度が高い
こんなこと言わなくてもねぇ
やさしいせかい (スコア:0)
違法なことは何もしておらず、迫害には徹底的に戦う。
定期的にパスワードを変更することが無意味なことは昨今では頻繁に説明されており (スコア:0)
なぜ定期的にパスワードを変更することが無意味なのでしょう？
定期的にパスワードを変更することが無意味なことは昨今では頻繁に説明されており、セキュリティについて学んでいる人であれば意味が無く利用者に不便を強いるだけのルールであることはもはや常識だろう。
ここでは
頻繁に説明されているから
学んでいる人の常識だから
と書かれています。
Re:定期的にパスワードを変更することが無意味なことは昨今では頻繁に説明されており (スコア:1)
無意味ではない。
パスワードが流出した事に管理者が長期に渡って気づいていないか公表していないか、盗んだ犯人が長期に渡って悪用していない場合に意味がある。
普通は流出すると速攻で悪用すると考えられるので
流出→悪用までの間に運よくパスワード変更してたら助かるよね(^^;
という話。
昔はパスワード解析に時間が掛かると考えられたけど、平文で保存するおバカな管理者も居たり超高性能コンピューターもあったりでそうも行かない今日この頃。
Re: (スコア:0)
そこは、頻繁に説明されているから常識になっている、と読むべきでは？
そしてこの文は、……ことが無意味であることを前提としているので、その理由(なぜ)についてはここを読んでも意味ないし。
Re: (スコア:0)
そしてパスワード変更が無意味なことはわかってないと。
Re: (スコア:0)
マジレスすると、めんどくさいルールを押し付けるとユーザーがパスワードを使いまわしたり、ポストイットで貼り付ける事をするから
Re: (スコア:0)
それは従来から既知じゃね？ なぜ突然それを言い出したの？
Re:定期的にパスワードを変更することが無意味なことは昨今では頻繁に説明されており (スコア:2)
人間が扱える範囲で総当たり耐性のあるパスワードの運用は筋が良くないと言っていいんじゃないでしょうか。
定期変更するなら、数か月や数年は技術的に長すぎます。しかし、例えば2週間や3日では紛失が起こるでしょう。
本筋は人間の暗記ぢからと関係なく妥当な複雑さのキーを設定できる物理的な認証デバイスの導入で、次善策はそれのソフトウェア版ではないでしょうか。
AppleのiCloudの大量クラックを引き起こした「秘密の質問」の落とし穴も追加が必要だな (スコア:0)
AppleのiCloudの大量クラックによる「セレブヌード流出事件」を引き起こした主犯「秘密の質問」もね
まぁあのときは「秘密の質問」に対するブルートフォース対策がなってなかったというAppleの重大な過失があったようだけど
(当時、最初にクラック実績を主張したクラッカーの発言より)
Re:これ、漫画家が考えた根拠で専門家の検証は済んでないよ (スコア:2)
XKCDの著者Randall Munroe氏は元NASA Langleyのプログラマですよ。
"単語を4つ並べたパスワードに最適化"すれば簡単に解けそうですが、この生成方法は2000未満の範囲で乱数を四つ作り、短いものを除いた常用単語2000語から選ぶ前提なんですよ。
例えば[0, 0, 0, 0]なら[the, the, the, the], [39, 133, 299, 16]なら[which, health, library, your]などとなります。
この例だと"which health library your"は25文字ありますので、乱数文字列とみれば26^25=2.4*10^35通りあり、千溝程度の試行回数がクラックするまでに必要そうですね。
単語だと知っていれば、わずか2000^4 = 1.6 * 10^13通りの強度に低下してしまいます。平均して10兆試行ほどでクラックできることになりますが、はて、"かなり短時間"をどう定義するかですね。