ユニークなアプリケーションキー

Question

私はアプリケーション開発者（A.K.A.私の友人）が自分のデータベースを照会できるようにするWebサービスを作成しています。セキュリティの制約として、私は各ユーザーを追跡できるようにしたいと考えています。私はFaceBookやGoogleマップのようなユニークなアプリIDを作成しています。

開発者はユーザー名と電子メールアドレスを送信し、生成ボタンをクリックすると固有のキーが生成されます。つまり、ユーザー/電子メールがすでに存在する場合はデータベースを最初にチェックし、既にキーが生成されているかどうかを確認する必要があります（擬似ランダム生成保護）。

Webサービスを使用するには、ユーザーが何か入力する必要があります。

webservice.Authenticate（「ここではアプリのキーを」）;

を認証します。前もって感謝します。

Answer 1

私が言うところでは、Guid.NewGuid()で十分であるはずです。

Answer 2

一般的な認証は、アイデンティティ（名前）とシークレット（パスワード）から構成されます。秘密だけで構成された認証方式を設計しています。パスワード（guidの形式）。このアプローチの問題点（すなわち、パスワードとアイデンティティを分離しない）は、パスワードがであるため、ユーザーがパスワードを変更してもパスワードを変更できないことです。

Maps APIのキーとそれに類するキーは何か他のもの：サービスプロバイダが署名したクレームです。たとえば、アプリがMaps APIを呼び出す場所の登録済みドメインです。 Generateキーは送信したドメインを受け入れ、そのドメイン名にサービスの秘密鍵を付けて署名し、publis署名を提示します。 APIにアクセスするには、登録し、利用規約に同意したことを示す署名（APIキー）を提示する必要があります。検証のもう1つの部分（アプリが実行されているドメイン、つまり「主張」）はJavaScriptによって自動的に検出されます。

私は決してMaps APIの専門家ではありませんが、私はいくつかの部分を持っているかもしれませんが、これは一般的に物事がどのように実装されているかです。私は多くの価値を提供していないため、難読化されたアプリケーションIDとしてguidを使用することを推奨します。漏れguidは誰でも使用でき、guidを使用してクレームを検証することはできません。あなたは何を保護しようとしているのか、あるいはOpenIdや何かのような確立された体系について考えてみてください。

Answer 3

塩、ユーザー名、電子メールアドレスから文字列を作成します。その後、その文字列からハッシュ（MD5またはSHA1）を作成します。塩は単にユーザーIDにすることも、ユーザーに知られていない限り他のものにすることもできます。

GUIDは問題ありませんが、この状況ではおそらく過剰です。あなたは何十億というユーザーを抱えていますか？あなたはおそらく1から1,000,000の間の乱数を得ることができます。次にxが3〜6の間で失敗したx回の試行後にログインを無効にしてください。

Answer 4

GUIDソリューションを使用する場合は、データベースを照会することで常に一意であることを確認できます。一意でない場合は、新しいものを生成してください。

Answer 5

アプリケーションのサイズとユーザー数に応じて、Guidを処理する方法がわからない限り、Guidが最適ではない場合があります。ほとんどの場合、これらは文字列として使用されていますが、ストレージ要件が増え、比較ルーチンが遅くなります。マッチするguidの文字列比較では、すべて36文字をスキャンする必要があります。ちょうど16進形式で格納されているデータのためのウェイ・オーバーキル。その良いGUIDを整数の配列として保存する...同時に検索を減らしながら、ストレージ要件を削減します。

数千のレコードしかない場合は、文字列としてのguidはおそらくそれほど重要ではないでしょう。しかし、規模のプログラミングとその規模が大きい場合は、適切な調整を行うことで、後で実行する際の苦労が軽減されます。

テーブルでジョインを行っている場合は、GUIDではなく、結合を行うために整数のアイデンティティを使用します（前述の理由と同じです）。