web-dev-qa-db-ja.com

「何百年もかけて破られる」パスワードの使用について混乱

私はこのパスワードについて話している-23##24$$25%%26と、最近のユーザーがよく使用するパターンに現れる特殊文字で構成される同様のパスワード。

職場(金融会社)では、特定のサイクルまたはパターンを使用して、ユーザーに選択を許可してはならない不正なパスワードのリストを作成していました。上記の種類は、特殊文字を挟む連続した数字を含むという特徴を示しています(特定の回数繰り返し、ここでは2回)。

好奇心から、私は非常に有名なWebサイト(ログインページ)でこれを確認しましたが、これには何百年もかかることになると述べていました。

壊れるのに何年もかかるが、非常に脆弱なリストのいくつかの例:

1!2@3#4$5%6^2@3#4$5%6^7&a!b@c#d$e%f^

今、私はリストと混同していますが、これらの特定の種類のパスワードを脆弱なものとしてマークし、ユーザーが解読するのに非常に長い時間がかかる場合でも、それらを許可しないようにする必要がありますか?

注1-多くのユーザー(したがって、複数の類似したパスワード)が覚えやすいようにこの傾向に従っているため、これらの脆弱性を考慮しています。
注2-セキュリティ担当者はすべてエントロピーを増やすことを目的としているため、混乱しています。彼らが無視しているのは、データベース内の類似したハッシュの秩序性の向上です。
どのパスワードを許可または拒否するかを定義する、どこに線を引くかについて、人の間で摩擦が生じました。

編集:

  • 私が話しているこのWebサイトは、名前を明かしませんが、パスワードをテストしたところ、すべての倫理的/非倫理的なハッカー、Stack Exchangeのほとんどすべてのユーザー、および多くの大小企業(サービスを使用しているため)によく知られています。

  • パスワードはプレーンテキストで保存しません。自家製のハッシュアルゴリズムではなく、Niceを使用しています。
    インシデントによりパスワードポリシーを確認する必要があり、別のマシンに別のデータベースdb-2を作成しました。who_createdを保存​​せずに、simply_hashed_newly_createdユーザーのパスワード(salt、nothing、hashed_pa​​sswordのみ)を保存しました。 when_created詳細。これは短期間だけ行いました。パスワードの変更もこのデータベースに反映されました。一方、元のデータベースでは、db-1はsecure_salted_pa​​sswordsを使用していました。
    パターンに従ってハッシュされた脆弱なパスワードのリストLも作成し続け、Ldb-2を照合すると面白がってしまいました-見ました特定のパターンを持つ類似したパスワードの複数のグループ。 Lおよびdb-2は後でシステムから消去されました。

  • db-2は非常に安全なマシンに保管され、安全でした。ここでは正確な詳細を開示しません。エアギャップや電気ソケットでも安全ではないことを認識しています。 db-2Lの両方が破棄されました。

  • ここで投稿されたパスワードについては心配しないでください。すでに小さな実験を行っており、これらの特定のユーザー全員がパスワードをリセットするようになっています(もちろん、古いパスワードとは異なる新しいパスワード)。それが理由で、私はいくつかのサンプルを投稿してここに来ました。
    そして、私も以前にここでコメントしました。ジェネレータのロジックからのパスワードのサンプルを投稿し、ハッシュ化されたパスワードの非常に膨大なリストを作成しました。これはdb-2にある場合とない場合があります。繰り返しますが、これらのすべてのユーザーは新しいパスワードを持っているため、心配する必要はありません。

  • ジェネレーターが機能していることを知っているので、ウェブサイトでいくつかのパスワードサンプルをテストしました。

回答ありがとうございました。感謝の意を表します。回答に基づいて、当面はパスワードの選択を制限するいかなる種類の制限も延期しました。

50
Batman

オンライン計算機は、特定の仮定に基づいて結果を計算しています。これは、いずれの場合にも当てはまらないものです。計算機を信頼して、攻撃者がパスワードを破ることをどのように選択するかについての洞察を提供する根拠はありません。

たとえば、あなたがパターンを使用していることと、そのパターンが何であるかを知っている場合は、ブルートフォーシングを調整してパターンに合わせます。オンライン計算機がそれを説明する方法はありません。考慮すべき他の同様の要因があります。 「エントロピー」とは、可能な限りランダム性を確保することです。セットパターンは、使用する文字に関係なく、ランダム性が大幅に低減されています。

したがって、そうです。そのような明白なパターンは、それがあなたの目標を満たしている場合は禁止してください。

ただし、これらのパスワードを禁止する方法について懸念があります。あなたは間違った戦いをしているかもしれません。

87
schroeder

好奇心から、よく知られているWebサイト(ログインページ)でこれを確認しましたが、これには何百年もかかることになると述べていました。

そのようなウェブサイトは福音と見なすことはできません。多くは価値がなく、良いものであっても結果を注意深く解釈する必要があります。まず第一に、原則として、強度チェッカーはパスワードが弱いことを最終的に伝えることができますが、パスワードが強力であることを実際に証明することはできません。障害を検出できないパスワードは、何らかの攻撃に陥る可能性があります。メーターはモデル化していません。いくつかの極端な例については、 thisArs Technicaの記事では、いくつかの非常に長いパスフレーズに対する成功したクラッキング攻撃について説明しています

ほとんどすぐに、かつて頑固なパスワードの洪水が明らかになりました。 「あなたの顔がまた見えるか?」 (36文字)、「最初は言葉だった」(29文字)、「創世記から啓示まで」(26)、「何も覚えていない」(24)、「thereisnofatebutwhatwemake」(26)、「givemelibertyorgivemedeath」(26 )、および「eastofthesunwestofthemoon」(25)。

もう1つは、1つのメーターがパスワードを強力であると判断すると言ったからといって、すべてのメーターがそうであるとは限らないということです。たとえば、最高の1つである zxcvbn チェッカーは、パスワードハッシュが弱い場合、これはオフライン攻撃によって3時間で破られると考えています。

password:              23##24$$25%%26
guesses_log10:         14
score:                 4 / 4
function runtime (ms): 3
guess times:
100 / hour:            centuries  (throttled online attack)
10  / second:          centuries  (unthrottled online attack)
10k / second:          centuries  (offline attack, slow hash, many cores)
10B / second:          3 hours    (offline attack, fast hash, many cores)

match sequence:
'23##24$$25%%26'
pattern:               bruteforce
guesses_log10:         14

1!2@3#4$5%6^2@3#4$5%6^7&a!b@c#d$e%f^の2分は10B /秒の攻撃(10k /秒で3年)と見積もられているため、さらに悪いと考えられています。 (すべてのスコアを4/4にしますが、メーターは、これらのパスワードのいずれかを実際に受け入れることを推奨しています。これは、アプリケーションが実装されている場合、攻撃に抵抗する可能性が高いと推定されているためです。遅いパスワードハッシュ。しかし、その分析は実際に、軽減すべき特定の攻撃に対して弱いことを証明しています。)

Zxcvbnは、ほとんどのユーザーがパスワードを選択する方法に関する一般的な知識のみに基づいて攻撃をモデル化することに注意してください。組織のパスワードポリシーまたは慣行が、それらを知る誰かに特別な攻撃を許可する方法についての具体的な知識はありません。また、ツールはパスワードが弱いことを通知できますが、強力であることは通知できません。zxcvbnは、何世紀にもわたってAm i ever gonna see your face again?をクラックすることを推定します。これは、Ars私たちが知っている記事は、実際に実際に解読されました。

今、私はリストと混同していますが、これらの特定の種類のパスワードを脆弱なものとしてマークし、ユーザーが解読するのに非常に長い時間がかかる場合でも、それらを許可しないようにする必要がありますか?

これらのパスワードを禁止するという本能は、zxcvbnの結果が示すように、実際には正当化の余地があることがわかります。問題は、同様に脆弱なパスワードや、攻撃者が悪用する可能性のあるパターンの限られたリストのコンパイルに成功する可能性が低いことです。たとえば、zxcvbnが後者の3つと同じくらい脆弱であると考えるすべてのパスワードをキャッチするには、1.2兆のエントリ(10Bパスワード/秒×2分)のリストが必要です。実用的ではありません。拒否するパターンの小さなリストに物事を要約しようとしても、攻撃者をうまく考え抜くことはできません。

間違いなく行うべきことの1つは、bcryptまたはArgon2パスワードハッシュ関数で強力なパスワードハッシュを使用することです。これは、上記のzxcvbnの結果が「スローハッシュ」と呼んでいるものであり、パスワードエントリを解読するのをはるかに困難にする可能性があります。 (ただし、強度チェッカーは、一部のパスワードは間違いなく安全ではないが安全であるとは限らないことを通知できることに注意してください。)

さらに考慮すべき事項:

  • 非常に一般的であることがわかっているパスワードの小さなリスト(数千)を使用し、それらを禁止します。このようなリストはオンラインで簡単に見つけることができます。
  • オンラインAPIもある Troy Huntの500M +違反パスワードリスト を使用します。 (必ず読んでください k-匿名性に関する資料 なので、実際にパスワードをAPIに送信しないでください!)
  • Zxcvbnなどのスマート強度メーターライブラリを使用します。これは、考えているようなパターン検出のはるかに高度な代替手段です。
  • パスワードが唯一の防御ラインではないように、2番目の認証要素を実装します。
42
Luis Casillas

パスワードの推測可能性とは、ユーザーが選択する可能性のあるパスワードの種類について何かを知っていることを意味します。 「パスワード」は英語の単語なので推測できることは誰でも知っています。しかし、英語を知っている必要があるか、英語や他の関連言語が単語を綴る方法の概念を持っている必要があることを知るために。英語や他の人間の言語にさらされたことがないベテルギウスの近くのどこかから来た外国人は、「パスワード」が簡単に推測できることを知らないでしょう。言い換えると、パターンはある程度主観的であり、(特定のレベルを超えると)パターンを事前に予測することが非常に困難になります。

同様に、リストの一部のパスワードについては、パターンが何であるかすぐにはわかりません。 1!2 @ 3#4 $ 5%6 ^は一見するといくぶん「ランダム」に見えますが、QWERTYキーボードでは、それは単に1-6であり、シフトキーを持つ他の文字。

さらに、誰かがパスワードCPE1704TKSをあなたに見せた場合、それも良いパスワードだと思うかもしれません。それは10文字の文字と数字を持ち、それに決定可能な反復可能なパターンはなく、それは人間の言語の言葉ではありません。しかし、あなたは間違っているでしょう。これは、映画Wargamesの最後に核ミサイルを発射するために使用されるパスワードであるため、優れたパスワードではありません。

このため、ランダムなWebサイトから(長さと文字の選択に基づいて)「クラッカビリティ」の計算を使用することは、ほとんどの場合偽です。さらに、彼らはパスワードハッシュを取得する誰かに依存しますが、それ自体がセキュリティ上の大きな妥協です。ハッシュがどれだけ速くかかるか知っていることを意味するので、それらは二重に偽物です。ハッシュ速度は、選択したアルゴリズムによって、桁違いに異なります。それで、塩の粒で「割れやすさ」のスコアを取ってください。最近のパスワードへの攻撃のほとんどは、共通のパスワードを使用するか、パスワードハッシュを盗み取らずに再利用されたパスワードを使用します。

本当に、これは、他の人々が長年にわたって発見した、ある種の特別な意味を持つ「不正なパスワード」のリストを単に維持することに帰着します。私の推測では、セキュリティ担当者はそこから来ています。

12
Steve Sether

特定のパスワードが解読されにくいことを証明することは不可能です。

これらが「非常に脆弱」であるという(正しい)ステートメントの意味するところは、それらを生成するための推測しやすいアルゴリズムが存在することです。つまり、「QWERTYこれは、このようなキーボードで1日中指を押している人間にとっては簡単に認識できるアルゴリズムですが、そのようなキーボードのパターンは、実際には「コンピュータからは見えない」ので、事実、ほとんどのコンピュータプログラムはキーの物理的なレイアウトをまったく気にしません

同様に、YWJjZGVmZ2hpamts、これはかなり安全なパスワードだと思うかもしれませんが、文字列abcdefghijklのBase64エンコーディングであり、のように見えるため、実際には間違っています。文字列が主にビットパターンであるAIにとって完全に明白な

与えられた情報のビットをどれだけ簡単に表現できるかという概念は コルモゴロフ複雑度 と呼ばれます。単純な定義にもかかわらず、これは実際には非常にトリッキーな概念です。それは、すべてを表現する言語に大きく依存し、uncomputableです。あなたができる最善のことは、大きな標準ライブラリを備えた表現力豊かなプログラミング言語ですべての可能な短いプログラムを評価することですが、それが成功しない場合 重要な標準関数が1つ含まれている別の言語でパスワードを計算するための低エントロピーの方法がないことは決して保証されません。 QWERTYレイアウトについて知らなかった場合、asdfqwerzxcvは安全だと思うかもしれませんが、知っていれば完全に明白です。

結論:与えられたパスワードの低エントロピー表現を見つけたら、はい、それを禁止します。ただし、パスワードが実際にどのように生成されたかがわからない場合は、特定のパスワードが安全であることを誰か(program'sを含む)の額面で主張しないでください。本当に解読できないパスワードを保証したい場合、唯一の方法は、それらが量子力学的物理ランダムプロセスから出てくることを確認することです。


パスワードクラッキングに関連するすべてのプログラムshouldは、人間がそのようなパターンに頼る傾向があることがよく知られているため、キーボードレイアウトを知っています。また、23##24$$25%%26は、なしでも、数字の行がほとんどASCIIで並べられているため、キーボードのレイアウトを知らなくてもかなり簡単です。だから、これらのウェブサイトは本当にここでひどい仕事をしています。

これは、実行時の問題も無視しています。ここで行っていることは、unknownパスワードをブルートフォーシングするのと同じくらい難しいです。

11
leftaroundabout

「12345678」のようなパスワードは、必要に応じてランダムと見なすことができます。ランダムパスワードのジェネレータを使用する場合、「12345678」が生成される確率は「4h2Ud8yG」と同じです(英数字のパスワードのみを考慮)。また、「12345678」は、「00000000」から「ZZZZZZZZ」の範囲でランダムにブルートフォースにすると、「4h2Ud8yG」と同じくらい壊れにくい場合があります。しかし、真実はパスワードはランダムであるだけでなく、lookもランダムであるべきだということです。どうして?攻撃者は辞書やパターンに基づいてブルートフォースを使用することが多いため、単語やパターンに基づいていないパスワードはより安全です。また、パスワードを覚えやすくするために単語やパターンを使用すると、同じ人物が使用する他のすべてのパスワードも同じように覚えやすくなる可能性があります。したがって、攻撃者がパスワードの1つを盗んで「John75」のように見える場合、「名前+番号」、「単語+番号」、またはいくつかのバリエーションなどのパターンを総当たりすることで、パスワードの大部分を破る可能性があります。しかし、攻撃者がパスワードの1つを盗み、それが「4h2Ud8yG」のようにランダムに見える場合、攻撃者はパスワードから情報を抽出することができません。

だからあなたが持っているそれらのパスワードは本当に安全ではないと言うときあなたは正しいです。彼らはあなたが彼らが持っていると思うすべてのエントロピーさえ持っていません!そして、これは、パスワードエントロピーが、パスワードがどのように見えるか、またはパスワードが作成される方法に基づいているためです。 「1!2 @ 3#4 $ 5%6 ^」のようなパスワード、「数字の後に記号が続く、6回」のように考えると、(10x10)^ 6 = 10 ^ 12の可能性があります。これは、小文字と数字で構成される単純な8文字のパスワードの可能性よりも低くなります。36^ 8 = 2.8 x 10 ^ 12の可能性。しかし、「同じキーの数字とそれに続く記号、昇順で1から始まる、6回」のようなパスワードの例を考えると、可能性の合計は1つだけです。

10
reed

まず、これらのパスワード強度インジケーターはガイドラインであり、絶対的な真実ではありません。

次に、パスワードの安全性、または解読にかかる時間は、いくつかの要因によって異なります。これをよりよく理解するには、最初にパスワードが「壊れる」方法を理解することが重要です。

パスワードに対する3つの一般的な攻撃があります。

  1. 攻撃者はパスワードを推測してサービスにログオンしようとします
  2. 攻撃者は別の違反で同じユーザー名/パスワードの組み合わせを見つけ、違反していないサービス(資格情報のスタッフィング)に対してこれを使用しています
  3. 攻撃者はサービスのデータベースダンプを入手し、パスワードハッシュを入手しました。彼らは今、ハッシュをプレーンテキストのパスワードを決定するために総当たりにしています。

攻撃者がパスワードを推測するのを防ぐために、ある種の「エントロピールール」[〜#〜]と[〜#〜]を適用してレート制限しますログオン試行。このように、攻撃者はサービスを直接総当たりすることはできません。

資格情報の詰め込みを防ぐのはより困難です。パスワードをどの程度強固にしても、ユーザーが別の侵害されたシステムで同じパスワードを使用していて、そのシステムが平文でそれを保存している場合は、ほとんど役に立ちません。

一部の企業(特にAmazon、LinkedIn、OpenTable)はデータ侵害にアクセスして顧客に警告しさえしている これらの侵害は上記の企業の外にあるにもかかわらず 。これは、クレデンシャルのスタッフィングからの保護に役立ちますが(やや!)、少し離れている可能性があります。

最後に、典型的な総当たりのパスワードハッシュがあります。これは、攻撃者が何らかの方法でユーザーのパスワードハッシュを入手し、ハッシュからプレーンテキストを推測しようとしている場所です。ここでは、何百年もかけてロープを破るのにかかるとよく耳にします。

通常、攻撃者はocl-hashcatなどのツールと一般的なパスワード(RockYouまたはTop1000のパスワードなど)のワードリストを組み合わせて使用​​して、平文を推測します。攻撃者は文字、数字、特殊文字のあらゆる組み合わせを総当たりする可能性もありますが、これはワードリストよりも効率が悪いため、一般的ではありません。

攻撃を遅くするために、通常は次のものを使用します。

  • 強力なハッシュ関数の使用(MD5の代わりにBcrypt)
  • 個別のパスワードをソルトする(攻撃者に1つずつブルートフォースを強制するため)
  • ユーザーが弱いパスワードを使用できないようにする
  • ユーザーが以前のデータ侵害でパスワードを使用できないようにする(ワードリストは以前に侵害されたパスワードで構成されているため)。

最後の2つについては NIST推奨 以下:

記憶されたシークレットを確立および変更する要求を処理するとき、検証者は、予想されるシークレットを、一般的に使用、期待、または侵害されていることがわかっている値を含むリストと比較する必要があります(SHALL)。たとえば、リストには以下が含まれる場合がありますが、これらに限定されません。

  • 以前の違反コーパスから取得したパスワード。
  • 辞書の単語。
  • 反復または連続する文字(「aaaaaa」、「1234abcd」など)。
  • サービスの名前、ユーザー名、およびそれらの派生語などのコンテキスト固有の単語。

明らかに、サービスで違反が発見されると、サービスはパスワードのリセットを強制する必要があります。

要するに、何世紀にもわたってナンセンスを壊すことについて混乱しないでください。パスワードの保護に関して適切な一連のプラクティスを適用してください。これらのパスワード強度インジケーターに完全に依存してセキュリティ態勢を判断しないでください。これは NISTリンク から始めるのが良いでしょう。

6
keithRozario

パスワードに関するオンラインアドバイスのほとんどは、親しみやすくするためであり、確固たる基盤はまったくありません。これは特に、80年代の神話に基づいた、いわゆるパスワードの複雑さに当てはまります。幸いなことに-NISTの元の作者が去年、それを認めた後-途中でそうなっています。

not脅威が実際に何であるかを理解せずに、パスワードの強度を推定できます。保護しようとしているものを考慮せずにいくつかの計算を実行するだけなので、簡単なオンライン計算機はすべてナンセンスですagainst

あなたの脅威はbrute-forcingである可能性があります。このような場合、最初にすることは、総当たり攻撃を許可しないことです。誰かが間違ったパスワードを100回入力し、そのユーザーをロックアウトしていない場合、パスワードの強度とは関係のない何か間違ったことをしています。 2番目にすべきことは長さ>複雑さ(Googleに投稿する、すばらしい記事)です。

脅威がパスワードハッシュに対する辞書攻撃である場合、最初に行うことは、ハッシュを適切に保護することです。 2つ目は、適切なソルトと適切なハッシュ関数(bcrypt、scryptなど-MD5またはSHA1ではない)でハッシュすることです。 3つ目は、単純な辞書の単語と順列を許可しないことです。クラッカーが使用するのと同じロジックを使用します。それらのいくつかは公開されています。

脅威がショルダーサーフィンやポストイットのステッカーである場合は、avoid無意味な複雑さの強制を行い、ユーザーが実際にパスワードを覚えてすばやく入力できるようにする必要があります。繰り返しますが、長さ>複雑さ。最小長は12文字にしますが、複合語を使用できます。

等々...

簡単に言うと、脅威を考慮し、簡単な数学の見積もりを信頼しないでください。

4
Tom

好奇心から、私は非常に有名なWebサイト(ログインページ)でこれを確認しましたが、これには何百年もかかることになると述べていました。

そのような主張は常に非常に疑わしいものです。

基本的な問題は、攻撃者がパスワードを破るのにかかる時間を計算するには、攻撃者のモデルが必要であることです。

理想的な攻撃者は、最も可能性の高いものから最も可能性の低いものの順にパスワードを試します。もちろん、実際の攻撃者は、特定のパスワードがどれほどの可能性があるかを知らないため、推測する必要があります。通常、攻撃者は、ある種の辞書(攻撃者がある程度の能力を持っている場合は、通常の英語の単語よりもはるかに多くのものを含みます)と生成ルールの束。

問題は、パスワード強度メーターで使用される攻撃者のモデルが、実際の攻撃者の辞書のサイズとルールの複雑さにおいて、多くの場合かなり遅れていることです。


パスワードの制限に関する根本的な問題は、ユーザーにどんな制限を課しても、多くの場合、パスワードを渡すために最低限のことを行うことです。

これでエントロピーを追加できるようになりました。通常、パスワードを変更してルールを通過させるための最低限の方法は複数ありますが、追加されたエントロピーは単純な分析が示唆するよりもはるかに小さくなります。たとえば、ユーザーにパスワードに数字を追加させる場合、不釣り合いな数のユーザーが1を選択する可能性があります。

4
Peter Green

パスワードの脆弱性を事前に定義することが可能であると想定しているため、混乱している可能性があります。その代わり、実際の攻撃者が最初に試行するパターンに大きく依存します。日和見攻撃者は、おそらく辞書または漏洩したパスワードのリストを最初に試すでしょう。しかし、適度な労力をかけるだけで、かなり正確になります。これが、パスワードに関するガイドラインを施行するのに苦戦する理由です。ほとんどのガイドラインでは、ユーザーがパスワードを選択するときに特定の最小要件に従うように促しています。 これはブルートフォースを助けることができます。例えば、

  • パスワードの最小文字数がX文字の場合、攻撃者はXより短いすべてのパスワードを試すことを回避し、代わりに多くのユーザーが最小長の要件しか満たしていないと想定して、X、X + 1、またはX + 2のパスワードに集中できます。

  • 「小文字、大文字、数字、特殊文字」などのパターンを適用すると、攻撃者は正確にこのパターンを使用してパスワードを導出するユーザーがいると想定できます。

  • 彼らのパスワードが漏洩したパスワードであるかどうかをフィードバックすることは可能ですが、その場合、パスワードが通過するまでパスワードを変更してしまうリスクがあります。繰り返しになりますが、これは攻撃者がブルートフォースを指示する方法についてのヒントです。

  • 最大長はかなり明白です。最良のケースでは、長さが長すぎると、パスワードマネージャを使用する利点が減少します。最悪の場合、ログインシステムの根本的な技術的制限を示唆する可能性があります。また、攻撃者が費やさなければならない最悪の場合の努力に上限を設けます。

3
MauganRa

パスワードが解読するのがいかに難しいかを判断するには、そのエントロピーを知る必要がありますが、これらのサイトでは明らかにできません。彼らは最善の推測をして、結果としてそれを返します。

パスワードのエントロピーを正しく計算するには、攻撃者が作成者と同じくらいパスワードがどのように作成されたかを知っていると想定する必要があります。作成者が常に2つの10文字の単語の1つを含む場合、攻撃者はそれらの単語の1つが存在することと、それらが何であるかを知る必要があります。

これから、パターンが非常に低いエントロピー(7ビット以下)であることがわかります。しかし、ウェブサイトはそれを知らないので、彼らはそれをはるかに高く評価します。適切なパスワードが必要な場合は、ランダム性が必要です。ユーザーにランダム性を受け入れさせ、パスワードにランダム性を含める方法は問題です。他の誰かにパスワードまたは同等のパスワードを実行させる方法を理解しようとする方が良いでしょう。

1
jmoreno