多数投稿オンライン討論 「マスターパスワード」または「確定的、サイト固有」パスワードのメリット生成ツール。
一般的な考え方は、関数hash("my_master_password", "facebook.com")
は、どのWebサイトでもアカウントのパスワードを確定的に与えることができるということです。
利点:
パスワードの保存に固有のリスクがあるKeepassやLastPassのようなキーストアを避けます
Webサイトアカウントごとに固有のパスワードを提供します
欠点:
特定のサイトでパスワードを更新できない
誰かがあなたのマスターパスワードを発見した場合、彼らはすべてのアカウントのあなたのパスワードを持っています
このアイデアをキーストアソリューションと組み合わせてこれらの欠点に対処するパスワードマネージャーはありますか?
これは事実上、パスワード生成関数hash("my_master_password", "facebook.com", "facebook.com_password_from_keystore")
を意味します
my_master_password
はどこにも保存されないため、記憶するか、システムの外部に保存する必要があります。残りの引数keystore_password
とfacebook.com
を取得するために、キーストアには個別のログインキーfacebook.com_password_from_keystore
があります。
利点:
キーストアが危険にさらされている場合、攻撃者が「my_master_password」を発見する方法はまだないため、攻撃が発見されたら、パスワードをリセットするための時間があります。
facebook.com_password_from_keystore
の新しいランダムな値を生成してパスワードを循環させる
キーストアに保存されない、またはキーストアに送信されない情報がスキームにあるのが好きなので、このような製品の使用を検討します。その他の欠点は何ですか?
追加のコンテキスト:LastPassやKeePassなどのソリューションが見かけほど信頼されている理由を本当に理解していないと思います。それらがパスワードの一意性と複雑さの問題に対する優れたソリューションであることがわかりますが、LastPassや、KeePassファイルの保存に一般的な他の一般的なファイルストレージソリューションに違反がありました。
パスワードの保存に固有のリスクのため、パスワードマネージャーを信頼できないと言います。しかし、私はあなたの解決策の改善がどこにあるのか本当に理解できません:
守秘義務:
パスワードマネージャは通常、持っているもの(暗号化されたファイル)と知っているもの(マスターパスワード)に依存します。正しいマスターパスワードと適切に実装されたパスワードマネージャーを使用していると仮定すると、保管時の暗号化ファイルのセキュリティは許容範囲内であると想定されます。マスターパスワードに自信がない場合は、ファイルにローカルストレージを使用することでセキュリティを向上できます。それを使用するときに攻撃者が復号化されたデータベースまたは暗号化に使用される対称鍵と同じものを抽出するためにプロセスメモリを読み取る可能性がある場合の主な脆弱性-ただし、これは、使用するシステムが侵害されていることを前提としています。
あなたのシステムでは、あなたはまだパスワードマネージャを持っているので、同じ攻撃が可能であり、あなたが知っている何か(あなたのマスターパスワード)を追加するだけです。システムが危険にさらされている場合、キーロガーを使用するか、プロセスメモリを読み取ることによって、システムを傍受することもできます。また、すべてのサイトパスワードに共通するため、簡単には変更できないため、盗聴されやすくなっています。
誠実さ:
システムはパスワードマネージャーに依存しているため、ここでは改善できません。パスワードボールトが変更された場合、使用できなくなったツールで終了し、不要な変更を特定するために同じ方法を実装する必要があります。
可用性:
システムはパスワードマネージャーに依存しているため、ボールトのバックアップが必要です。追加のマスターパスワードがあるので、システムはそのバックアップの侵害に対して脆弱ではないと主張できます。
マスターパスワードはあなたが知っているものにすぎず、すべてのパスワードを変更する必要があるため変更される可能性が低いため、これは良い習慣ではありません。だから、あなたはあなたが持っているものの部分の防御力を下げようとしています。なぜなら、私はあなたがあなたが知っているものの部分を強化したと思いますが、私見ではそうではありません。
TL/DR:セキュリティーはほとんど追加されないため、主要なパスワードマネージャーアプリケーションでアルゴリズムが採用される可能性はほとんどありません。また、セキュリティの実装の詳細には脆弱性が潜んでいるので、私は自分でロールバックしないことを強くお勧めします。 パスワードの保存に固有のリスクとは何かをもう一度考え直して、それらをどのように軽減できるか疑問に思う必要があります。
最終ハッシュとキーストアの両方に対して、マスターパスワードを1つだけ使用します。
このスキームでは、標準のパスワードマネージャがすでに提供しているものに加えて、追加のセキュリティは追加されません。
それでは、パスワードマネージャからのパスワードファイルが漏洩したとしましょう。通常、これらはマスターパスワードから派生したキーを使用して暗号化されます。そのため、攻撃者はサイト固有のパスワードを取得するためにマスターパスワードを解読する必要があります。
マスターパスワードとキーストレッチアルゴリズムの両方が適切である場合、それは難しい注文です。しかし、議論のために、攻撃者が成功したとしましょう。その後、彼女は(a)マスターパスワードと(b)すべてのサイト固有のパスワードを知っています。彼女が提案したハッシュを計算することを彼女が止めることは何もありません。
スキームへの攻撃は、LastPassへの攻撃とまったく同じように機能し、最後に単純なハッシュが1つ計算されます。
最終ハッシュとキーストアに異なるマスターパスワードを使用します。
ここでは2つのパスワードを使用しています。比較する関連ベンチマークは、2つのパスワードを組み合わせた長さの1つのパスワードを使用して、通常のパスワードマネージャーを使用することです。
これがセキュリティ上の利点であるかどうかを議論できます。すべてのパスワードにアクセスするには、攻撃者は最初にキーストアのパスワードをブルートフォースで強制し、次に最後のハッシュのパスワードをブルートフォースにする必要があります。後者の場合、攻撃者はキーストアにある1つの正しいパスワードと結果を比較する必要があります。
攻撃者がそのようなパスワードを持っていない場合は、システムが優れています。
攻撃者がそのようなパスワードを持っている場合は、通常のパスワードマネージャーの方が適しています。長さn/2
の2つのパスワードをブルートフォースで強制することは、長さn
の1つのパスワードをブルートフォースで強制するよりもはるかに簡単です。
したがって、私の推奨は、強力なパスワードを持つ通常のパスワードマネージャーを使用することです。強力なパスワードを使用すると、攻撃者はとにかく無敵になります。
パスワードマネージャーを使用して、ランダムにサイトパスワードを選択し、暗号化したファイルに保存します。
一方、「ハッシュマスターパスワード」アプローチでは:
site_password = hash(master_password, site_metadata)
およびsite_metadata
が、パスワードと同じ推測攻撃を認める低エントロピー値であるためです。多くのサイトでは安全でないパスワードの保存を実践しているため、これは非常に心配です。site_metadata
に推測攻撃を仕掛けるためにパスワードボールトファイルを盗む必要はありません。これにより、サイトのパスワードを発見する可能性が高くなります。site_metadata
をファイルに保存することで、ユーザーがそれを(誤って)覚えたりする必要がないようにします。それから、暗号化されたボールトアプローチ以上に、攻撃者がファイルを作成して攻撃の手助けをすることができます。マスターパスワードハッシュの支持者が彼らのアプローチを最も頻繁に主張する利点は、盗む暗号化されたパスワードボールトがないことです。しかし、この主張の問題は、これは実際には不利 —そのようなファイルがない場合、つまり、パスワードmustがそのようなファイルなしで回復可能であることです、ユーザーが記憶できるデータから。したがって、攻撃者はファイルをまったく盗むことなくスキームを攻撃できる可能性があります。マスターパスワードハッシュは、暗号化されたボールトよりも厳密に悪いです。