0

idtoken は、バックエンド サーバーとのフォローアップ通信でそれ自体の (おそらくソルト化された) SHA2 ハッシュに置き換える以外にセキュリティを提供しないと仮定するのは正しいですか?

想定されるフローは次のようになります。

  1. Android アプリは Google から idtoken を取得します
  2. アプリは idtoken を自己ホスト型バックエンド サーバーに送信し、そこで gitkitclient.VerifyGitkitToken を使用してバックエンドによって検証されます。
  3. バックエンドは、トークンの SHA2 ハッシュを有効期限と関連付けられたユーザー ID と共に作成し、将来の参照用にルックアップ テーブルに保存します。
  4. Android アプリは、idtoken の同じ SHA2 ハッシュを作成し、その後の通信で idtoken を使用する代わりに、バックエンドとの今後の通信でヘッダーにそれを渡します。

これにより、システムのセキュリティが何らかの形で低下しますか?

https インスペクションを備えた透過プロキシ (およびデバイスに、つまり企業環境に合法的にインストールされた証明書) がトラフィックを盗聴する場合、idtoken またはその SHA2 ハッシュが取得されても、その透過プロキシはidtoken の存続期間全体にわたって、Android アプリに代わって (おそらくルージュな方法で) 行動できるでしょうか?

私の問題は、サーバーとのフォローアップ通信ごとに gitkitclient.VerifyGitkitToken を呼び出すのはコストがかかりすぎて、idtoken の有効性が確認されたら必要ないことです。

また、今後の参照のためにidtokenをサーバーに保存したくありません。代わりに、idtokenのハッシュを保持することを好みます。idtoken の SHA224 ハッシュは十分であり、衝突が発生しないと想定しても安全ですか?

4

1 に答える 1

1

これには、認証 Cookie に何を含めるか、およびさまざまなアプローチの長所と短所について、長い議論が必要です。すべての人に適したソリューションはありません。アプリ/サイトのセキュリティ、パフォーマンス、スケーラビリティの要件に応じて、ソリューションを慎重に選択する必要があります。そのため、アプリ、要件、および脅威に関する詳細を理解することなく、提案されたソリューションについてコメントすることはできません。

一般に、認証 Cookie/トークンには次の基本的な要件があります。

  • 偽造可能であってはなりません (サーバーによって署名されています)
  • 検証が容易であること
  • 署名の秘密が盗まれたとしても、ハッカーはすべてのユーザーのトークンを作成できるべきではありません (たとえば、アカウントごとのノンスを持つことで達成できます)。
  • サーバーから取り消し可能であること (サーバー側の状態を維持することで実現)
  • 必要に応じて発行されたクライアントに関連付けられているため、クライアントから盗まれた場合は役に立たなくなります

もっと多くの望ましいプロパティがあると確信しています。GITKit は、1 回限りの認証用に id_token を発行します。開発者は、独自の Cookie/トークンを使用して、アプリ/ブラウザーのセッションを維持し続ける必要があります。多くの開発者が私たちに支援を求めていることは承知しており、ホーム サーバーで引き続き使用できる、長期間有効な OAuth 更新トークン (および短期間のアクセス トークン) をアプリに与えるソリューションに取り組んでいます。

于 2015-08-19T07:33:03.667 に答える