私は人々のお金と相互作用するクレジットカードプロジェクトに取り組んでいるので、パスワードを保存する必要があります。このパスワードには、文字ではなく数字[0-9]を含める必要があり、常に4桁にする必要があります。
このパスワードに使用するSQLデータ型がわかりません。
私が念頭に置いているいくつかの状況は次のとおりです
。A。選択した場合intはパスワードを1000から9999の間で確認する必要があります
B.選択した場合Char(4)はパスワードを数字のみ（文字ではなく）で確認する必要があります
C.選択した場合Decimal（4,0）の場合、10000未満であると確信していますが、それでも999より大きいかどうかを確認する必要があります。
そのようなパスワードについて何を提案しますか、そしてその理由は何ですか？
ピンコードはChar（4）として保存する必要があります。'int'を選択すると、ゼロなしで格納されるため、'0042'などのいくつかのピンコードで問題が発生します。Char（4）を選択した場合は、このメソッドChar.IsNumber（ch）を使用してピンコードを検証できます。
通常、私はあなたがパスワードを全く保存するべきではなく、それのハッシュを保存するべきであると言うでしょう。ただし、可能なパスワードが10,000しかないため、あまり意味がありません。データベースが侵害された場合に、攻撃者が4桁のパスワードをブルートフォース攻撃するのを阻止するキーストレッチの量はありません。
ただし、少なくともできることは、安全な方法で保存されたキーを使用してパスワードを暗号化することです（ランダムなソルトと組み合わせて、 2つの同一のパスワードが同じ暗号文にマップされないようにします）。理想的には、キーを抽出できないハードウェアセキュリティモジュールに保存し、HSMにパスワードの暗号化と検証を任せる必要があります。
（HSMもパスワードの復号化を許可するべきではありません。許可されるクエリは、「このパスワードをランダムなソルトで暗号化する」と「このパスワードがこの暗号化された文字列と一致するかどうかを確認する」だけです。可能であれば、モジュールはいくつかの組み込みの機能も備えている必要があります。レート制限では、攻撃者がHSMに接続されたサーバーを乗っ取ったとしても、少なくともある程度の時間をかけてすべてのパスワードを解読する必要があります。理想的には、モジュールはパスワードのレートも報告する必要があります。別の物理的に分離された監視サーバーに照会され、成功した照会の割合。）
とにかく、クレジットカードのデータを扱っている場合は、データベースに安全に保存する必要のある他のフィールドがある可能性があります。一般に、これらすべてを管理する非常に詳細な業界規制および/または法律があります—それらのどれがあなたに適用され、彼らが何を言っているかをすでに確認しましたか？