5

わかりました、それが何であるか、およびWebアプリケーションでそれを使用する方法について2時間グーグルで調べました! しかし、成功しません。

リンクのほとんどは、コードのスキャンまたは GoogleAuthenticar モバイル アプリでのキーの入力について説明しており、30 秒ごとに変更された確認コードが返されます。

いくつかのこと :

  1. Web アプリケーションには独自のログインがあります。つまり、ユーザーは Google を使用して Web アプリケーションにログインしません。
  2. 攻撃者がユーザーのパスワードを取得した場合、次のステップとして QR コードを確認し、モバイルの GoogleAuthenticator アプリで直接スキャンできます (私の目に見える限り)。ユーザーのモバイルのみにどのように関連付けられていますか?
  3. さまざまなサイトで、ユーザーとサーバー間の共有シークレットについて言及されています。つまり、サインアップ時にユーザーに共有シークレットを提供します。ユーザーはそれをモバイル GoogleAuthenticator アプリで使用し、QR コードの読み取り中に使用できます。
  4. 上記の場合、ユーザーがシークレットを紛失または忘れた場合、どうすればよいですか? シークレットを忘れて、シークレットをユーザーの電子メールに再度送信しますか?

Google以外のAndroidアプリケーションである場合、どのように実装できるかについて混乱しています!

私が得たのは、GoogleAuthenticator のソースコードの助けを借りて独自の実装を求める概念にすぎないということだけです。私を修正してください？

私が考える解決策は、ここで言及されているこの男と同じように、独自のモバイルアプリを作成する必要があるということですが、モバイルアプリとサーバーの間の秘密がそれぞれで一意になる方法はまだわかりません特定のユーザーのみを識別するようにそのアプリをインストールするか、独自のアプリを作成して、webapp に Google ログインせずに GoogleAuthenticator モバイルアプリを使用する方法はありますか?

4

1 に答える 1

7

Google Authenticator (モバイル アプリケーション) は、時間ベースのワンタイム パスワード アルゴリズムを実装しています。あなたが尋ねているシナリオでは、2 要素認証は次のように機能します。

  • ユーザーは、サーバー アプリケーションによって検証されるワンタイム パスワードを生成します。
  • サーバーは、TOTP アルゴリズムで詳述されている手順を使用してパスワードを検証します。

ユーザーデバイスでのパスワード生成は、ユーザーアカウント用に「構成」された TOTP を実装する任意のアプリケーションで実行できます。 ここで構成されているということは、質問で自分自身に言及しているように、秘密をサーバーと共有したことを意味します。

今、あなたの質問に答えようとしています：

  1. アプリケーションが独自のユーザー認証情報セットまたは Google の認証情報を使用しているという事実は、2 要素認証に直接影響しません。これらの資格情報が何であれ、ユーザーが誰であるかを知る必要があるため、TOTP パスワードの検証に進むためには、ユーザー (ユーザー名) を識別する方法が必要です。別の言い方をすると、TOTP を使用し、Google Authenticator アプリケーションを使用しても、サイトで Google 資格情報を使用する必要があるわけではありません。

  2. 正しく理解しているかどうかわかりません。各アカウントの Google Authenticator アプリの構成は1 回だけ実行されます。攻撃者があなたの後ろに座って、あなたが Google Authenticator を構成しているときに画面の写真を撮った場合、攻撃者は、あなたが使用しているのと同じバーコードを読み取る資格情報を使用して、独自のアプリケーションを構成できます。それにもかかわらず、彼はログインを実行してワンタイム TOTP パスワードを提供するために、(適切な) 資格情報も必要とします。とにかく、これはユーザーが自分の資格情報を不適切に処理する方法に起因するセキュリティ上の問題であり、使用するテクノロジに関係なく、同様の問題が発生する可能性があります. 不完全な比喩を作ることは、「ユーザーがピンカードをテーブルに置いたままにしておくと、攻撃者はそれを見て写真を盗みます。".確かに、彼はできました。

  3. はい、バーコードを読み取ることは、アプリケーションを構成し、クライアント アプリケーションとサーバー間でシークレットを共有する方法の 1 つです。キーをアプリケーションに手動で入力するなど、他の手段を使用することもできますが、QR コードを使用する方が迅速で、エラーが発生しにくくなります。この質問への回答を依頼されたときに読んでいたブログ投稿で説明したように、Google の Web API を使用できるため、QR コードを生成する必要さえありません。実際、そこで説明されている Java サーバー側ライブラリは Google Web API を使用し、ユーザーがチェックアウトして独自の QR を読み取るための URL を返します。独自の QR ロジックを構築したい場合は続けてください。ただし、Google の API を使用する資格がある場合は、そうしなければならないという説得力のある理由はありません (とにかく確認する必要があります)。

  4. 秘密が失われた場合、それが独自のアプリケーションである場合、それは独自のポリシーに依存します。まず、ユーザーからの通知を受けたらすぐに古いシークレットを無効にする必要があります。次に、TOTP シークレットの作成時にユーザーに与えた可能性のあるスクラッチ コードを使用して、ユーザー自身の身元を確認できます。彼がスクラッチ コードも紛失した場合は、アカウントのバックアップ情報 (バックアップの電話番号、セキュリティの質問など) を使用するなど、別の方法で本人確認を行うことをお勧めします。基準に従ってユーザー ID が確認されたら、新しい資格情報を発行し、最初から開始します。つまり、新しい QR や新しい秘密鍵を使用して Google Authenticator を再構成します。

要約すると、はい、必要に応じて Google Authenticator アプリケーションをクライアント フロントエンドとして使用できます。別のアプリケーションを作成する必要はありません。考慮すべき唯一のことは、Google Authenticator がその TOTP 実装で 30 秒のウィンドウを使用することです: TOTP パスワードを検証するサーバー側のロジックは、同じウィンドウ サイズを使用する必要があります (つまり、IIRC、によって提案された標準値) TOTP RFC )。

于 2014-04-10T15:17:11.263 に答える