ブルームバーグ認証システムには、従来の2要素に比べてどのような利点がありますか？
Bloombergクライアントには、サーバーを認証する興味深い方法があります。これには次の一部が含まれているようです。
- 点滅する四角形を表示する安全なWebサイトにログインする
- ポータブル指紋リーダーに対して指をスワイプ
- フラッシュを読み取ることができるようにリーダーを画面に置く
- 指紋リーダーがコードを表示する
- 次に、コードがWebサイトに入力されます。
私はこれまでにこの認証を見たことがありませんし、私が観察したものよりも、存在するものにはおそらくもっとたくさんあるでしょう。
この認証システムの詳細は何ですか？これは従来のRSA 2要素認証に比べてどのような利点がありますか？
これらのすべての手順が必要ですか？それは使いやすさを妨げているようであり、私が見た他のシステムよりもはるかに多くのエンドユーザートレーニングを必要とします。
編集-追加情報
プロモーション 情報 、および エンドユーザーマニュアル
免責事項：私はこれまでこれらの端末を使用したことがなく、説明しているシステムについて私が知っている唯一の知識は説明自体です。
認証のしくみ
これが実際に行っていることです-
- Webサイトにログインします。
- 生体認証データを指紋リーダーに提供します
- ウェブサイトは指紋リーダーにいくつかの「チャレンジ」値を提供します
- 指紋リーダーは、受け取った生体認証データとWebサイトから提供されたチャレンジデータを組み合わせ、指紋と1回限りのチャレンジの両方の特定の組み合わせに固有の結果を出力します
- 次に、Webサイトはその認証コードを読み取り、登録されたユーザーが端末の前にいるユーザーであることを確認します
保護されているもの
このテクノロジーはかなり効果的ですが、ユーザーが考えているような保護は提供されません。 あなたを守るためにそこにあるのではなく、Bloombergを守るためにそこにあります。
興味深いことに、このテクノロジーは、フィッシング、詐欺、またはMITM攻撃からユーザーを保護しません。しかし、それはブルームバーグを海賊行為から保護します。
ブルームバーグの端末は非常に高価であり、通常1台の端末はそれを支払う人にとってだけでなく、通常はオフィス全体がアクセスの恩恵を受けることができます。そのため、サブスクリプションを直接の同僚と「共有」する一定のインセンティブがあります。ブルームバーグはこれを望まない。
指紋リーダーは、あなた以外の誰もあなたのログインを使用できないようにするために存在します。 2要素トークンは共有できます。指はできません。ただし、指紋リーダーにはハードウェアアクセスが必要ですが、ウェブサイトにはありません。したがって、指紋リーダーは、Webサイトに入力するだけのコードを出力するように設計されています。あなた（ブルームバーグ）は毎回同じコードを出力したくありません。何かと混ぜる必要があります.
現在時刻などのいくつかの独立して変化するデータを使用することもできますが（たとえば、Google AuthenticatorのようなTOTPシステムと同じです）、（Bloomberg）キーがホールの誰かによって生成されないようにする必要があります。有料ユーザーがその画面のその席に座っていることを確認します。そのため、指紋リーダーに応答するための一意のチャレンジコードを送信します。
ユーザーのみが認証されていることに注意してください。サーバーでも接続でもありません。したがって、このスキームでは、中間者攻撃がうまく機能します。理想的にはサーバーをTLSで認証できますが、TLS検証アーティファクトは認証スキームの一部ではないため、認証はその検証にまったく依存しません。
したがって、your保護が重要な場合、このメカニズムはあまり役に立ちません。 SMS、RSA SecurID、Google AuthenticatorなどのOTPベースの2段階認証システムに勝るものはありませんが、価格ははるかに高くなります。重要なのがyour保護である場合、現在Googleが作成した Yubico U2F キーよりも優れた方法はありませんが、そのサイトで使用できます。それを受け入れます（今を含む Github ！）。
通常、この種の方法は、「 あなたが見るものはあなたが署名したもの 」を達成するために使用されます。これは、ヨーロッパの銀行がしばしば採用する原則です。 men-in-the-browser 攻撃。
この手法自体は、オンラインマネートランザクションに使用するときにその利点を示します。例はこれをより明確にします。
攻撃者がブラウザを完全に制御でき、銀行がログインの認証とトランザクションの認証の両方に2要素認証を採用したとします。被害者は€500を銀行口座556611に送金したいと考えており、OTPジェネレーターでトランザクションを認証する準備ができています。ただし、攻撃者はブラウザを完全に制御でき、トランザクションを€50000に変更して、銀行口座447700に送金します。攻撃者がブラウザを変更したため、被害者にはこれは表示されません。元のトランザクションを示します。これで、被害者はOTP（およびおそらくこの攻撃には関係のない他の資格情報）に入ります。トランザクションは承認され、被害者は元のトランザクションを承認したのか、変更されたのかを知る方法がありません。ユーザーは自分が見ているものに署名しませんでした。
一見すると、OTPの生成にトランザクション情報を含めるソリューションでもあるかもしれません。ただし、攻撃者が間違ったトランザクション情報をサーバーに送信する可能性があるため、サーバー上で正当に計算されたOTPを信頼することはできません。
上記の問題を解決する唯一の方法は、被害者が送金先の金額と銀行口座番号を確認できるようにすることです。被害者のPCが（ブラウザを含めて）完全に侵害されていると想定しているため、この検証は帯域外で行う必要があります。ここで、「あなたが見るものはあなたが署名するもの」に到達します。上記の例では、被害者は見たものに署名しませんでした。これは金銭取引にとって大きな問題です。
したがって、ユーザーの利便性にあまり影響を与えずに、銀行の顧客が支払いの詳細を確認できる巧妙な方法が必要です。単純なアプローチは次のとおりです。
- 顧客に支払いの詳細（金額、口座など）を入力させます
- 金額/口座の詳細に基づいて（および チャレンジ にも基づいてOTPを計算します。これは、ヨーロッパの一部の銀行の標準OTP生成方法です）
- 顧客はPINコードを使用してOTPジェネレーターをアクティブ化します（あなたの場合：自分の指紋を使用）
- OTPジェネレーターで上記のすべての情報をお客様に入力してもらいます（これは、チャレンジ、金額、アカウントの詳細、および場合によってはその他の情報です）。
- ジェネレーターは応答を表示し、トランザクションは許可されます
ご覧のとおり、上記の方法はユーザーにとって非常に扱いにくいものです。OTPジェネレーター（通常はオフラインのデバイスであるか、最近ではスマートフォンである可能性があります）に多くの情報を入力する必要があります。このプロセスをはるかにユーザーフレンドリーにするために、この情報を次のような画像に含めることができます。
- QRコード
- この投稿の最後の画像に表示されているような「変化する」バーコード
- Cronto 画像
プロセスは簡単です。ユーザーは、銀行（またはスマートフォン）から受け取ったリーダーを使用して、上記のコードのいずれかを読み取ります。必要な情報（チャレンジ/金額/アカウント）を入力する代わりに、リーダーは画像からこの情報を読み取り、ユーザーに提示するだけで、ユーザーはこれを確認する必要があります。たとえば、読者は「500ユーロを送金しますか？」と尋ねます。リーダーで生成される応答は、この500ユーロに基づいています。攻撃者が€500を€50000に変更する可能性は完全にあることに注意してください。ただし、顧客が（できれば）読者がこのトランザクションを承認するかどうかを尋ねる場合は、決して[OK]を押さないでください。これは最高のWYSIWYSです。
回答
あなたの例では、指紋でリーダーを最初にアクティブにする必要があります。これは、PINでリーダーをアクティブ化する方法と比較して新しい方法ですが、WYSIWYSメソッドの残りの部分には影響しません。今、あなたの質問に実際に答えます。私はブルームバーグシステムの詳細を知りません。「画像」には、チャレンジ/レスポンスログインを高速化するためのチャレンジが含まれているだけです（ユーザーがリーダーにチャレンジを入力する必要はありません）。ただし、ほとんどの実装では、この種のフローはWYSIWYSを実現するために使用されます。ログインフォームの場合、これは通常、2要素認証と比較してセキュリティを追加しません（ユーザー名/チャレンジ以外に変更できる他の情報がないため）。ただし、ユーザーのログインとトランザクション署名で同じ認証フローを使用する方が簡単です。
付録：
この回答で述べた光学バーコード（静的バーコードでは必要なすべての情報を保持できないため、このバーコードは絶えず変化することに注意してください）。このバーコードを読み取るには、変化するバーコードを読み取るのに数秒かかる特別なリーダーが必要です。 
対比するために、一部のサイトがパスワードの再入力を求めることで、プロファイルの設定の変更にどのように重点を置いているかを検討してください。これは、認証Cookieトークンがコピーされ、アカウントへのアクセスに使用されるのを防ぐためです。ブラウザ自体が危険にさらされている場合、またはクライアントとサーバー間のトランザクション全体が明白である場合、被害を最小限に抑えるアクションは、暗号化されたチャネルの再確立ではなく、結びつけることです。確立された認証済みエンドポイントを使用する各トランザクションで、パスワードの使用、帯域外通信などを通じて、何らかのシークレットを提供する必要があるのはこのためです。 、それはその単一のトランザクションに関連付けられています。通常、これはすべてのアクションで実行されるわけではありません。アカウントの残高を確認することは、アカウントから現金を転送することほど簡単ではないためです。
指紋モジュールは、読み取り機自体が改ざんから安全である限り機能します。これを除けば、パスワードを入力するのと同じくらい透過的です。電話の指紋モジュールが行う唯一の良いことは、後ろにカメラを取り付けてスワイプパターンを見つけることにより、デバイスを盗聴するのを妨げることです。
端末には双方向機能があり、bloombergを優先して重く、端末と端末の間に1人のユーザーのみが存在することを保証するという観測に同意します。