公開データベースIDを不明瞭化/難読化することは、実際には「ベストプラクティス」ですか？
人々がインターネットのあちこちで講演するのを聞いたことがあります。Webアプリケーションで一般向けのデータベースIDを隠すことがベストプラクティスであるということです。私はそれらが主にフォームとURLで意味していると思いますが、私はこの件について一口以上のものを読んだことがありません。
[〜＃〜] edit [〜＃〜]：もちろん、これを聞いたので、この件に関するいくつかのリソースを見つけます：
- https://stackoverflow.com/questions/2374538/obscuring-database-ids
- https://stackoverflow.com/questions/1895685/should-i-obscure-primary-key-values
- http://joshua.schachter.org/2007/01/autoincrement.html
これらのリンクは私の好奇心の一部を満たしましたが、SOの投稿は多くの投票を持たず、必ずしもこのコンテキストのトピックを中心としているわけではないので、それをどうするかわかりません、そして3人目のリンクが偽物であると主張する人もいます。残りの投稿はそのままにしておきます。
あいまいさとセキュリティの違い、および2つがどのように連携するかについては理解していますが、なぜこれが必要になるのか想像できません。
これに真実はありますか、それは単なるパラノイアですか、それともまったくまったく偽物ですか？
私はそれを行う方法を考えることができますが、もちろんそれはアプリケーションコードに多くの複雑さを追加します。これはどのような状況で役に立ちますか？これがである人々が頻繁に行うことである場合、通常はどのように展開されますか？識別子をハッシュ化しますか？他に何か？余計なセキュリティを確保するために多くの作業が必要なようです。私は実際の解決策を探しているのではなく、人々が現実世界でこれをどのように/なぜ行うのかを知りたいだけです。
これは本当に「ベストプラクティス」と見なされているのでしょうか、それともほとんど価値のないマイクロ最適化にすぎませんか？
[〜＃〜]注[〜＃〜]：数人の人々が間違った考えを持っているかもしれないと思います：私はその難しいことを示唆していません-推測するIDはonlyセキュリティメカニズムであり、通常のアクセスチェックがあるはずです。それらが適切であり、レコードのIDまたはハッシュされたIDを知るだけではアクセスを許可するのに十分ではないと仮定しましょう。
それはそれほど重要ではないと私は思いますが、あなたが行う他の決定次第では、それがcould問題になるいくつかのシナリオがあります。
たとえば、順次生成される注文IDを公開し、カスタマーサポートに電話をかけてソーシャルエンジニアリング攻撃を受けた場合、「ねえ、私は新しいコンピューターに$ 2000を費やしただけで、他の人の注文を送ってくれました。 $ 15のケーブル、今なら$ 2000です」偽物であると結論を下すか、偽造者に新しいコンピュータを送る前に、多くの時間をかけて問題を精査することができます。
テーマには似ていますが、それほど洗練されていませんが、恥ずかしいバリエーションがあります。悪意のある人物が注文IDをインクリメントし、領収書への電子メールで送信されたリンクがあり、リンクをクリックした人が注文IDを表示する権限を持っていることを確認する追加の検証が行われていない場合、突然、意図せずに個人の顧客情報が公開されます。間違った人に。
このような場合、数値が非連続的であると、推測によって興味深い結果が得られる可能性が低くなるため、露出はわずかに軽減されます。一方、今では、カスタマーサポートのやり取りで注文IDを参照する便利な方法が必要です。これにより、担当者がB、PD、注文番号BPT2015DのT。
この難読化を "ベストプラクティス"と呼ぶのは簡単だと思いますが、特定のシナリオでは、検証または承認コードの別の弱点を悪用することの容易さを低下させる可能性があります。一方、あなたがブログ投稿＃1または＃2559を書いたことを誰かが知っているかどうかは問題ではありません。追加の知識があっても、IDが貴重な情報ではない場合、IDを難読化することがベストプラクティスであるという主張は、重要性が低くなります。
2番目の可能性のある引数があります。これは、データベース識別子が特定のデータベース実装（またはインスタンス）につながる可能性があり、会社が競合他社を買収または買収したときに、2つのレガシーシステムまたはCEOをマージする必要があることです。 DynoCoreBaseの担当者と飲みに行って、すべてのデータをDynoCoreBaseバージョン13hに移動し、すべての主キーをguidにすることを決定し、古いIDを新しいものに変換するための何らかのマッピングレイヤーを作成する必要があります。古いURLが壊れないようにするためのIDですが、これらのシナリオが重要かどうかは、一般的なベストプラクティスよりも、ビジネスの性質（およびそれらのIDに対する顧客の関与）に大きく依存します。
これは私の見解です：
「あいまいさによるセキュリティ」だけでは明らかに不十分ですが、あいまいさcan少しでもセキュリティを支援します。アプリケーションにこのようなものをデプロイするために必要な追加の労力に見合うだけの疑似セキュリティが必要かどうかを判断する必要があります。
これを実装するために私が考えることができるセキュリティ以外の別の理由があります：
プライバシー
URLのユーザーIDを扱っているとしましょう。 JoeのユーザーIDが100で、BobのユーザーIDが101である場合、Joeのアカウントが最初に作成されたことは明らかです。これはほとんどのアプリケーションでは問題にならないかもしれませんが、一部のアプリケーションでは問題になる場合があります。これはプライバシーの例ですstriclyあいまいなため、ユーザーIDを難読化する非常に高度なシステムがない限り、ID 3Js9kW3hTs7sa120のユーザーがID Q8Hs73kks0hEgのユーザーより長いアカウント。
私が参照した link から：
1つ目は、オブジェクトのURLを指定すると、そのオブジェクトの周りに作成されたオブジェクトのURLを把握できることです。これにより、データベース内のオブジェクトの数が、競合他社またはこの情報を必要としない可能性のある他の人々に公開されます（連盟がシリアル番号を見てドイツの戦車の生産レベルを推測することにより 有名に示されている のように）。
自動インクリメントIDを使用すると、データベース内のオブジェクトの数が公開され、最初に作成されたオブジェクトと新しいオブジェクトが公開されます。この情報は、ビジネスが新しい、またはうまくいっていないという事実を与える可能性があります。たとえば、本を注文し、注文IDが1であるとします。あなたの注文がシステムの最初の注文であったことは明らかかもしれません。たとえば、前に戻って別のものを注文し、注文IDが9であるとします。これにより、2つの注文の間の時間枠に7つの注文しか出されなかったという情報が提供されます。これは、競合他社にとって貴重な情報になる可能性があります。この場合、数値の自動インクリメントIDは、おそらく難読化したほうがよいでしょう。
私は主流に反対し、ランダムで長い識別子を使用することは私の意見ではかなりまともなセキュリティの形だと言います。
そのデータにアクセスできる人には、パスワードと同じくらい機密性が高いことを明確にする必要があります。そしてもちろん、それが実際に出て行くと、変更するのが難しくなるかもしれないという欠点があります。
ただし、通常のユーザー名とパスワードのペアに比べていくつかの利点があります。まず、ユーザーはそれを選択することはできません。そのため、本質的に推測することは不可能です。管理者がファーストネームをパスワードとして選択した場合、完全に安全なサイトを設計しても意味がありません。次に、各アイテムには異なる識別子があるため、1つのアイテムにアクセスしても、他のアイテムには役立ちません。
もちろん、セキュリティの層が多ければ多いほど良いです。ただし、この方法だけでも、いくつかの資格情報よりも安全です。
「あいまい」という言葉はここでは少し誤解を招く可能性があり、人々は「難読化」または「部分的に隠す」と考えるようになるかもしれません。
これらのデータベースレコードに機密データが含まれている場合は、内部で生成されたデータベースキーをパブリックURLの一部として含めないでください。
URL内の数字を操作して他のレコードにアクセスするのは簡単すぎます。
明らかにそれはデータの機密性に依存しますが、中程度のセキュリティでは、IDとチェックサム値を含めることが最低限必要です。
IDの前後にソルト（ランダムな文字のセットのコレクション）を追加し、値にMD5を実行して、チェックサムを生成します。
ID値を読み取るすべてのページで、チェックサム値を生成し、渡されたものと比較し、一致しない場合は要求を拒否します。
潜在的なハッカーが十分な有効な組み合わせを取得できれば、ブルートフォースでソルトの値を計算できる可能性があるため、ユーザーIDのチェックなどのセキュリティの別の層を追加すると、役立つでしょう。
これには、使いやすさとセキュリティという2つの側面があります。
セキュリティの観点から、IDを不明瞭にしても意味がありません。重要なのは、IDが非公開リソースの唯一の「キー」であってはならないということです。つまり、選択したユーザーに特定のページへのアクセスを許可したい場合、URLでページのIDを要求するだけでは十分ではなく、ユーザー名/パスワードのログインや公開/秘密鍵認証などの実際のセキュリティメカニズムを実装する必要があります。また、適切な承認（つまり、システムは、ユーザーXがリソースYへのアクセスを許可されているかどうかをケースごとに判断し、それに応じて行動できる必要があります）。
使いやすさの点では、一般的なアドバイスは人工キーを非表示にしておくことです。ユーザーには意味がありません。明らかな方法でそれらを明らかにすることにより、追加の依存関係が導入されます。ソフトウェアの領域-人々意志書き留め、電子メール、ファックス、印刷、ブックマークなど、それらのIDです。IDを変更した場合、迷惑なサポートチケットに参加することになります。
No、あなた絶対的に、積極的に内部IDを知っているだけで任意のリソースへのアクセスを許可したくない。これはインターネットであり、悪意のある、犯罪的、または明白な幼稚な存在であり、実際に存在する実際に存在する、遅かれ早かれ存在するあなたのサイトに来るでしょう。あなたが提供することができるすべてが完全にすべての人に公開されていない限り（そしてあなたが1人の顧客を持っているなら、それは事実ではないことが保証されます）、あなたはでなければなりませんアクセスを実際に許可されている人にアクセスを制限します。
通常の解決策は、暗号化されたセッションに格納されているある種の認証トークンを使用し、実際に送信する前に、認証されたユーザーに何かが見えるはずかどうかを確認することです。これは、JDKに同梱されているものなど、実際のセキュリティマネージャー、または同じ役割を果たしている限り、同じ役割を果たしている他のコンポーネントである場合があります。 （内部IDを既に認証されている人に公開するかどうかも、さまざまな長所と短所がある興味深い質問ですが、セキュリティの重要性は低くなります。）
これを行うことの価値は、ビジネスを意味する誰かに実際に攻撃されるまで計算するのは困難です。次に、それは通常、廃業と、もう1つの失敗したスクリプトキディをすくめることとの違いです。