（sha）ハッシュを使用したIPアドレスの匿名化。レインボーテーブル攻撃を回避する方法
GDPRでは、IPアドレスは個人データです。 IPを特定のユーザーまで追跡する必要はありませんが、ダウンロードをIPごとに1つに制限したいと思います。*プレーンIPを保存したくありません。
私の最初の解決策は、IPをハッシュすることです。ハッシュを保存できます：
12ca17b49af2289436f303e0166030a21e525d266e209267433801a8fd4071a0
問題は、4 294 967 296の可能なIPアドレスすべてをハッシュするのが簡単で、誰かが127.0.0.1は保存されたIPです。
ソルトを追加しても同じ問題が発生します。このソルトを使用してすべてのIPを再計算すると、同じ問題に到達できます。
これに対する解決策はありますか？
*ここでの使用例は単純化されています。これが必要な理由についてコメントしないでください。;）
純粋なセキュリティの観点から、システムに3つの可能な改善が見られます。
bcryptのような低速ハッシュを使用します。これは、SHA-1よりもサーバー規模で低速です。アプリケーションは影響を受けませんが、意欲的な攻撃者が1秒もかからずにすべての可能なIPをブルートフォース攻撃するのに数週間かかります。
ソルトを定期的に変更します。攻撃者はソルトごとにレインボーテーブルを生成する必要があります。ただし、テーブルを定期的にフラッシュしないとできない場合があります。たとえば、現在の日付で十分です。
saltの一部としてファイルIDを使用します。ユーザーが異なるファイルをダウンロードしている場合は、saltをファイルIDに依存させることができるため、データベースのデータベースでいくつかの異なるsaltが使用されます。同時。
攻撃者は、ダウンロード可能なファイルごとに1回、レインボーテーブルを毎日作成する必要があります。 各Rainbowテーブルは、適切なセットアップをしても、数週間かかります。
それでも（IPv4アドレスの数が非常に少ないため）不可能にはほど遠いですが、これは明らかに、以前の1秒の数秒からの大幅な改善です。
他の個人を特定できる情報と一緒にIPアドレスを保存しない限り、それらはGDPRルールの下で処理される必要はありません。これらは、ユーザーの名前、電子メールアドレス、またはその他のそのようなデータで強化された場合にのみ機密になります。リクエストを制限するシステムが、ログインやユーザーデータを処理するシステムとは別であることを確認してください。問題はありません。この場合、実際に格納しているのは、離散セットからのコンテキストのない数値だけです。
GDPRでは、そのようなデータの合理的な保護が必要ですが、これらのデータの保存を完全に禁止するものではありません。ハッシュはサーバーにのみ保存されるため（攻撃者がアクセスできないはずであり、ユースケースでは短期間の保存のみが必要であり、後でこれらのハッシュを削除できる（そしてすべき）ため、ここでは実際の問題は発生しません。攻撃者はなんらかのハッシュのコピーを取得して、これらのユーザーに影響を与えるのはごく少数のユーザーのみです。つまり、現時点でアクティブなダウンロードがあったユーザーのみです。
しかし、そうでないと感じる場合は、ハッシュにシード（ランダムな種類の）を含めることで、保護を追加できます。各シードは、一定期間のみ有効です。これにより、ダウンロードの可能な時間内にすべてのシードを確認する必要があるため（したがって、古いシードを短時間保持する必要があるため）、重複するダウンロードの検証が少し難しくなりますが、IPとハッシュ間の事前計算されたマッピングが役に立たなくなります。