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 there 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 scheme you propose, with GUIDs and PINs stored in the database is, frankly, a joke.