公開用のデータベースIDを不明瞭化/難読化することは、本当に「ベストプラクティス」ですか？

私は人々がインターネット上であちこちで講義するのを聞いたことがあります。それはウェブアプリケーションで人前向きのデータベースIDを隠すのがベストプラクティスだということです。私はそれらが主にフォームとURLで意味すると思いますが、私は主題について一口以上を読んだことがありません。

編集：もちろん、今私はこれを尋ねたので、私は主題に関するいくつかのリソースを見つけます：

• /programming/2374538/obscuring-database-ids
• /programming/1895685/should-i-obscure-primary-key-values
• http://joshua.schachter.org/2007/01/autoincrement.html

これらのリンクは私の好奇心の一部を満たしましたが、SOの投稿には多くの票がなく、必ずしもこのコンテキストのトピックに集中しているわけではないので、何をすべきかわかりません。リンクは偽です。残りの投稿はそのままにしておきます。

あいまいさとセキュリティの違い、およびこの2つがどのように連携するかを理解していますが、なぜこれが必要なのか想像できません。

これには真実がありますか、それは単なる妄想ですか、それとも完全に偽物ですか？

私はそれを行う方法を考えることができますが、もちろん、それはアプリケーションコードに多くの複雑さを追加します。これはどのような状況で役立ちますか？これが人々が頻繁に行うことである場合、通常はどのように展開されますか？識別子をハッシュしますか？他に何か？余分なセキュリティを確保するための多くの作業のようです。私は本当の解決策を探しているのではなく、人々が現実の世界でこれをどうやって/なぜ行うのかを知りたいだけです。

これは本当に「ベストプラクティス」と見なされますか、それとも単に価値の低い微最適化のみですか？

注：少数の人々は間違った考えを持っているかもしれないと思います：推測が困難なIDが唯一のセキュリティメカニズムであることを示唆していません。明らかに通常のアクセスチェックがあるでしょう。それらが適切に配置されており、レコードのIDまたはハッシュされたIDを知るだけでは、アクセスを許可するには不十分であると仮定しましょう。

私はそれはそれほど重要ではないと思いますが、あなたが下す他の決定に応じてそれが重要になるいくつかのシナリオがあります。

たとえば、順番に生成される注文IDを公開する場合、カスタマーサポートに電話して「ねえ、新しいコンピューターで2000ドルを使っただけで、他の男の注文を送ってくれた」というソーシャルエンジニアリング攻撃を受けた場合15ドルのケーブル、2000ドルになりました」と偽って結論を出すか、フェイカーに新しいコンピューターを送る前に、多くの時間をかけて問題を吟味することができます。

テーマには似たような洗練されていないが、恥ずかしいバリエーションがあります。悪者が注文IDを増やし、領収書へのリンクをメールで送信し、リンクをクリックした人に注文IDを表示する権限があることを確認する追加の検証が行われない場合、突然、意図せずに個人の顧客情報が公開されます間違った人に。

そのような場合、数値が連続していない場合、推測によって興味深い結果が得られる可能性が低いため、露出はわずかに軽減されます。一方、今では、顧客サポートのやり取りで注文IDを参照する便利な方法が必要です。これにより、担当者がB、PD、注文番号BPT2015DのT。

この難読化を「ベストプラクティス」と呼ぶのは無理があると思いますが、特定のシナリオでは、検証コードまたは認証コードの別の弱点を悪用しやすくなる可能性があります。一方、ブログ投稿＃1か＃2559を書いたことを誰かが知っているかどうかは実際には関係ありません。IDが有益な情報ではなく、追加の知識がある場合でも、IDを難読化するのがベストプラクティスであるという議論の重要性は低くなります。

2番目の潜在的な議論があります。データベース識別子が特定のデータベース実装（またはインスタンス）に結びつく可能性があり、会社が買収または競合他社を選択したときに、2つのレガシーシステムまたはCEOをマージする必要がある場合ですDynoCoreBaseの担当者と一緒に飲みに行くと、すべてのデータをDynoCoreBaseバージョン13hに移動し、すべての主キーをGUIDにしたいと決め、古いIDを新しいIDに変換するために何らかのマッピングレイヤーを作成する必要がある古いURLが壊れないようにするためのIDですが、これらのシナリオがあなたにとって重要かどうかは、一般的なベストプラクティスよりもビジネスの性質（およびそれらのIDに対する顧客の関与）に大きく依存します。

これは私の考えです：

「あいまいさによるセキュリティ」は明らかに十分ではありませんが、あいまいさは、たとえわずかであってもセキュリティを支援することができます。ちょっとした擬似セキュリティが、アプリケーションにこのようなものをデプロイするのに余分な労力をかけるだけの価値があるかどうかを判断する必要があります。

これを実装するために考えられるセキュリティ以外の別の理由があります：

プライバシー

URLのユーザーIDを扱っているとしましょう。JoeのユーザーIDがで100、BobのユーザーIDがの場合101、おそらくJoeのアカウントが最初に作成されたことは明らかです。これはほとんどのアプリケーションでは重要ではありませんが、一部のアプリケーションでは重要になる場合があります。これは、あいまいさによる厳密なプライバシーの例です。したがって、ユーザーIDを難読化する非常に洗練されたシステムがない限り、IDを3Js9kW3hTs7sa120持つユーザーがidを持つユーザーよりも長いアカウントを持っているかどうかを簡単に解消して把握できる可能性がありますQ8Hs73kks0hEg。

私が参照したリンクから：

1つは、特定のオブジェクトのURLを指定すると、そのオブジェクトの周囲に作成されたオブジェクトのURLを把握できることです。これにより、データベース内のオブジェクトの数が競合他社や、この情報を必要としない他の人に公開されます（連盟がシリアル番号を見ることでドイツの戦車の生産レベルを推測することで有名です）。

自動インクリメントIDを使用すると、データベース内のオブジェクトの数が公開され、最初に作成されたオブジェクトと新しいオブジェクトが公開されます。この情報は、ビジネスが新しいか、うまくいかないという事実を明かすことができます。たとえば、書籍を注文し、注文IDがであるとします1。注文がシステムの最初の注文であり、不安を感じる可能性があることは明らかです。戻って別の注文を行い、注文IDがであるとします9。これにより、2つの注文間の時間枠に7件の注文しかなかったという情報が得られます。これは競合他社にとって貴重な情報かもしれません。この場合、数値の自動インクリメントIDはおそらく難読化された方が良いでしょう。

ここで「Obscure」という言葉は、おそらく少し誤解を招く可能性があり、人々を「難読化」または「部分的に隠す」と考えるようになるかもしれません。

これらのデータベースレコードに機密データが含まれている場合、内部で生成されたデータベースキーをパブリックURLの一部として決して含めないことをお勧めします。

URLの数字を操作したり、他のレコードにアクセスしたりするのは簡単すぎます。

私は主流に反対し、ランダムで長い識別子を使用することはかなり適切な形式のセキュリティであるとあなたに言います。

そのデータにアクセスできる人には、パスワードと同じくらい機密性があることを明確にする必要があります。そしてもちろん、それが荒れ狂う場合、変更するのが難しいかもしれないという欠点があります。

ただし、通常のユーザー名とパスワードのペアに比べていくつかの利点があります。まず、ユーザーには選択肢がありません。したがって、本質的に推測することは不可能です。管理者がパスワードとして名を選択した場合、完全に安全なサイトを設計しても意味がありません。第二に、各アイテムには異なる識別子があるため、あるアイテムにアクセスしても、他のアイテムには役立ちません。

もちろん、セキュリティの層が多ければ多いほど良いです。ただし、この方法だけでも、いくつかの資格情報よりも安全です。

これには、ユーザビリティとセキュリティの2つの側面があります。

セキュリティに関しては、IDを隠すことはかなり無意味です。重要なのは、IDが非公開リソースの唯一の「キー」であってはならないことです。つまり、選択したユーザーに特定のページへのアクセスを許可する場合、URLでページのIDを要求するだけでは不十分であり、ユーザー名/パスワードログインまたは公開/秘密キー認証などの実際のセキュリティメカニズムを実装する必要があります。適切な許可（つまり、システムは、ユーザーXがリソースYにアクセスできるかどうかをケースごとに判断し、それに応じて行動できる必要があります）。

使いやすさに関しては、一般的なアドバイスは人工キーを非表示にしておくことです：ユーザーにとって意味がないため、明らかな方法でそれらを明らかにすることで、余分な依存関係を導入します。ソフトウェアの領域-人々はそれらのIDを書き留め、電子メール、FAX、印刷、ブックマークなどし、それらを変更した場合、あなたはいくつかの迷惑なサポートチケットを求めています。

いいえ、あなたは絶対に、内部IDを知っているだけで任意のリソースへのアクセスを許可したくありません。これはインターネットであり、悪意のある、犯罪者の、または単純な子供のような存在が存在すると想像し、実際に存在し、遅かれ早かれあなたのサイトに来るでしょう。提供できるすべてのものがすべての人に完全に公開されていない限り（そして、顧客が1人でもいる場合はそうではないことが保証されます）、実際にそれを所有する権限を与えられた人にアクセスを制限する必要があります。

通常の解決策は、暗号化されたセッションに保存されている何らかの種類の認証トークンを使用し、実際に送信する前に、認証されたユーザーに何かが見えるはずかどうかを確認することです。これは、JDKに同梱されているものなど、実際のセキュリティマネージャー、または一貫してそうである限り、同じ役割を果たす他のコンポーネントです。（すでに認証されているかどうかに関係なく内部IDを公開するかどうかは、さまざまな長所と短所を伴う興味深い質問ですが、セキュリティにはそれほど重要ではありません。）

これを行うことの価値は、ビジネスを意味する誰かに実際に攻撃されるまで計算が困難です。それは通常、廃業することと、もう1つの失敗したスクリプトキディを肩代わりすることとの違いです。

明らかに、データの機密性に依存しますが、中程度のセキュリティの場合、IDとチェックサム値を含めることが最低限必要です。

IDの前後にソルト（つまり、ランダムな文字の集合）を追加し、値に対してMD5を実行して、チェックサムを生成します。

ID値を読み取るすべてのページで、チェックサム値を生成し、渡された値と比較する必要があります。一致しない場合、要求を拒否します。

潜在的なハッカーが十分な有効な組み合わせを取得できる場合、ブルートフォースによってソルト値を計算できる可能性があります。したがって、ユーザーIDの確認など、別のセキュリティレイヤーを追加できる場合にも役立ちます。