web-dev-qa-db-ja.com

2つのパスワードは、2要素認証よりも優れたセキュリティを提供しますか?

1Passwordの新しいTeamsサービス を評価しているときに、多要素認証のサポートの不思議な欠如に気づきました。

がMFAの欠如について尋ねたとき、彼らは答えた

2要素よりも優れたセキュリティのために、マスターキーと組み合わせたアカウントキーを使用します。 https://teams.1password.com/security/

そのページは言う:

セキュリティの専門家は、複数の認証要素を使用することを推奨しています。パスワードなどの「知っているもの」と、携帯電話の認証アプリのような「持っているもの」です。

アカウントキーは、このアイデアを次のレベルに引き上げます。サーバーで認証するだけではありません。また、データの暗号化にも直接的な役割を果たします。マスターパスワードが指数関数的に強化されるため、これは重要です。また、ネットワーク経由で送信されることはないため、アカウントキーをリセットしたり、傍受したり、回避したりすることはできません。

「アカウントキー」は、基本的に生成される2番目のパスワードです。 1Password Teamsサービスにサインアップすると、「緊急キット」 [〜#〜] pdf [〜#〜] が送信されます。これは、印刷することを目的としています。アカウントキーが含まれており、マスターパスワードを書き留めておくこともできます。

アカウントキーは、ブラウザの ローカルストレージ に保存されます。新しいデバイスからログインする場合は、パスワードを入力した後、アカウントキーを手動で入力する必要があります。

私の知る限り、このアプローチは実際の2要素認証よりも著しくさらに悪いです。次のような攻撃者:

  • 印刷された緊急キットを入手する
  • PDFのコピーを取得します
  • 1password.comとの接続をMITMできますか
  • コンピュータにマルウェアをインストールします
    • ローカルストレージからアカウントキーを盗む、または
    • (マスターパスワードと共に)入力するときに注意してください

...非常に機密性の高いアカウントへの自由で継続的なリモートの検出不可能なアクセスに必要なものがすべてあります。

実際の2要素認証とは対照的です。セカンダリキーは別のデバイスに安全に保存されます。

  • マスターパスワードを取得するだけでは役に立ちません。攻撃者はオーセンティケータデバイスを所有する必要があります。
  • 侵害されたデバイス/接続を使用してログインしても、攻撃者がアカウントに継続的にアクセスすることはありません。認証デバイスによって生成されたワンタイムパスワード(TOTP)は、今後のアクセスには使用できません。

ここで何が欠けていますか?

14
josh3736

ああマーケティング。 (そして、彼らは愚かなものを商標登録しました)

ここでの問題は、彼らが本当に物事を正しく比較していないという事実にあります。彼らは、発信者の認証と秘密データの保護を混合し、それらを一緒にジャンブルしてから、その乱雑さを最初の部分だけに接線的に関連する何かと比較し、ロジックをひねった場合は正しいかもしれない大きな大胆な主張をします少し多すぎます。ナッツはアイスクリームを健康的にするので、アイスクリームとナッツを混ぜて野菜よりも健康的に呼ぶようなものです(それから得られる唯一のテイクアウトが良いアナロジーである場合は難しい...)。

しかし、実際には、これは2FAよりも優れていません。これは、実際には別個の要素を導入するものではなく、既存の要素(知っているもの)の別のインスタンスを導入するだけだからです。単一のパスワードよりもわずかに優れていますが、パスワードを盗むことができれば、もう少し努力して他のパスワードを盗むことができるでしょう。

LocalStorageからのキーを使用してブラウザーでパスワードの復号化が行われる場合、パスワードの保護が少し良くなる可能性があります(WebCrypto標準に言及しており、IEをサポートしていないように見えるため、これが行われる可能性があります)。

とはいえ、緊急キットは安全ではなく、緊急時に利用できるように設計されています。これは、絶対にアクセスが必要なブレークグラスシナリオ用です。これを手に入れれば、何があってもゲームオーバーです。

一方、実際の2FAでは、すべての攻撃を解決できるとは限りません。それでもブラウザとサーバーをMITMできる場合は、ユーザーパスワードとアカウントパスワードの両方、さらには2FAコードも取得できます(ユーザーの要求に失敗し、パスワードと2FAコードを使用して、秘密を盗みます)。

11
Steve

[開示:1Password for Teamsの開発者であるAgileBitsで働いています]

さまざまな脅威、さまざまな防御

正しく述べたように、アカウントキーは従来の2FAと同じものではありません。実際、数週間後にはケンブリッジのPasswordsConでこれについて話します。

覚えておくべき最も重要なことは、アカウントキーの目的が2FAの目的と同じではないことです。これは、サーバーが危険にさらされた場合にパスワードの解読を防ぐことを目的としています。

私たちのサーバーはあなたのSRPベリファイアを保存し、あなたの暗号化された秘密鍵を保存します攻撃者がそれらのいずれか(違反、インサイダー攻撃、保証)を取得した場合、そうでなければそれらのいずれかに対してマスターパスワード推測ルーチンを実行しようとする可能性があります。アカウントキーの目的は、サーバーのみの侵害に対するパスワードクラックの試みを実行不可能にすることです。

2FAの従来の概念はサーバー違反に対する防御を提供せず、弱いパスワードまたは再利用されるパスワードを奨励する範囲で、サーバー違反の結果を悪化させることに注意してください。状況によっては、2FAはこのゲートに2つのロックをかけるようなものです。

Gate with no fence. Sign says "Gate must be locked"

アカウントキーの盗難

また、前述のとおり、アカウントキーはクライアントコンピューターから簡単に盗まれる可能性があります。 iOSではiOSのキーチェーンを使用してある程度の保護を行うことができますが、デスクトップ、特にブラウザークライアントでは、マシンのユーザー権限のみでこれらを簡単に奪うことができます。明らかに、これらを保護するためのより良い方法が欲しいのですが、難読化を簡単に壊すためだけに難読化するために多大な努力を払うことは、実際の解決策ではありません。

最高のセキュリティプロパティの組み合わせ

マスターパスワードとアカウントキーを組み合わせる背後にある考え方は、

  1. マスターパスワード(頭にのみ保存される)は盗むのは難しいですが、簡単に推測できます。
  2. アカウントキー(デバイスに保存されている128ビットのエントロピー)は推測が困難ですが、クライアントデバイスから簡単に盗むことができます

つまり、これは攻撃者が2つのことを行う必要があることを意味します。また、特に、サーバー違反は、パスワードクラッキング攻撃を開始するのに十分な情報を攻撃者に提供しないことを意味します。

10

アカウントキーは、あなたが持っているものです。 お使いのコンピュータで生成

あなただけがあなたのアカウントキーを持っていて、それがあなたのデバイスを離れることは決してありません。

あなたが述べる

「緊急キット」が送られてきますPDF印刷用です。アカウントキーが含まれています

「送信済み」の意味がわかりませんが、メモに書いたり別のコンピューターにコピーしたりしない限り、キーがコンピューターから出ることはないとページに明記されているため、電子メールで送信することはできません。

これがより一般的な2要素認証(2FA)の実装よりも優れたソリューションであるとまでは言えませんが、アカウントキーなしではパスワードを復号化できないと述べています。つまり、誰かがマスターパスワードとパスワードデータベースを入手したとしても、それを解読することはできません。より一般的な2FAは、サイトへのログインを停止するだけであり、パスワードデータベースが取得されたら、復号化を完了する必要はありません。

1Passwordが推奨する限り

あなたはあなたのマスターパスワードを書き留めます

それはブルース・シュナイアーと多くの人が持っている意見です] 2 おそらく最も有名である。しかし、それは Digital InspirationsWashington Post 、および LifeHacker によっても提唱されています。それが良い解決策であるかどうかはまだ議論の余地があると私は言いますが、それは間違いなく明確な考えではありません。

アカウントキーで発生する問題の1つは、アカウントキーを別のコンピューターにコピーするたびに、公開されるリスクが高まることです。たとえば、モバイルアプリベースの2FAでは、モバイルデバイスについて心配するだけで済みます。とはいえ、モバイルデバイスを携帯する傾向があるため、アカウントキーを保存したコンピューターのコレクションよりも安全性が低い可能性があります。

7
Neil Smithline

ここで何が欠けていますか?

脅威モデル。

同期可能なパスワードマネージャーの脅威モデルはクライアントを完全に信頼し、サーバー上でゼロまたは最小限の信頼です。これは、サーバーとクライアントの両方で信頼を必要とする通常のWebアプリケーションの脅威モデルとは大きく異なります。

パスワードマネージャーの脅威モデルでは、ボールトのパスワードが侵害されると、ゲームはすでに失われます。クライアントが危険にさらされている場合は、すでに失っています。クライアントが危険にさらされると、すべてのシステムですべてのパスワードを変更する必要があり、新しいアカウントキーを使用して新しいパスワードボールトを作成する必要は比較的軽微です。

2FAの問題は、それが「認証」の形式であることです。 2FAのような認証システムは、主に(ユーザーではなく)サーバーを不正使用から保護することを目的としています。通常のサービスの場合、サーバーは大量の有用な情報とサービスを保持しているため、サーバーの不正使用が主な脅威です。ただし、パスワードマネージャーの場合、同期サーバーは暗号化されたBLOBのみを保持します。これは、ユーザーとクライアントだけが知っている復号化キーをまだ持っていない攻撃者にはまったく役に立ちません。

従来のパスワードマネージャーの脅威モデルでは、攻撃者はすでに暗号化されたパスワードボールトを持っていると想定する必要があります。このモデルが同期可能なパスワードマネージャーに転送される場合、同期サーバーが悪意のあるものであると想定する必要があります。この脅威モデルを考慮して見た場合、2FAは暗号化スキームの一部として使用できないため、2FAは有用なセキュリティ値を追加しません。

3
Lie Ryan

私は、会社がマーケティング志向の誇大宣伝で自分たちに好意を示したことはないと思います。ただし、セキュリティがより悪いと主張することは、おそらく反対方向に行き過ぎているでしょう。

個人ユーザーにとって、パスワードを書き留めることは、私たち全員がそうであると言われている主要な罪ではありません。はい、リスクはありますが、実際には、ほとんどの人にとってそれは低リスクです。あなたの家にアクセスできる人は限られており、通常あなたが知っている人です。 「スーパーシークレットパスワード」というタイトルで書き留める必要はありません。誰かが見つけたとしても、それが自分のパスワードであることが明らかではないような方法で書き留めることができます。一般的には、パスワードを書き留め、覚えやすい安全性の低いパスワードに制限するよりも、推測するのが難しい強力なパスワードを使用した方がよいでしょう。ビジネスの世界では、だれがオフィス/デスクを覗き見できるかについて同じコントロールができないため、少し難しいです。そのため、このシナリオでは、パスワードを書き留める際にもっと注意する必要があります。個人ユーザーにとって、大きな脅威はリモートアクターによるものであるため、リソースへのアクセスに必要なローカルでのあらゆるものが保護レベルを高めます。

私は、1Passwordは2FAよりもソリューションの方が「優れている」という議論を避けているべきだと思います。ただし、2FAについては多くの誤解があり、それは本当に問題ではありません。人々が2FAと呼んでいるもののほとんどはとにかく2FAではありません。それは実際には2SA(2段階認証)であり、そのように見ると、1Passwordのアプローチは実際にはそれほど違いはありません。

「実際の」2FAの場合、2番目の「要素」が必要です。これは、2番目のパスワード以外の何かを意味します。たとえば、SMSコードを電話に送信するシステムは実際には2FAではなく、2SAです。2つのパスワードがあります-2番目のパスワードを送信する必要があるかもしれませんが、それでもただのパスワード。

実際の2FAには別の要素が必要です。スマートカードまたは網膜スキャンはさまざまな要因です。ユーザーは、パスワードに加えてこれらのものを持っている必要があります。 SMSメッセージを使用した有名なGoogleハッキングでわかるように、攻撃者は携帯電話に保護をバイパスさせる必要はありません-SMSを入手するために電話会社をソーシャルエンジニアリングすることができます彼らが持っている電話にリダイレクトされたメッセージ。

128ビットのキーは、基本的なパスワードよりもセキュリティを確実に向上させます。そのキーをコンピューターに保存するのは危険ですが、ユーザーがコンピューターにアクセスできる場合は、すでにゲームオーバーです。別の読み取り専用のキーまたはカードにキーを保存することはおそらく良いでしょう(必要な場合にのみキー/カードをシステムに接続し、データを読み取る前にパスワードを要求してデータをさらに保護するとします)カード/キーから。

1Passwordのような企業にとって、これらすべての問題の大きな問題は、十分に安全でありながら、エンドユーザーにとっても便利で便利なスキームをどのように考案するかです。エンドユーザーの大多数は、これらすべてがどのように機能するかを実際に理解しておらず、キーとパスワードを安全に管理する方法を知るのに十分な知識を持っている人はほとんどいません。問題は、ユーザーが両方を望んでいることです。さらに悪いことに、多くのユーザーがキーを紛失すると、会社に連絡して「こんにちは、私のキーを紛失しました。私のデータを回復してください」と言って、ベンダーが怒るとき「申し訳ありませんが、それはできません」と言います。これらは、ベンダーが個人データをどのように見ることができるかについてのニュース記事が話しているときに憤慨する人々と同じです。

1
Tim X