IMAP / POP3 / ASPは2要素認証を弱体化しますか？
Hotmail、Google、またはposteoにログインすると、設定した2FAを使用しないとログインできません。ただし、各プロバイダーには、Webクライアント経由で認証しないアプリの代替手段があるようです。
- Hotmail/Google：16小文字の「アプリ固有」のパスワード
- Posteo：IMAP/POP3
このアプリ固有のパスワードを使用すると、どのアプリでもアカウントに完全にアクセスできます。 Thunderbirdの同じアプリ固有のパスワードを使用して、電話のメールアプリを使用してすべてのメッセージを読むことができます。
Posteoの場合、2FAがセットアップされていないかのようにパスワードを入力するだけで、任意の受信トレイを読み込むことができます。
上記の状況を考えると、2FAが有効になっている場合、IMAP/POP3とアプリ固有のパスワードが2FAを完全にバイパスするため、どのように存在するのか理解できません。
ここで見逃している重要なことは何ですか？
あなたは何も見逃していません。
これは、2FAが有効な場合に特にオプトインする必要がある便利なオプションであり、2FAにいくらか反抗します。
そうでなければ、スマートフォンと電子メールクライアントは全く役に立たないか、少なくとも面倒です。
スマートフォンメールクライアントの場合：ほとんどの2FAオプションでは、スマートフォンが2番目の要素であるため、スマートフォンから大きなメリットはありません。 （そして、他のオプションは不可能かもしれません。例えば、iPhoneはyubikeysを使用できません）。
それにもかかわらず、2FAは、IMAP/POP3/SMTPパスワードが強力でそのアカウントに対して一意であり、接続がTLSによって保護されている場合にも役立ちます。それでも、フィッシングされたりスマートフォンを使用したりすることはできません。漏れません（強力であり、そこでのみ使用されるため）。
サーバー側での認証は魔法ではありません。アルゴリズムが行うことを実行するだけのアルゴリズムです。サイトで2FAが有効になっている場合、サイトはパスワードを要求し、それが正しいと想定して、2FAコードを要求します。サイトにアプリ固有のパスワードのようなメカニズムがあり、それを指定した場合、2FAコードは要求されません。とても簡単です。
アプリ固有のパスワードの利点は、アカウントへのアクセスが制限されたアプリケーションまたはサービスを構成できることです。通常、アプリ固有のパスワードを使用してアカウントを変更することはできません（サイトの設計が不適切であるかバグがある場合を除きます）。そのためには、マスターパスワードと2FAコードが必要です。
一般に、@ Craigに同意します
通常、アカウントの変更には使用できません
この部分を明確にするために：
アプリ/ドメイン固有のパスワードを組み合わせた2faは、技術的に可能なatm *）としてデジタルIDを安全に保護するための良い習慣です。つまり、なしよりも優れていますが、これは聖杯ではありません。 2faは、強化されたセキュリティレベルの（最も重要な部分）だけでなく、第2の要素（所有）を組み合わせてパスワードの「複雑さ」（心に留めておく必要がある）を下げる可能性があるため、パスワードセーフがなくてもログインを容易にしますアカウントのセキュリティが向上する可能性があります。 （私はあなたがこれをそのようにするべきだとは言いません;））
それでも：侵害されたアプリ/メールパスワードは、アカウントを悪用するために使用される可能性があります。他のシステムで口座を開設したり、正しいメールアドレスであなたに代わって注文したりすること。攻撃者でさえ、一般的にIDプロバイダーのパスワードまたはアカウントの詳細を変更することはできません。あなたはまだ回復することができます...もしあなたが虐待の使い方を知っているなら。
それでも：2faが不正なパスワードの上にあり、noアプリ固有のパスワードがある場合、falseのためにアプリ（メール）のセキュリティが「危険にさらされています」ウェブでの2faの肯定的な安全感;プロバイダーのセキュリティ設定に注意してください。「古いパスワード」を保持する方が安全な場合があります（ https://www.xkcd.com/936/ ）。
それにもかかわらず、アプリ固有のパスワードは、プロバイダーが生成するのと同じくらい安全です。また、特定のリソースへのアクセスを制限する場合にのみ、その利点が提供されます。 「ビッグG」のようなプロバイダーは、私の目には大きな仕事をしていません。パスワードは128ビットで生成され、エントロピーは低く（特別な文字などはありません）、このパスワードはAPIに制限なしで使用できるためです。与えられた「アプリケーション」はヒントにすぎず、取り消したい場合に使用します。
*）私が知る限り、2faを利用してメールクライアントを利用する高度なIMAP/POPプロトコルの既知のRFCはありません。そして、レガシーメールクライアントの「大きな」後方互換性の問題のために、私がそれを手に入れるとは思えません。
理由のために、このオプションを明確に許可する必要があります。パスワードがアクセスを許可するのに十分であるため、2FAを無効にします。
その理由は、コンピューターやスマートフォンでメールリーダーのような2FAを使用できないリッチクライアントが引き続きメールにアクセスできるようにするためです。 2FAの損失に対処するために予想される対策は、強力なパスワードを使用することです。 12文字以下のランダムな文字は使用しません。しかし、その場合、コンピューターまたはスマートフォンにパスワードを記憶させて入力させ、セキュリティは端末で処理されるため、それは実際には問題ではありません。
つまり、信頼できる安全なコンピューターまたはスマートフォンでのみ使用し、安全性の低い（または信頼できる）環境でのみ2FAを使用する必要があります。