「何世紀にもわたって破る」というパスワードの使用について混乱

私はこのパスワードについて話しています - 23 ## 24 $$ 25 %% 26 と、パターンで表示される特殊文字で構成されている類似のもの。

職場(金融会社)では、ユーザーが選択できないような不適切なパスワードのリストを作成していました。特定のサイクルやパターン、および特殊文字を挟む連続した数字が含まれているという特徴2回)。

好奇心から、私はこれを非常によく知られているウェブサイト(そのログインページ)でチェックしました、そしてこれは何世紀もの間破るのにかかるだろうと述べました。

リストには壊れるまでに数年かかるが、非常に脆弱な例がいくつかあります。

[email protected]#4$5%6^ [email protected]#4$5%6^7& [email protected]#d$e%f^

今、私はリストと混同して立っています、私がこれらの特定の種類のパスワードを脆弱であるとマークし、たとえ彼らが破るのに非常に長い時間がかかったとしても

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

Edits:

  • This website I am talking about, but won't name, on which I tested the password is pretty much known to every ethical/unethical hacker, almost every user here on Stack Exchange and many big/small companies (as they use its services).

  • We do not store passwords in plain text. We use a nice, not home-brewed, hashing algorithm.
    An incident led us to review our password policies, and we created a separate database db-2 on a different machine, wherein we stored simply_hashed_newly_created user's password (no salt, nothing, just hashed_password) without storing who_created, when_created details. We did this for short period only. Any password change too went into this database. While, in our original database db-1 sat secure_salted_passwords.
    We kept creating a list L of hashed vulnerable passwords as well, following a pattern, and we were left amused when we matched L & db-2 - we saw multiple groups of similar passwords, with certain patterns. L and db-2 were later erased from the systems.

  • db-2 was kept on a highly secure machine and was safe, won't disclose the exact details here. We are aware that even air-gaps or electric-sockets aren't secure. Both db-2 and L were destroyed.

  • Worry not about passwords posted here, as we have already conducted our small experiment, and all those specific set of users have been made to reset their passwords (of course, a new password different from the old one). That's the reason, I came here posting few samples.
    And, I have commented here earlier too, that I posted a sample of passwords from the generator's logic which created a very huge list of hashed passwords, which may or may not be in db-2. Again, since all those users have a new password, so no worries, everything is safe and secure.

  • Since I know the generator's working, I tested few password-samples on a website, and we got confused over which ones to be allowed or disallowed, over what criteria.

Thanks a lot for your answers, accept my gratitude. Based on the answers, for the time being, we have postponed any kind of restriction to be put over password's choice.

48
あなたは本当にNIST 800-63-3を見直して、彼らがパスワードに関してどのような勧告をするかを見るべきです(「暗記された秘密」)。
追加された 著者 Sergio del Amo,
haveibeenpwned.com/Passwords を使用することも検討してください。
追加された 著者 coder,
とにかく、あなたのユーザがしばしばそのような種類のパスワードを使っていることを一体どうやって知っていますか?パスワードを平文で保管していますか、それともハッシュ化する代わりに暗号化していますか?それとも、選択したパスワードがこれらのカテゴリに従っているかどうかを確認するために、パスワード変更中に実行されるチェックを正しく実装しましたか?
追加された 著者 coder,
私の昔のRadeon 5870でも、14文字というのはそれほど多くありません。
追加された 著者 bedouger,
@ JOW同意した。私が手動で「壊した」最初のパスワードは、1990年代初頭のものです。私は電話番号を何トンものボイスメール回線があることがわかっている会社に調べ、電話で次の番号を入力しました: 2580456 。どのように私はとても簡単に入りましたか?電話パッドを見てください:私はちょうど数字の入った真ん中の線を下って行き、それから中央でも同じです。簡単で怠惰なパスワードいくつかの技術者が物事を設定するために使用しました(まだ使用しますか?)。
追加された 著者 Harper Shelby,
「データベース内の類似したハッシュ」を参照するときの意味あなたはたまたま同じハッシュを複数回持っていますか?
追加された 著者 Martin B,
ウェブサイトは「これを破るには何世紀もかかるだろう」と言ってはいけません。彼らは、「これはに何世紀もの時間がかかるだろう」と言うべきです。そしてそれらはすべてあなたの基本的な攻撃者よりもはるかに愚かです。
追加された 著者 Stu,
@Baldrickk私はxkcdストリップであることも覚えていません。ただし、古典的な xkcd.com/538 のように聞こえます。
追加された 著者 James McMahon,
私はあなたがこれらのパスワードを使用しないことを願っていますまたはそれらがオンラインで掲示された今、二度と同じパターンから生成されたもの。無塩のDBもセキュリティリスクのように思えます。
追加された 著者 jpmc26,
彼らが無視しているのは、データベース内の似たようなハッシュの規則性が高まっていることです(...)。私たちは、自作ではない素敵なハッシュアルゴリズムを使います。パスワードは同様のハッシュを生成します。 継続は、セキュリティハッシュ関数にとって望ましい品質ではありません。 。あなたは通常雪崩効果を持つものが欲しいです。
追加された 著者 Ray,
これらのパスワードは何世紀もの間(ブルートフォース)破られるのにかかるかもしれませんが、それほど推測に時間はかかりません。
追加された 著者 BetterLateThanNever,
追加された 著者 butterfly,
パスワードエントロピー(長さや複雑さとは対照的に)は、これらのWebサイトが決定することを求めているものであり、正確に解決することはほとんど不可能です。
追加された 著者 Tom Castleberry,
@ sbecker私はそれがxkcdのストリップであることを覚えていません。見つけたら、リンクを張ってもいいですか。
追加された 著者 EDP,
あなたの素敵なハッシュアルゴリズムがpbkdf2、bcrypt、scrypt、アルゴンなどのどれかであることを願います。適切なパスワードハッシュアルゴリズムを使用している人は、それが内蔵されているので、saltについては言及していません。私は、単に「salted hash」と言っても、知識の欠如を示す悪臭がすると言っています。
追加された 著者 LTR,
事件の後、なぜあなたが無塩のパスワードハッシュのリストを維持し始めたのか理解していません。それを維持することは、それがトラブルを求めているようです。多要素認証を検討しましたか?
追加された 著者 Zach Lipton,
@ZachLipton:新しいガイドラインを公開する前に疑問点を確認したいため、この無塩のパスワードリストは短期間だけ維持され、別のマシンで db-2 に継続的に移動されました。平文のパスワードを見た人はいませんでしたが、脆弱なパスワードリストもハッシュされていましたが、平文のリストではありませんでした。これらのパターン化パスワードのハッシュを生成するジェネレータを使用しました。私たちはそのジェネレータに置かれたロジックを知っているので、私は db-2 にあるかもしれないしないかもしれないいくつかのパターンを投稿しました。両方とも一致すると、 db-2L のリストは削除されました。
追加された 著者 Chloe,
@Dissimilis:私の編集はそれらのアルゴと一緒に働いたことがない人々に向けられていました、そして彼らがその働きについてあまり知らない可能性があるかもしれません。私はそれらを修正することによって失礼に聞きたくないので、私は平易な英語で「編集」の下にものを投稿しました。私はあなたの懸念に感謝します、そしてありがとう、そして 'nice'で私を信じています私は本当に素晴らしいアルゴリズムを意味しました。私はsecurity.stackexchangeでここで育ちました、あなたのような偉人を聞いて、私を信頼してください!
追加された 著者 Chloe,
ところで、あなたがそのWebサイトでパスワードを試したとき、おそらく彼らは彼らの辞書に追加するでしょう。
追加された 著者 Robert Elliott,
彼の同僚に自慢している男とのXKCD漫画はどれほど複雑で、長く、そして彼の非常に安全なパスワードマネージャにおける彼の新しいパスワードが「難しい」かはわかりません。それから彼は立ち上がってコーヒーを飲みます。もう一方が座って、パスワードマネージャに保存されているパスワードを書き留め始めます。
追加された 著者 LisaC,

10 答え

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

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

それで、そう、それがあなたの目標を満たすならば、そのような明白なパターンを禁止しなさい。

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

84
追加された
@バットマン真剣に、パスワードが平文で格納されているか、可逆暗号化によって格納されているかどうかを調べます。どちらの場合も、それを達成するためのキャンペーンがすぐに変更された場合、それはあなたのビジネスにとって重大な脅威となります。パスワードがハッシュ化されるのではなくプレーンテキストとして保存されている場合、ハッカーがデータベースに侵入してそれらすべてを取得しても、パスワードがどれほど優れているかは関係ありません。
追加された 著者 Chetan Sachdev,
この答えについてはよくわかりません。ヒューリスティックに、これらのパスワードに低いエントロピー値を割り当てるのは簡単です。しかし、ヒューリスティック分析では、エントロピーからアスキーへの符号化方式がすでに推測できることを前提としています。私はBTCがBIP39で正しくバランシングを得たと思います...
追加された 著者 Haakon,
「私たちのデータベースでも同じようなパスワードの集まりです」:あなたは自分のパスワードを平文のままにしていますか?これは、ここまででより大きなセキュリティ問題になるでしょう。あなたはそれらを(固有の塩で)ハッシュしているべきです。
追加された 著者 djsadinoff,
使用されている特定のパターンがわからなくても、Hashcatのようなツールのルールセットは最も一般的な(そして珍しい)パターンとそのすべてのバリエーションを適用します。
追加された 著者 forest,
これらのオンライン計算機のほとんどは、非常に古くなった技術と検索アルゴリズムを想定しています。
追加された 著者 Mark Buffalo,
これは私たちのデータベースでも同様のパスワードのグループで、繰り返し話をしています。このOPとコメントの両方のステートメントは、どちらか一方に保存していると仮定しています。プレーンテキスト(これは拒否されました)または雪崩効果なしでハッシュアルゴリズムを使用しているそうでなければどうやってそれらが似ていることを知ることができますか?)後者は、もちろん、わずかに優れていますが、どちらも悪いものです。
追加された 著者 Ray,
最後の段落では+1。それはまさに私が質問を読んだときに思ったことです。
追加された 著者 Peter J,
このウェブサイトは、話題になっていますが、名前を挙げませんが、すべての倫理的/非倫理的ハッカー、ここでスタックに参加しているほぼすべてのユーザー、およびすべての大小企業に知られていますそのサービスを使用してください...私はここに来て提案を求めています。 ランダム性が大幅に低下したことに加えて、私たちのデータベースでも同じようなパスワードの集まりが注目を集めました。
追加された 著者 Chloe,

ちょっとした好奇心から、私はこれを(ログインページで)よく知られたウェブサイトでチェックしました、そしてそれはこれが破るのに何世紀もかかるだろうと述べました。

そのようなウェブサイトは福音とみなすことはできません。多くのものは価値がなく、良いものであっても結果は慎重に解釈されなければなりません。まず第一に、原則として、強度チェッカーは、パスワードは弱いと最終的にあなたに伝えることができますが、パスワードが強いということをあなたに証明することはできません。メーターはモデル化されていません。極端な例については、この Ars Technica の記事では、非常に長いパスフレーズに対するクラッキング攻撃の成功について説明しています

ほぼすぐに、かつて頑固なパスワードが大量に流出しました。彼らは含まれています:「私は今までにまたあなたの顔を見るつもりですか?」 (36文字)、「はじめは言葉(29文字)」、「創世記から啓示まで」(26)、「何も思い出せない」(24)、「thereisnofatebutwhatwemake」(26)、「givemelibertyorgivemedeath」(26 )、および "eastofthesunwestofthemoon"(25)。

もう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

It estimates 2 minutes for [email protected]#4$5%6^, [email protected]#4$5%6^7& and [email protected]#d$e%f^ with a 10B/second attack (3 years at 10k/second), so those it thinks are even worse. (Though it does score all of them 4/4. The meter is recommending that you actually accept any of these passwords, because it estimates they're reasonably likely to resist attacks if your application has implemented slow password hashing. But its analysis actually proves they're weak to a specific attack that you should mitigate.)

zxcvbnは、ほとんどのユーザーがパスワードを選択する方法についての一般的な知識にのみ基づいて攻撃をモデル化していることに注意してください。また、パスワードは弱いという意味では強力だという意味ではありません。zxcvbnでは、何世紀にもわたってクラックする可能性があると推測しています。私たちが知っているArs の記事は実際には実生活の中で割れています。

さて、私はリストを混乱させています。これらの特定の種類のパスワードを脆弱であるとマークし、たとえ非常に長い時間がかかってもユーザーがそれらのパスワードを要求しないようにすべきですか。

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

あなたが絶対にやるべきことの一つは、bcryptまたはArgon2パスワードハッシュ関数で、強力なパスワードハッシュを使うことです。これが、上記のzxcvbnの結果が「低速ハッシュ」と呼んでいるものであり、おそらくパスワード入力が破られにくくなります。 (しかし、繰り返しになりますが、強度チェッカーが、パスワードの中には間違いなく安全ではないと言っているものもありますが、安全ではないことを覚えておいてください。)

あなたがさらに考慮すべきこと:

  • ごく一般的であることが知られているパスワードの少数(数千)のリストを使用し、それらを禁止します。そのようなリストはオンラインですぐに見つけることができます。
  • Troy Huntの500M +パスワード違反リストを使用するこれにはオンラインAPIもあります。 ( K匿名性に関する資料を必ず読んでください。実際にはパスワードをAPIに送信しません。)
  • zxcvbnのようなスマート強度メーターライブラリを使用します。これは、あなたが考えているもののようなパターン検出に代わる、より洗練された代替手段です。
  • 2つ目の認証要素を実装して、パスワードがあなたの唯一の防衛線にならないようにします。
40
追加された
@バットマン私はあなたがゆっくり一つの "安全な"そして承認されたパスワードを持つことに向かっていると思います。言及したパターンは、ユーザーが意図的に作成したものではありません - 特定のパスワードを禁止することでパターンの作成を強制しました制限を多くすればするほど、全員を1つのパターンに強制します。いったん壊れると、それは壊滅的です。より少ない規則、より多くの教育。馬電池の定番を修正してください。
追加された 著者 Clever Human,
@Batmanあなたのユーザがあなたの制限を欺く方法をパターンの共有を開始した場合、それらの制限は彼らにとって難しすぎ、それは大きなセキュリティリスクです。何人かのユーザ(例えばオタク)は数字と記号を覚えることができますが、他の人(ほとんど残りの部分)は覚えられません。あなたはユーザーを教育する必要があります。
追加された 著者 Clever Human,
それでは、多要素認証を実装していますか。
追加された 著者 ck3g,
「zxcvbnが後者の3つと同じくらい脆弱だと考えているすべてのパスワードを捉えるには、1兆2000億エントリのリストが必要です」このパスワードの弱点は、自己相関をビットレベルで計算することによって検出できます。4文字のシフトでは、自己相関は非常に高くなります。
追加された 著者 FatalSleep,
@Batmanデータベースに類似のパスワードハッシュがある場合、それより深いものは間違っています。適切なアルゴリズム(PBKDF2、bcrypt、scrypt、Argon2iなど)を使用している場合は、すべてのユーザーが同じパスワードを持っていても、それらは異なるハッシュを持つことになります。同じパスワードで同じハッシュが得られる場合、攻撃者は全員のパスワードを同時に解読する可能性があるため、大きな利点があります。アルゴリズムが広く使用されているものであれば、既製のレインボーテーブルも利用可能かもしれません。
追加された 著者 Valerie Anderson,
@DerekElkins:きっと、近いうちにその方向に動くでしょう。
追加された 著者 Chloe,
@Agent_L - 「ユーザーを教育する必要がある」と指摘した。新しいパスワードの設定中に問題が発生する可能性がある非常に古い(および尊敬される顧客)がいます。それらを教育すると言うのは正しいことです。
追加された 著者 Chloe,
@Agent_L:私たちは誰にもパスワードの設定パターンを強制することはせず、ただ記号を含め、全体の長さが8以上の数字をルールとしました。しかし。ファイナンスドメインでは、ユーザーのデータ保護が最優先事項であるため、パスワードの作成に対して一定の制限を設ける必要があるかもしれません。
追加された 著者 Chloe,
あなたの努力を評価してください。このような遅いハッシュは、何世紀にも渡ってパスワードを破るために使用されてきたため、脆弱なパスワードと脆弱でないパスワードを区別しています。安全のため、ここではユーザーが頻繁に使用するさまざまなパスワードの種類を私たちのサイトに掲載していません。私達が経験していることは私達がパスワード作成のためにセットパターンがユーザーの間で勢いを増していることがそれをクロスチェックしたとき私達のDBに保存された類似のハッシュを持つことです。神が禁じられている、我々が破られたならば、それらが推測されるパターンであるので、遅さはこれらの特定のパスワードを救うであろう。 br Troy リンクを見てください。
追加された 著者 Chloe,

パスワードを推測できるということは、ユーザーが選択する可能性のあるパスワードの種類について何かを知っていることを意味します。私たちはみんな「パスワード」は英語の単語なので推測できることを知っています。しかし、英語を知っている必要があること、または英語または他の関連言語が単語を綴る方法の概念を持っている必要があることを知るために。英語や他の人間の言語に晒されたことのないBetelgeuse周辺のどこかのエイリアンは、「パスワード」が容易に推測できることを知りません。言い換えれば、パターンはやや主観的なものであり、(あるレベルを超えると)事前に予測することを非常に困難にします。

同様に、あなたのリストにあるパスワードの中には、そのパターンが何であるかがすぐにはわからないものがあります。 1!2 @ 3#4 $ 5%6 ^一見すると多少「ランダム」に見えますが、QWERTYキーボードでは1〜6で、他の文字をすべてシフトキーで交互に入れ替えることにすぐに気付くでしょう。

さらに、誰かがあなたにパスワードCPE1704TKSを見せてくれたなら、あなたはそれが良いパスワードだと思うかもしれません。それは文字と数字の10文字を持っています、それに決定可能な繰り返し可能なパターンはありません、そしてそれはどんな人間の言語の単語でもありません。あなたは間違っているでしょう、そしてそれは映画Wargamesの終わりに核ミサイルを発射するのに使用されるパスワードであるのでそれは素晴らしいパスワードではありません。

このため、ランダムなWebサイトから(長さと文字の選択に基づいて)「クラッキング性」の計算を使用することは、ほとんど偽物です。さらに、それらはパスワードハッシュを入手する誰かに依存していますが、それ自体が大きなセキュリティ上の妥協です。彼らはあなたがハッシュがどれくらい速くかかるかを知っていることを意味するのでそれらは二重に偽である。ハッシュ速度は、選択したアルゴリズムに応じて何桁も異なります。だから、塩の粒で「割れやすさ」の点数を取る。最近のパスワードに対する攻撃のほとんどは、一般的なパスワードを使用するか、パスワードハッシュを害されずに再利用されたパスワードを使用します。

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

13
追加された
@ベンここで何を言っているのかよくわかりません。私はあなたが他のリストから独立してあなた自身のリストを維持するべきであるという意味ではなく、リストを維持するときあなたが他の人々のリストを考慮に入れるべきではありません。実際には何があなたにとって意味があるのか​​を決定します。たとえば、5億のパスワードを禁止することは、すべての人にとって正しいアプローチではないかもしれません。
追加された 著者 Steve Sether,
「他の人が長年にわたって発見した「不適切なパスワード」のリストを単に維持すること」に関しては:あるいは単に他の人のリストおそらくあなたのものよりはるかに大きいです
追加された 著者 Ben,
「最近のパスワードへの攻撃の多くは、一般的なパスワードを使用したり、パスワードを再利用したりしています」 - 同意した。
追加された 著者 Chloe,

与えられたパスワードが解読されにくいことを証明することは不可能です。

これらが「非常に脆弱である」という(正しい)文によってあなたが意味するのは、それらを生成するためのより簡単に推測できるアルゴリズム、すなわち「そのような単純なパターンでQWERTYキーボードの数列を打つ」ということです。これはたまたまそのようなキーボードで一日中指を押すことに費やす人間にとっては認識しやすいアルゴリズムであるが、そのようなキーボード上のパターンは実際にはかなり「不明瞭」である。キーの物理的なレイアウトについてはまったく気にしないでください。

私は YWJjZGVmZ2hpamts のような例を同じようにうまく与えることができます。これはかなり安全なパスワードだと思うかもしれませんが、実際には間違っているでしょう。なぜならそれは文字列 abcdefghijkl </のBase64エンコーディングであるからですそして、それはAIにとっては完全に明白に見えるかもしれません。

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

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


Any program concerned with password cracking should know keyboard layouts though, because it's well-known that humans tend to resort to such patterns. Also, 23##24$$25%%26 is pretty easy even without knowing the keyboard layout, because the number row is almost ordered in ASCII. So, these websites are really doing a terrible job here.

That's even disregarding run-time problems. What you're doing here is just as hard as brute-forcing an unknown password.

11
追加された
"パスワードが実際にどのように生成されたのかわからない場合は、指定されたパスワードは安全である""量子力学的な物理的ランダムプロセス" は生成されません実際には、実際にはパスワードをより安全にします。私のハードウェア乱数発生器が「パスワード」の提案されたパスワードを出力するならば(それは非常にありそうもないですが不可能な発生ではありません)。それから実際の言葉でそれは私が私のパスワードとして私がいつも「パスワード」を使うという事実によってそれを選択したかのようにちょうど同じくらい安全である(または安全である)。
追加された 著者 Zrb0529,
生成方法を知っていると、安全なパスワードを生成するその方法の傾向がわかりますが、その方法を使用して生成された特定のパスワードのセキュリティについては何もわかりません。そのためには、ユーザーについて知っている必要はなく、攻撃者について知っておく必要があります。これら2つの文を除いて、これはあなたの答えが実際に何についてであるかです。
追加された 著者 Zrb0529,
確かにそれは公平です、それで私の主なポイントはあなたがパスワードを生成するためのユーザーメソッドに関してあなた(システムのメンテナ/システム)が知っている情報は実際には関係ないということでしたそのユーザーのパスワードのセキュリティ。ランダムなプロセスを使用してパスワードを生成することに関するユーザーのポイントは、(全体として、多数のパスワードを超えて)保持されています。 メンテナ/システムからは、彼らがどうやって手に入れたかは問題ではありません。あなたの最後の文章は基本的には成立しません、それがどのように生成されたかは maintaner/system とは無関係です。それが現実さ。
追加された 著者 Zrb0529,
特に、あなたがおそらく攻撃者を知ることができないということが、私の主張の大部分を占めています。あなたは彼らがおそらくしようとしているいくつかのことを知っていることができます、そして確かにこれらに対してフィルタリングするのは理にかなっています、しかしあなたは彼らが しようとしないことを知りません。ですから、戦略が何でも構わないのであれば、戦略は最も安全です。
追加された 著者 Hui Wang,
@LyndonWhite「ありそうもないが不可能ではない」 - 8文字しかない場合、これはやや有効なポイントです。一般的に、指数関数的にありそうもないイベントを不可能と見なすことは理にかなっています。技術的に言えば、あなたのパスワードチェック方法が、間違った瞬間にプロセッサを通過して戻り値をfalseからtrueに反転させることによって中断されることも可能ですあなたはどこにも行かない、まったく不可能なシナリオ。
追加された 著者 Hui Wang,
@ Lyndon白なし、同意しません。それが何であるかは関係ありません。単一のパスワードのセキュリティは、最終的には無意味な概念です(これも、明らかに安全でない pwdsの小さなサブセットを除く)。エントロピーによって客観的に評価できるのは生成方法だけです。そして、どのような特定のメソッドがメンテナにとってもユーザにとっても重要ではありませんが、ジェネレータエントロピーは重要なのはだけです。
追加された 著者 Hui Wang,

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

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

10
追加された
正確には、それらは十分なコルモゴロフ複雑さを持つべきです。
追加された 著者 user23013,

まず、これらのパスワードの流れの指標はガイドラインであり、絶対的な真実ではありません。

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

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

  1. 攻撃者がパスワードを推測してサービスにログオンしようとしている
  2. 攻撃者が別の違反で同じユーザー名とパスワードの組み合わせを発見し、現在、それを違反していないサービスに対して使用している(資格情報の詰め込み)
  3. 攻撃者はサービスのデータベースダンプを入手し、パスワードハッシュを持っています。プレーンテキストのパスワードを決定するためにハッシュがブルートフォースを強いられています。

攻撃者がパスワードを推測することをまっすぐに防ぐために、私たちはある種の 'エントロピールール'を強制しますそしてログオン試行をレート制限します。このようにして、攻撃者はあなたのサービスを直接ブルートフォースすることはできません。

資格情報の詰め込みを防ぐのはより困難です。パスワードをどの程度強力にするかにかかわらず、ユーザーが別の違反システムで同じパスワードを使用していて、そのシステムが平文で保存している場合は役に立ちません。

一部の企業(特にAmazon、LinkedIn、OpenTable)はデータ侵害にアクセスし、顧客に警告を出しています - たとえこれらの違反が会社の外部にあったとしてもこれは資格証明の詰め込みから保護するのに役立ちます(多少ですが)が、少々遠すぎるかもしれません。

最後に、パスワードハッシュをブルートフォースする典型的な方法があります。これは、攻撃者が何らかの形でユーザーのパスワードハッシュを入手したところで、ハッシュから平文を推測しようとしているところです。ここで私たちはそれが何世紀にもわたって破壊されるという傾向をよく聞きます。

通常、攻撃者はocl-hashcatのようなツールを一般的なパスワードの単語リスト(RockYouやTop1000のパスワードなど)と組み合わせて使用​​し、プレーンテキストを推測します。攻撃者は、文字、数字、特殊文字のあらゆる組み合わせをブルートフォースする可能性もありますが、これは一般的ではありません。ワードリストよりも効率が悪いからです。

攻撃を遅らせるために、私達は通常頼ります:

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

最後の2つについては、 NIST推奨をご覧ください

記憶された秘密を確立し変更する要求を処理するとき、検証者は一般的に使用される、期待される、または危殆化されることが知られている値を含むリストと見込みの秘密を比較しなければならない。例えば、リストには以下のものが含まれます(ただし、これらに限定されない)。

  • 以前の侵害コーパスから取得したパスワード
  • 辞書の単語。
  • 繰り返し文字または連続文字(例:「aaaaaa」、「1234abcd」)。
  • サービス名、ユーザー名、およびその派生語などの文脈固有の単語。

明らかに、彼らのサービスに違反が発見されたら、サービスはパスワードリセットを強制するべきです。

一言で言えば、ナンセンスを破るために何世紀もかかることについて混同しないでください。パスワードの保護に関して妥当な一連のプラクティスを適用してください。あなたは良いはずです。あなたのセキュリティ状態を決定するのにこれらのパスワード強度指標に完全に頼らないでください。この NISTリンクから始めるのが良いでしょう。

6
追加された

ちょっとした好奇心から、私はこれをよく知られているウェブサイト(そのログインページ)で調べましたが、これは何世紀にもわたって破綻すると述べていました。

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

根本的な問題は、攻撃者がパスワードを破るのにどれくらいの時間がかかるかを計算するためには、攻撃者のモデルが必要であるということです。

理想的な攻撃者は、最も可能性の高いものから最も可能性の低いものまで順番にパスワードを試します。もちろん、実際の攻撃者は、与えられたパスワードがどれだけありそうなのかを知らないので、通常はある種の辞書(攻撃者がやや競合している場合は通常の英語の単語よりもはるかに多くの単語を含みます)多数の生成規則

問題は、パスワード強度計で使用される攻撃者のモデルは、辞書のサイズと規則の複雑さの点で実際の攻撃者よりもかなり遅れていることです。


パスワード制限の根本的な問題は、ユーザーがどのような制限を加えても、パスワードを渡すために最低限必要なことがほとんど行われることです。

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

4
追加された

パスワードに関するオンラインアドバイスの大部分は、根拠のないもので、しっかりした基盤がなくてもです。これは、いわゆるパスワードの複雑さに特に当てはまります。これは、80年代の神話に基づいており、幸いなことに - NISTの最初の作者が昨年それを認めた後 - その解決策として。

実際の脅威を理解していなくても、パスワードの強度を推定することはできませんできます。彼らはあなたがに対してを保護しようとしているものを考慮せずにちょうどいくつかの数学を行うようにすべての些細なオンライン電卓はナンセンスです。

Your threat could be brute-forcing. In such case, the first thing to do is to not allow brute-force attacks. If someone enters a wrong password one hundred times and you're not locking him out, you are doing something wrong that has nothing to do with password strength. The second thing to do is length > complexity (put that into Google, great article).

あなたの脅威があなたのパスワードハッシュに対する辞書攻撃であるならば、最初にすることはあなたのハッシュを適切に保護することです。 2つ目は、適切なハッシュ関数(bcrypt、scryptなど - MD5やSHA1ではなく)を使用して適切にsaltしてハッシュすることです。 3つ目は、単純な辞書の単語や順列を許可しないことです。クラッカーが使用するのと同じ論理を使用してください、それらのいくつかは公に利用可能です。

If your threat is shoulder-surfing or post-it stickers, you want to avoid the nonsensical complexity enforcement, and make sure your users can actually remember their passwords, and type them quickly. Again, length > complexity. Make the minimum length 12 characters, but allow compound words.

等々...

一言で言えば:あなたの脅威を考慮し、ささいな数学の見積もりを信頼しないでください。

4
追加された
あなたが最後の文で1つのステートメントに質問全体を蒸留したので、支持を得ます。ブルートフォース計算機は他の9文字のパスワードと同じように '123456789'を扱うつもりです。攻撃者がブルートフォース(そしてブルートフォースのみ)を使用している場合、他の方法を使用している場合とは答えが大きく異なります。
追加された 著者 Jeremy,
面白い事実:私がパスワードセキュリティについての最近のスピーチを準備したとき、それは多くのオンラインパスワードツールがABCabc123だと思っていることがわかった! "§は本当に安全なパスワードです...
追加された 著者 Tom,

パスワードの脆弱性を先験的に定義することが可能であると想定しているため、混乱している可能性があります。代わりに、実際の攻撃者が最初に試すパターンに大きく依存します。日和見的な攻撃者は、おそらく辞書または漏洩したパスワードのリストを最初に試みるでしょう。しかし、中程度の労力でも、かなり正確になります。これが、パスワードに関するガイドラインを強制するのが敗北的な戦いである理由です。ほとんどのガイドラインでは、パスワードを選択するときに特定の最低限の要件に従うことをユーザーに推奨しています。これは、ブルートフォースを強要するのに役立ちます。 例えば、

  • 最小パスワード長X文字を使用すると、攻撃者はXより短いすべてのパスワードを試してみることを避け、代わりにX、X + 1、またはX + 2の長さのパスワードに集中することができます。最小長の要件。

  • 「小文字、大文字、数字、特殊文字」のようなパターンを実行すると、攻撃者はまさにこのパターンを使用して自分のパスワードを導出したユーザーがいると見なすことができます。

  • 自分のパスワードが漏洩したパスワードであるかどうかを彼らにフィードバックすることは可能ですが、合格するまでパスワードを変更するだけで済むというリスクがあります。繰り返しになりますが、これは攻撃者が自分のブルートフォースを誘導する方法についてのヒントです。

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

3
追加された
あなたはあなたのパスワードの長さの分析に非常に正しいです、私たちは確かに多くをすることはできません、しかし、確かに、私たちはパターンに従わないようにそれらを制限することができます。
追加された 著者 Chloe,

パスワードを解読するのがどれほど難しいかを判断するためには、そのエントロピーを知っている必要があります。彼らは最善を尽くしてそれを結果として返します。

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

これから、あなたのパターンは非常に低いエントロピー(7ビット以下)であることが分かります。しかしウェブサイトはそれを知らないので、彼らはそれをはるかに高いと評価する。良いパスワードが欲しいなら、あなたはランダム性を持たなければなりません。パスワードにランダム性を受け入れて含めるようにさせる方法は問題です。他のユーザーにパスワードまたは同等のパスワードを使用させる方法を見つけ出すことをお勧めします。

1
追加された