ブラウザに送信されるときにデータベースの主キーを暗号化する
ODataベースのアプリケーション（ADO.NET Data Services）、またはそうでなければPrimaryKey、またはForeignKeyをクライアントに公開するものを扱う場合...
ブラウザに到着したときにデータベースキーを暗号化することの利点について誰かに説明してもらえますか？
このキーをどのように暗号化しますか？検証にはどのような方法を使用しますか？
理想的には、この応答は、PMまたはこの慣行の利点/欠点についての幹部を売るような方法で表現されます。
詳細
Webプログラミングに慣れていない場合、私が話しているのは、クライアント（Webブラウザー、ファットクライアントなど）に送信され、HTTPSトンネルのリモートエンドで復号化される、しばしば隠された主キーです。議論は、クライアントに送信されるとき、プライマリキー（またはそのことについてはfk）を暗号化して難読化する方がより安全であるということです。
更新
正式な調査自体は見つけられませんでしたが、マルチテナントサイト、またはターゲット行のサーバー側の検証が不十分な場合に適用される概念実証Webサイトを作成しました。これはセキュリティの問題だと思いますが、このITセキュリティフォーラムにとって、プログラムの性質上、あまりにも多すぎるかもしれません...
コメントでのAviDの発言に同意します。
元の質問では、アプリケーションによって公開されるキー値を暗号化することにメリットはないと思います。私には、無名のセキュリティの奇妙な（そしてパフォーマンスの観点から見ると高価な）形式のように聞こえます。
非機密データのセキュリティと整合性は、強固なアプリケーションロジックによって提供される必要があります。つまり、現在のユーザーは、変更しようとしているデータを変更する権限を持っていますか？または、現在のユーザーはこのクラスに生徒を追加する権限を持っていますか？クラスはまだ登録のために開いていますか？
鍵を暗号化してもこれらの問題は解決しませんが、実際には、有効な暗号化されたパラメーターを持つリンクが、アクセスできないはずの誰かに電子メールで送信された場合など、追加の問題を引き起こす可能性があります。
他の例、電子メールで送信されたパスワードのリセットでは、暗号化されたキーがGUIDよりも重要な利点があり、パフォーマンスの影響で相殺されない）暗号化および復号化操作。
もちろん私の2セントだけですが、セキュリティ上の利点があったとしても、あまり多くは見えません。根本的なセキュリティの問題のすべてではなくてもほとんどが残り、関係なく別の方法で解決する必要があるため、それは実際の利点がない追加コストにすぎないと思います。
これが役に立てば幸い
-Xander
これがシナリオです。
フレッドは、バーニーのMyFaceItアカウントに侵入したいと考えています。彼は自分のアカウントのパスワードのリセットをリクエストし、リンクが記載されたメールを受け取ります。 https://MyFaceIt.com?reset=Fred&resetid=1234
次に、Barneyのアカウントのパスワードのリセットを要求します。メールは表示されませんが、resetidが1235、1236、またはその周辺にあると推測できます。
この状況では、resetidに順次生成されるキーではなくGUIDを使用できます。ただし、GUID（サイズ、インデックスの分布...）には欠点があるため、通常のシーケンシャルIDと値をハッシュ/暗号化します。これにより、リンクは https://MyFaceIt.com?reset=Fred&resetid=6FFB262274EC4B50A6320CFF15763C24 次のようになります https://MyFaceIt.com？ reset = F6E6B9B65D7B4ED48F1B68＆resetid = 6FFB262274EC4B50A6320CFF15
これにより、フレッドがバーニーのアカウントのリセットリンクを推測するのが非常に難しくなります。