確かに、一部のハッシュは悪い考えです。セキュリティが低いか、インターセプトがあるか、レインボーテーブルが一般的に使用されているためです。これは、すべてのハッシュが悪い考えであることを意味するわけではありません。相互参照する唯一の方法は、情報を一意かつ予測可能に識別する方法です。PCIが特に禁止していない限り、ハッシュは依然として道のりです。
塩
ハッシュをソルトするようにしてください。これにより、レインボーアタックが防止されます。または、少なくともレインボーアタッカーがソルトを念頭に置いてテーブルを作成する必要があります。特に、ソルトを適度に安全に保つことができる場合は、{生成するにはソルトが必要であるため、コード内のどこかにあることを意味するため、合理的にのみ言います}。
適切なアルゴリズムを選択する
MD5は今では悪名高く、あらゆる種類の言語で実装されていますが、非常に一般的であるため、事前に作成されたレインボーテーブルを見つけることもできます。ハッシュの生成も非常に高速です。システムはおそらく少量の遅延を許容し、はるかにプロセッサを集中的に使用するハッシュを使用できます。これにより、レインボーテーブルを生成するコストがはるかに高くなります。たとえば、 Tigerアルゴリズムを確認してください。
複数回ハッシュする
関連するデータポイントが複数ある場合、複数のハッシュを使用すると、レインボー攻撃を実行するのが非常に難しくなります。例：Hash（Hash（Card＃+ salt1）+ ExpireDate + salt2）-カード番号と生成日（簡単）の両方の知識が必要ですが、簡単にリバースエンジニアリングすることはできません（すべてのカードにレインボーが必要です） ＃*すべての有用な有効期限+両方の塩の知識）。
編集:(あなたのコメント）
適度に安全：暗号化された接続（SFTP、SSH）を介してのみ送信し、暗号化されていない状態で保存しないでください-ライブ/反復コピーとバックアップコピーを含め、ファイルをWebツリーの外部にソルトとともに保持します（直接アクセス/誤ってリリースすることはできません） ）、ファイルのアクセス許可が可能な限り制限されていることを確認します（グループ/グローバルファイルアクセスを許可しないでください）。
ランダムな値をハッシュにスローする動的ソルトは、レインボー攻撃を減らすのに最適です-そのランダムな部分をハッシュ値とともにテーブルに保存します-レインボーを構築するときは、動的ソルトごとに1つ構築する必要があります。ただし、ニーズに応じてこれを行うことはできません。2回目にハッシュを作成するときに使用する適切なランダムソルトを知っている必要があります（そうしないと、2回目のカードの使用でインターセプトを取得できません）...予測可能/繰り返し可能である場合は、数値の一部に基づいて動的ソルトを作成する必要があります。これは、事実上、別のデータポイントを使用した複数のハッシュが行うことです。データポイントが多いほど、この方向にハッシュできます。たとえば、CVVがある場合（3ハッシュ）、または一度に8桁をハッシュする場合（合計3ハッシュ:) hash(hash(hash(1..8+salt1)+9..16+salt2)+expDate+salt3)。
ベストハッシュそれは動くターゲットですが、security.stackexchangeについては良い議論があります。これはSHA-512を指しています。