5

MongoDB_idフィールドは、秘密のデータとして機能するのに十分にランダム/推測不可能ですか?

例:サーバー側のOAuthを構築している場合、ユーザーのOAuthトークンとして_idを使用できますか?データベースに提供されるクリーンさとインデックス作成性のために、これを実行したいと思います(たとえば、 "tokens._id" => oauth_token)。

MongoDB _idオブジェクトの構造を調べると、それらはまともなランダムであるように見えますが、悪意のあるエンティティがブルートフォース攻撃を推測することについては、長引く懸念があります。

4

2 に答える 2

12

要するに、違います。モンゴObjectIdsは簡単に推測できます。特に、高負荷では、タイムスタンプ、マシン、およびプロセスIDが変更されないため、これらは連続した番号であることがよくあります。Objectidの構造を見ると、次のように構成されています。

a 4-byte timestamp, 
a 3-byte machine identifier, 
a 2-byte process id, and 
a 3-byte counter, starting with a random value.

したがって、ランダム性はほとんどありません。たとえば、コントローラーのアクションによってドメインオブジェクトが書き込まれ、ログエントリがすばやく連続して書き込まれる場合など、データベースに連続したIDが表示されることがよくあります。

タイムスタンプを推測でき、マシンIDを判別できる場合(巨大なクラスターがない限り)、残りは5バイトだけです。生成されたIDの数を調べることで、おそらくそれを50プロセス程度に減らすことができるので、有効なエントロピーは28ビット範囲のどこかにあります。これはまだ推測するのが難しいですが、アクセストークンにはリスクが高すぎます。

代わりに、暗号的に強力な疑似乱数ジェネレーターを使用して、そこからトークンを作成します。たとえば、.NETでは、はRNGCryptoServiceProvider任意の長さのランダムデータを作成できます。

補足として、2つの理由から、OAuthTokenの周りに追加の暗号ラッパーを用意することをお勧めします。

a)無効なトークンをすばやく特定できるようにする必要があります。有効な暗号化シェルには、無効なトークン(失効または期限切れの許可)が含まれている可能性がありますが、毎回ブルートフォース攻撃でデータベースを攻撃する必要はありません。また、クライアント

b)クライアントはトークンを何度も要求できます。これは必須ではありませんが、私が知っているほとんどすべてのシステムは、毎回異なるトークンを返します(自己検証であるかどうかは関係ありません)。通常、これはトークン自体の有効期間が限られているためです。これは、OAuth付与と同じ有効期間ではありません。

データベースに実際に保存したいのは、付与、つまり、あるユーザーからあるクライアントに与えられた許可です。この付与が削除されると、すべてのトークンが無効になります。アプリケーションの許可を効果的に削除するには、ユーザーがすべてのトークンを削除する必要があるため、毎回新しいトークンを挿入するのは非常に便利ではありません。

于 2013-03-15T15:25:54.450 に答える
1

非常に難しいですが、それは可能だと思います。実際には、他のほとんどのOAuthトークンを推測するほうが幸運かもしれません。

それが非常に難しくなる可能性がある方法の1つの例は、PIDが含まれていることです。PHPなどの言語を使用している場合、PIDは生成されたすべてのPHPプロセスに変更されます。つまり、それぞれ_idが独自の移動PIDを持ち、完全かつ完全にランダムになる可能性があります。もちろん、PHPを実行するモードによって異なります。fcgiモードの場合、PIDは一定である可能性があります。

mahcineidも別のものです。ほとんどのWebサイトには、データベース用のサーバーの自動スケーリングクラスターがあるため、負荷が高い場合など、実際に予測できる唯一の変数は、多くの場合、タイムスタンプです。それでも、ミリ秒レベルであるため、推測するのは非常に簡単ではありません。 ; 合理的な方法で時間を計算するために、サイトがアルゴリズムを構築するために必要なトラフィックの量を正確に知る必要があります。もちろん、そもそもその情報を飾る唯一の方法は、実際にその_idを取得して22をキャッチすることです。

ただし、それを考慮すると、ブルートフォース攻撃について考えることができる唯一の方法は、_idこれまでに存在する可能性のあるすべてのObjectIdを反復するのに十分な計算能力を取得することです(ObjectIdの変数のランダム性を考慮すると、ここでは数兆/無限になる可能性があります)。データベース内の各アプリID(常にOAuthトークンとアプリIDを要求する必要があります)に、ここでもさらに別のレベルの謎を提供します。

ですから、私の意見では、そうです、誰かが力を抜くことができますが、それは本当に価値のないものをクラックするのに多くの計算能力とおそらく数年かかるでしょう。

于 2013-03-15T15:22:32.550 に答える