我正在做一个与人们的钱交互的信用卡项目，所以我需要存储一个密码。此密码不应包含任何字符，只能包含数字 [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) 验证 pin 码。
Normally, I would say that you shouldn't store the password at all, but a hash of it. However, with only 10,000 possible passwords, there's not really much point — no amount of key stretching is going to stop an attacker from brute forcing a four-digit password if your database is compromised.
However, what you could do, at least, is to encrypt the password (combined with a random salt, so that two identical passwords don't map to the same ciphertext) with a key stored in some secure manner. Ideally, you should store the key in a hardware security module from which it cannot be extracted, and have the HSM take care of encrypting and verifying the passwords.
(The HSM should not allow decrypting a password, either; the only allowed queries should be "encrypt this password with a random salt" and "check if this password matches this encrypted string". If possible, the module should also feature some built-in rate limiting, so that even if an attacker manages to take over the server connected to the HSM, they still at least have to spend some time to crack all the passwords. Ideally, them module should also report the rate at which it is being queried, and the fraction of successful queries, to another, physically separate monitoring server.)
Anyway, if you're dealing with credit card data, it's likely that there are other fields in your database that also should be stored securely. Generally, there are quite detailed industry regulations and/or laws governing all this stuff — have you already checked which of them apply to you and what they say?