Chromeでは、サインアップページを開くと、パスワードフィールドに入力して記憶するように求められます。私はこれを行い、次の一連のパスワードが生成されたときに提供されました:
suCipAytAyswed0
LUnhefcerAnAcg2
it2drosharkEweo
UndosnAiHigcir0
AKDySwaybficMi5
DorrIfewfAidty5
MeecradGosdovl9
KasEsacHuhyflo4
OngouHemNikEyd0
これらすべてにoneの数字のみがあり、3番目以外のすべての数字は最後にです。この正確なパターンで多くの可能性が得られる可能性は非常に低く、Chromeで生成された他のパスワードでも確認されているので、さらに生成された場合はそれが続くと確信しています。
これは奇妙に思えますが、奇妙なパターンを強制するよりも、文字と数字のランダムなコレクションとしてパスワードを生成する方が簡単ではないでしょうか。これらは覚えておくべきではないので? Chromeが他に何かするのはなぜですか?
Conorの答え は良い出発点ですが、Chromiumのソースを掘り下げると、状況は少し目立たなくなります(ただし、パスワードマネージャをまったく使用しないよりはましです)。
バージョン68までChrome follow FIPS 181は、大文字、小文字、数字を許可する15文字の読みやすいパスワードを生成します。結果に含まれていない場合 changes 最初の小文字を大文字にし、最後の小文字をランダムな数字に変更します。
残念ながら、FIPS 181のパスワードのエントロピーは、文字ではなく可変長の音節を生成するため、計算がかなり難しく、音節が許可されるかどうかを決定する多くのルールがあります。
不均一性には重大な影響があります。 1994 paper (192ページ)は、8文字のパスワードを持つ100アカウントのうち1アカウントに侵入するために、攻撃者は160万のパスワードを試すだけでよいと推定しています。長さを8から15に増やしてエントロピーを2倍にしても、それでもおそらく平均で60ビット未満のエントロピーです。1、ただし、これは大文字化によりわずかに改善されています。
元の標準 は大文字または数字をサポートしていないようであり、 実装2 50%の確率で音節の最初の文字のみを大文字にします(興味深いことに、チェックされた文字の array でy
がw
に置き換えられるため、y
が大文字になることはありません)。これは、文字ごとに約1ビットのエントロピーを追加するのではなく、大文字化によって音節ごとに1ビットしか追加しないことを意味します。音節の数は一定ではないため、これが実際に追加するエントロピーの量を決定することは困難ですが、1文字の音節の不足を考えると、平均して8ビット未満しか追加されません。
数字と記号は supported で、50%の確率で各1文字の音節を数字または記号に交互に変換します(記号機能は使用されません)。残念ながら、お気づきのように、一文字の音節は珍しい3なので、 ForceFixPassword
は通常、最後の小文字を数字に置き換えてしまいます。
もっと問題があるかもしれませんが、私はそれを見るのに少し疲れてきました。要するに、これはパスワードを生成するための非常に優れた方法ではなく、エントロピーは長さに対して予想されるよりもはるかに小さいものです。実際のところ、20人の場所でお気に入りの低エントロピーパスワードを使用しないので、平均的なユーザーにとってこれはおそらく問題ありませんが、高速ハッシュ(つまり、パスワードの 適切なパスワードハッシュ )。
Chrome 69の方がずっと見栄えが良いです。文字セットは大文字、小文字、数字、記号-_.:!
次の 読みやすくするために削除 :
l
(小文字のL)I
(大文字のi)1
(1桁目)O
(大文字のo)0
(ゼロ桁)o
(小文字のO)生成は adding によって機能し、各クラスのランダムな文字が、そのクラスの最小数に達するまで続きます。 デフォルト と現在使用されているように、これは1つの小文字、1つの大文字、および1つの数字です。
次に、残りのパスワードは filled であり、すべての文字クラスからランダムに選択された文字が使用されます(現在使用されていない各クラスの最大数を考慮)。
最後に、要件を満たすために予測可能なクラスからパスワードの先頭に文字が追加されたため、文字列は ランダムにシャッフル になります。読みやすさを向上させるために2つのダッシュまたはアンダースコアが隣接している場合、シャッフルは最大5回行われるため、エントロピーはごくわずかに減少しますが、その減少はごくわずかであり、許可されたシンボルからダッシュまたはアンダースコアを削除すると、悪化する)。
61の可能な文字で、完全にランダムなパスワードはログを持つでしょう2(6115)= 88.96ビットのエントロピー。包含/除外を使用して必要な文字を説明すると、88.77ビットのエントロピーが得られます。
61^15 all possible passwords
-53^15 passwords without digits 2-9 (0 and 1 are excluded)
-37^15 passwords without lowercase letters (l and o excluded)
-37^15 passwords without uppercase letters (I and O excluded)
+29^15 add back passwords excluded twice for lack of digit and lowercase
+29^15 add back passwords excluded twice for lack of digit and uppercase
+13^15 add back passwords excluded twice for lack of lowercase and uppercase
-5^15 remove all-symbol passwords that were excluded then added back
追加のシャッフルによっても少しは削られますが、今は計算する時間がありません。結局、パスワードには88ビットを超えるエントロピーが必要です。これはかなり良いことです。
古いジェネレーター まだ存在します バージョン69ですが、私が開発ビルドをテストしたとき、新しいジェネレーターを使用していました。古いジェネレーターを使用する方法があるかどうかはわかりません。
1.平均エントロピーは、不均一な分布では必ずしも有用ではありません。 元の1975年の論文 は、単一のパスワード(たとえば、「password」)を生成するジェネレーターの例(29〜30ページ)を示します。 50%の確率、それ以外の場合は高エントロピーパスワード。平均エントロピーは高いかもしれませんが、パスワードがすぐに推測される可能性はまだ50%あります。それでも、 1994年の分析 から推定すると、最悪の場合でも40ビットをはるかに超えるはずです。
2.実装は実際にはChromeのものではありませんが、互換性のための小さな変更を加えた [〜#〜] apg [〜#〜] プログラムから取得されます
3. Testing with apg
は、単一文字の音節が実際にパスワードの約33%で発生することを明らかにしますが、それらの70-75%は最後に単一文字の音節しかありません。
重要で正確な警告から始めましょう:
http://dilbert.com/strip/2001-10-25
実際のオッズを見ると、62の可能な文字(a-zA-Z0-9)があるため、すべてが均等に分散していると仮定します。これは、特定の文字が数字である可能性が〜16%であることを意味します。
合計136文字を表示しました。これは、表示した9文字ではなく、平均して21桁になることを意味します。 1000回のランダムな試行を実行すると、標準偏差4.3のこのような実行で平均21.5桁が得られます。つまり、9桁しかない136文字の文字列は、約3シグマの外れ値です(ランダムな確率による0.3%の変化のみ)。もちろん、これはあなたがあなたの例から省いたより多くの数を持つどんな例も持っていなかったと仮定しています。
これは、数字の不足が単なるランダムではないことを示唆しています。これはいくつかのことを意味する可能性があります。Googleが使用しているパスワード生成アルゴリズムは、末尾に数字を挿入するか、パスワード生成アルゴリズムまたはエントロピーのソースに問題があるかのどちらかです。彼らの出所を見ない限り、それらのケースのどれがより可能性が高いかを言うのは難しいです。もちろん、最初に数字がある例があるので、最後に数字を貼り付けるほど単純ではありません。したがって、これがパスワード生成アルゴリズムの意図的な結果である場合、それらのアルゴリズムは非常に奇妙であり、何か別のことが起こっていると思います。
Update上記のAndrolの回答によれば、Chromeのパスワード生成アルゴリズムは実際に非常に奇妙なことをしています。
もちろん、これは実際の質問に答えるものではありません。これらのパスワードには十分なエントロピーがありますか?未知のランダム性の桁を無視すると、これは少なくとも長さ14のランダムな文字列と考えることができます。このような文字列(適切なCSPRNGを使用していると想定)は、1.06e24の可能な値、または〜80ビットのエントロピーを持ちます。比較のために、文字または数字で構成される15文字の長い文字列のエントロピーは〜90ビットです。それは「十分な」エントロピーですか?まあ、それは答えるのがはるかに難しい質問です。それは場合によって異なります-そのパスワードは、md5を使用し、オフラインのクラッキングリグのデータベースをリークするWebサイトに保存されていますか?パスワードをプレーンテキストで保存するWebサイトに保存されていますか(その場合、エントロピーの量は重要ではありません)?最新のベストプラクティスでパスワードを保護するWebサイトについてはどうでしょうか。この回答は有用な比較を提供し、プレーンなsha256の場合、80ビットのエントロピーを含むパスワードは事実上解読できないことを示唆しています(多くの警告があります)。
https://security.stackexchange.com/a/168511/149676
その結果、数字が適切にランダム化されていなくても、パスワードは十分長いため、予見可能な将来に十分なエントロピーがあると言えます。
Chromeがこのようなパスワードを生成し、たとえばp ^&7 + 4 + {ZgfnP#P /ではなく、なぜ生成するのかという答えにつながる2つの誤った仮定があります。
最初に、パスワードは覚えておくべきではないため、完全にランダムであると想定します。ではない。 AndrolGenhaldの回答で詳しく説明されているように、Chromeは、多くのランダムパスワードジェネレーターと同様に発音可能なパスワードを作成します。
意味不明なパスワードの代わりに発音可能なパスワードを使用すると、入力エラーが減り、パスワードが電話などで他の人に渡されるようになり、覚えやすくなります。 Chromeパスワードは記憶されていないことになっていると思いますか?最近、1台のデバイスだけでインターネットにアクセスする人はほとんどいません。
次に、パスワードは複雑である必要があると想定します。これは、何度も改ざんされてきた一般的な誤解であり、最も公式なものは、NIST SP-800の複雑さの推奨事項の撤回です(例: https://www.passwordping.com/surprising-new- password-guidelines-nist / )。
パスワードは、何よりもlongである必要があります。 Chromeはその条件を適切に満たします(12文字は、重要ではないWebアプリケーションの現在の推奨最小値です)。
これらの事実に照らして、Chromeが生成するパスワードは、modernのパスワード標準を満たしています。改良点については、確かに可能ですが、それらは確かに正しい方向に進んでいます。
これは私の推測ですが、パスワードを覚えやすくしたり、パスワード入力ボックスに転記したりする試みである可能性があります。奇数番号の配置に加えて、提供された例はほとんど発音しやすいように見え、他のパスワードジェネレーターが同様のことをするのを見ました(例 LastPassには、生成されたパスワードを「簡単に言うことができるオプションがあります" )。これを行うための公開アルゴリズムがあります(例 https://exyr.org/2011/random-pronounceable-passwords/ )。
それらを発音可能にして、ランダムに配置されているように見えることで、エントロピーが明らかに減少しますが、実際のアルゴリズムを知らなければ、どれだけの量かを言うことはできません。 Chrome=開発者が生成されたエントロピーを評価し、使いやすさの利点が失われたエントロピーを上回り、残りのエントロピーは依然として比較的安全であると判断した可能性があります。