6

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?

stephen776
  • 9,134
  • 15
  • 74
  • 123
  • Upon what reasoning is your assumption that the GUID should be stored "in the clear" based? – Eric Lippert Oct 06 '11 at 16:13
  • 1
    @EricLippert Can't speak for OP, but my reasoning is that if it can be read by an RFID reader, then making it "more secure" on the database is just security through obscurity. – Widor Oct 06 '11 at 16:22
  • 3
    @Widor: I see your point. Here's my concern. Defense in depth is about securing a system against lots of different attacks. The attack I am concerned about is that the database -- and nothing else -- is compromised, and now the attacker has a *complete* list of valid GUIDs. The attacker can then build themselves any number of cloned valid cards, and then try to compromise the PIN associated with of *any* of the cards. – Eric Lippert Oct 06 '11 at 17:02

4 Answers4

6

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.

Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
  • 2
    The question asked was how to securely implement a particular (and I assume, existing) system of RFID badges and PINs. You describe a more secure system, but it doesn't really answer the question. – Bob Oct 06 '11 at 17:13
  • @Remus This sounds like the route to go. Can you point me to any more in depth information on how systems such as these work? Please see my edit above for some additional info. – stephen776 Oct 06 '11 at 17:41
  • http://www.microsoft.com/download/en/details.aspx?id=17777 and http://www.microsoft.com/download/en/details.aspx?id=468 – Remus Rusanu Oct 06 '11 at 17:55
  • In the scheme you proposed the 'RFID GUID' is actually a 'username' and the 'PIN' is in fact a 'password'. So then you really are forcing a password composed of 4 digits, which is just not enough, as many have pointed. And, for the record, to store *any* information securely in SQL Server you would use TDE: http://msdn.microsoft.com/en-us/library/bb934049.aspx – Remus Rusanu Oct 06 '11 at 18:02
  • @Remus The actual case is that this would NOT be a web based app. Users would only access the system from dedicated workstations. The work stations would then access web services to communicate with the backend system/DB. How can I factor this into the mix? – stephen776 Oct 06 '11 at 18:36
4

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.

svick
  • 236,525
  • 50
  • 385
  • 514
  • That's true, but I think a salted hash is the best we can do here - the weakness comes from knowing that the hash is guaranteed to be of a 4-digit PIN... – Widor Oct 06 '11 at 16:00
  • 3
    ...anyone from the banking industry care to enlighten us as to how our bank PINs get stored? – Widor Oct 06 '11 at 16:01
  • I would love to hear some thoughts from someone in the banking industry seeing as how a debit card/PIN is of the same nature as my scenario. – stephen776 Oct 06 '11 at 16:09
  • 2
    This information is stored on the card. The ability to read the card likely would be an encrypted method. – Security Hound Oct 06 '11 at 16:15
  • @Ramhound Is it possible to store the GUID and PIN within the RFID tag and use methods similar to debit cards? – stephen776 Oct 06 '11 at 16:21
  • @stephen776 - That would really depend on the card you are dealing with I suppose. I just know that in the past when I had to change my pin, I had to go to the ATM, after getting it reset. – Security Hound Oct 06 '11 at 16:24
1

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.

Bob
  • 3,301
  • 1
  • 16
  • 11
  • The accepted answer supposes that the users are given SmartCards with cryptographic modules (like modern credit cards), yet the question talks about RFID cards which can only store a GUID. Hence, this answer is more reasonable. – wool.in.silver Nov 24 '14 at 14:49
0

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...

Widor
  • 13,003
  • 7
  • 42
  • 64
  • 1
    Where would you then store the salt? And how would you take care of transactions in such case? – svick Oct 06 '11 at 16:14
  • Lost me on the JCB thing...what exactly does that mean? – stephen776 Oct 06 '11 at 16:14
  • @stephen776 Sorry, might be a British thing. Website is [here](http://www.jcb.com/products/machinerange.aspx). They're a well-known brand of heavy-duty construction vehicles - suitable for use in ramming down doors... – Widor Oct 06 '11 at 16:17
  • @svick Fair point, depends on how you implement the salt: http://stackoverflow.com/questions/1219899/where-do-you-store-your-salt-strings – Widor Oct 06 '11 at 16:21