ハートブリードのためにすべてのパスワードを変更する必要がありますか
ハートブリードバグのため、すべてのオンラインパスワードを変更する必要がありますか？
編集：
GitHub で脆弱なサイトのリストを見つけ、すべての重要なサイトをチェックしました。リストによると、私が本当に心配していたことはすべて脆弱ではありませんでした。
短い答え：はい、すべてのパスワード。
長い答え：一見すると、証明書の秘密鍵を変更するだけで済みます。しかし、いくつかの理由により、すべてのパスワードが影響を受けます。理由は次のとおりです。
理由1：連鎖攻撃
- 誰かが証明書の秘密鍵を入手しました。その時から、彼はそのサイトへのすべてのトラフィックを解読することができました。
- そのWebサイト上のサービスにログオンした場合、パスワードが明らかにされました。おそらく最も一般的なサービスはWebメールなので、それを例として使用しましょう。
- 攻撃者はあなたの電子メールを読んで、あなたが使用している他のサービスを見つけました。
- 攻撃者はパスワードリセットメカニズムを使用して、すべてのパスワードをリセットし、リセットされたメールを確認して、もちろんそれらのメールを削除しました。
- これで攻撃者はすべてのサービスにアクセスできるようになります。
- Webサイトの所有者（秘密キーが盗まれた）は、セキュリティリークを認識して修正しました。このサービス（Webメールを想定）は脆弱ではなくなりました。
- ウェブサイトの所有者がリークについて通知し、パスワードを変更するように求めます。
- 攻撃者は、パスワードを変更したためにログインできなくなったことに気付かない限り、他のすべてのサービスを引き続き使用できます。つまり、頻繁に使用するサービスでは、誤用されたことが検出される可能性が高くなります。頻繁に使用しないサービスについては、気付かないでしょう。
そのため、影響を受けるかどうかに関係なく、少なくとも各パスワードを確認する必要があります。
この攻撃ベクトルの良い点：この問題に気づくでしょう。
理由2：データベースへのアクセス
- 誰かが証明書の秘密鍵を入手しました。その時から、彼はそのサイトへのすべてのトラフィックを解読することができました。
- Webサイトの管理者がログオンして管理、管理などを行う場合、攻撃者は管理者のパスワードを入手します。
- そのパスワードを使用して、攻撃者はデータベースにアクセスします。
- データベースのセキュリティに応じて、攻撃者は読み取ることができます
- ユーザー名
- 平文のパスワード（最悪の場合）
- 脆弱なパスワードハッシュ（MD5ハッシュ、無塩）（悪いケース）
- 安全なソルトハッシュ（最良の場合）
- 攻撃者はハッシュからパスワードを計算します
- ウェブサイトの所有者が問題を修正しました
- ウェブサイトの所有者からパスワードを変更するよう通知されます。
ユーザーとしてのあなたは、パスワードがデータベースにどの程度安全に保存されたかを知ることができないため、攻撃者がパスワード（およびユーザー名）を持っていることを考慮する必要があります。他のサービスでパスワードを再利用した場合、これは問題です。
悪い点：他のサービスへのログインは引き続き機能するため（自分自身と攻撃者にとって）、影響を受けるかどうかはわかりません。
唯一の解決策：すべてのパスワードを変更します。
理由3：シークレット証明書のキーが漏洩するだけではない
I looked at some of the data dumps
from vulnerable sites,
and it was ... bad.
I saw emails, passwords, password hints.
XKCD＃135 による投稿：
そのため、攻撃者は、データベースへのアクセスがなく、連鎖攻撃がなくても、パスワードをプレーンテキストで既に入手している可能性があります。
注意事項
2番目の問題 @ Iszyで説明 はまだ残っています：サービスがHeartbleedの問題を修正するまでパスワードを変更するのを待ちます。使用するすべてのサービスが更新された場合にのみ、すべてのパスワードを確実に変更できるため、これはヘンアンドエッグの重要な問題です。
いいえ。ハートブリードのため、すべてのパスワードを変更する必要はありません。誰もがパニック状態の羊の巨大な群れになっているように見えるため、すべてのパスワードを変更する必要があります。パスワードを変更すると、最終目的地に向かって走っているときに何か便利なことをすることができます。これが羊の運命です。
比喩的にあなたの死に落ち込んでいる間、あなたは、人間の脳が最も必要とされるときに適切に機能を停止するという人間の脳の驚異的な能力について考える時間があります。
編集：わかりました、それで終わりです。ここでは、より退屈な方法で表現された考慮事項をいくつか示します。
ハートブリードバグは深刻です。誰もそれに異議を唱えません（まあ、一部の人はそうですが、常にそのような人がいます）。その その他の回答 は、ターゲットサーバーのセキュリティを深刻に侵害するためにバグをどのように利用できるかを詳しく説明しています。実際には、これはバグがread-onlyバッファオーバーランであっても、-mayはwriteと同等の結果をもたらすには十分であることを意味しますバッファオーバーラン（古典的な種類のバッファオーバーフロー）。
しかし、3つの明確な誤謬が心の底から「討論」全体で働いています（うーん、「討論」は正しい言葉ではないかもしれません。「パニックモブ」は真実に近いでしょう）。これらは次のとおりです。
Fallacy 1：このバグは例外的です。これは明らかに間違っています。適切に管理されたベテランコードでは、バッファオーバーフローは比較的まれですが、Cコードの重要な部分には、いくつかのオーバーフローが潜んでいる必要があります。 Webサーバーの場合、OpenSSLのオーバーフローおよびその他の脆弱性（たとえば、use-after-free）だけでなく、Apache（およびそのモジュール！）とカーネルも関連します。このようなことは定期的に発生し、年に数回発生します。センセーショナルな記事が主張するように、10年に1回ではありません。
この誤りは、ずさんな管理者がセキュリティパッチを定期的に適用しなくても済むという考えで、ずさんな管理者を慰めるので危険です。彼らはニュースに当たったときだけ何かをするだけで「反応する」ことができると信じています。
Fallacy 2：我々はすべて2年前にハッキングされました。これは定量化の一時停止にかかっています：何かが理論的に可能な場合 =、それが起こったと仮定してください。これは、「セキュリティに関する妥協を望まない」という正当な主張によって正当化されることが多く、これはベストプラクティスと現実の両方に反するだけです。すべてのセキュリティ機能には、予想されるリスクと結果とバランスを取る必要のあるコストがあります。このケースでは、バグが2年間存在しているため、<insert-name-here>が2年間このバグを悪用したことは明らかであると主張する人もいます。
ハートブリードがサーバーのコードスタック全体でこれまでにない最後のバグであると主張するのは愚かです。経験によれば、alwaysは、少なくとも1つのバグがどこかにあることがわかります。その結果、攻撃者が何年も前にバグを認識することを「許可」されている場合、攻撃者は依然としてサーバーを制御しています。ハートブレッドバグのためにキーまたはパスワードをリセットする必要がある場合、同じロジックでを再実行する必要があります。そしてまた。これは実際には妥当ではありません。ある時点で、潜在的な脆弱性があってもサーバーが攻撃されない可能性があると想定する必要があります。 証明済みであったコードのみを使用してバグをなくす代替案（その可能性は高いです。NASAはコード行あたり20000 $を費やして、バグをできるだけなくし、しかもバグがある）;またはWebサーバーをまったく操作しない（バグのない唯一のコードは、存在しないコードです）。
Fallacy 3：パスワードをリセットするとサーバーがクレンジングされます。攻撃者が強く信じていると仮定しましょうdidハートブリードバグを悪用し、あなたの最も深い秘密をすべて手に入れました。あなたはそれについて何をしますか？あなたはパスワードと秘密鍵をリセットし、そして...それがすべてですか？このような一連のアクションは、サーバーで秘密キーとユーザーのパスワードがonlyプライベートのものである場合にのみ意味があります。それでは、どのようなサーバーですか。公開データのみを含むサーバーにアクセスするためにパスワードが必要なのはなぜですか？
他の答えが言うように、攻撃者は「データベースへのアクセスを獲得する」ためにバグを利用した可能性があります。その時点でデータベース全体のコンテンツは彼の所有物であり、ハッシュされたパスワードだけではありません。彼はまた、その一部を変更し、敵対的なコードを植えた可能性があります（例：バックドアを利用して戻ることができる）。このような攻撃者が仕掛ける可能性のあるいたずらの終わりはありません。単にパスワードをリセットして証明書キーを変更することは、タイタニックキャビンの床の過剰な湿気をモップで処理するようなものです。それは要点を逃しています。妥協があったかもしれないと本当に信じているのなら、すべきことはただひとつ 軌道からそれを核に入れる だ。 compromiseの場合、パスワードをリセットするだけで、自分の正当性を真剣に信じていないことを示しています。実際に攻撃の疑いがあるためではなく、PRのパスワードをリセットした。
それであなたはそれを手に入れました：誇張されたバグ（深刻ですが、まだ誇張されている）に起因する空想的な攻撃への効果的な対策は、貧弱なシステム管理者を悪い状態に慰めます実践。羊さん、クリフさんに会ってください。きっと仲良くなると思います。
Heartbleedに対して脆弱である/脆弱であったサイトでのパスワードの変更は、以下の場合にのみ有効です。
- このサイトはOpenSSLの脆弱性のないバージョンにパッチされているか、別のSSL実装を使用するように切り替えられています。
- 新しいSSL証明書が発行され、サイトに適用されました。
- サイトの古いSSL証明書は取り消されています。
上記のすべてはエンドユーザーとして制御できないため、サイトの所有者から脆弱性が完全に緩和されたことを確認するまで待つことをお勧めします。
とはいえ、すべてのWebサイトに複雑で一意のパスワードを使用するなどのベストプラクティスに従うと、パスワードの侵害による影響を軽減するのに役立ちます。これは、最新の最大の脆弱性ニュースが何を言っているかに関係なく、あなたがすべきことです。また、影響を受けるサイトでのみパスワードを変更する必要があり、他のすべてではないため、このような問題に対する独自の応答を簡素化するのにも役立ちます。
はい、パスワードのalways変更allを変更する必要があります。
誰かがあなたのパスワードを危険にさらしたかもしれないときをあなたは決して知りません。そして、それが最悪の事態が起こっていない今日と確信することなく、唯一の賢明な行動は、自分を守るために可能なあらゆる手段を講じることです。
明日も同じです。