How to secure access with RFID Badge and PIN Number

I have a scenario akin to a door lock which requires two-factor authentication to gain access:

• An RFID Badge with a GUID
• a 4-digit PIN passcode entered through a keypad.

I need to securely store these within SQL Server 2008. I assume it is ok to store the GUID as normal, but what methods should be taken to secure the PIN in the database and on the system as a whole?

Is a typical hash/salt method enough for a 4 digit PIN?

What would be the proper approach to secure this type of system?

EDIT

Some more info...Ultimately this system most likely needs to be more secure than a standard "door lock". Users will authenticate with an RFID token and PIN number. After gaining access to the system, A user would have the opportunity to browse and purchase items, via a credit card linked to their account(using 3rd party gateway/vault service for storage). What implications would this impose on the system?

EDIT 2

In addition, the case is that this would NOT be a web based app. Users would only access the system from dedicated workstations. The workstations would then leverage web services to communicate with the backend system/DB. How can I factor this into the mix?

Can I use a system as @Remus suggests below, where the authentication/decryption is all a function of the RFID card? The workstation would then communicate with the backend using the authenticated users ID. Is t开发者_StackOverflow社区here a way to implement such a system?

Badge + PIN don't work by storing PINs in the database. PINS are actually the encryption key for accessing the badge cryptographic module itself. The badge stores a private key, encrypted with a key derived from the PIN. Authenticators have a public key and challenge the badge with a nonce. The badge cryptographic module itself signs the challenge nonce with the private key (decrypted internally with the PIN) and responds with the nonce signature. The authenticator then validates the signature using the public key and thus authenticates the user (the badge holder). The key points are:

• The cryptographic authentication is established with a public/private key pair, strong RSA cryptography
• The identity is proven by possession of the private key, which never leaves the badge cryptographic module
• The PIN is solely used to decrypt the private key inside the badge. The PIN is completely useless w/o physical possession of the badge

The scheme you propose, with GUIDs and PINs stored in the database is, frankly, a joke.

I think it isn't. If someone stole your database, that stores the salt and hash of the PIN, it would be trivial for him to compute the actual PIN, because there is only 10000 combinations.

You could store just a list of HMAC(PIN, GUID) in your database. The PIN is the secret, the GUID is the data. Having the HMAC alone should not allow anyone with access to the database to get either the GUIDs or the PINs.

If an attacker stole the GUID of one of your badges AND the entire database, it would be simple to calculate the HMAC of that GUID with all possible combinations of a 4-digit PIN, and find a matching row. That 4-digit PIN will always be a weakness. Adding a salt to each row would help, but not by much. It would only increase the number of needed computations by the number of rows, which still leaves you with a trivial number for an offline attack.

The biggest weakness in this system, as far as I can tell, is that any attacker knows that the PIN is guaranteed to be exactly 4 digits, thus making pre-computed hashes worthwhile.

I'd say the best steps you can take are:

• Definitely use a salt when computing the hash, but do not store the salt in the same location as the hash.
• Ensure that access (both virtual and physical) to the database is as resticted as is feasible
• Enforce some form of 'PIN policy' to make sure they are changed at regular intervals - this way, any successful breach will only be valid for a short period of time.

EDIT: Then again, the weakness in this system might be your door's hinges, or accessibility to JCBs...