The best way to protect secrets ...
... is to never have secrets to protect. Does that make sense?
So today I got an email from someone who challenged my post on using regular expressions for data validation on the PIN field in the Users table. His position isn't about the regex itself (which he liked), but the fact I was storing the PIN in the first place.
And he is right. I didn't really go into detail in that post, but I never designed the final Anvil database structure to actually store the PIN. This was actually one of the things exposed during the threat modeling process. There is no reason an administrator should ever know a user's PIN. So why let them see it? Why even store it? In Anvil, the PIN is not actually stored. A 32 byte MD5 hash is actually stored in the database, and a regex of ^[abcdef0-9]{32}$ is used as the data filter.
I am pleased that someone actually noticed this and pointed it out. It's a great lesson on why we shouldn't store secrets if we don't need to. The Token Validation Web Service takes the PIN inputed by the user, hashes it, and compares that hash to what is in the database. If it matches, then we have a valid PIN. No need to expose the PIN directly in the database.
While waiting for Microsoft PSS to get back to me on the IAS issue I am having, I am spending time working through the new AuthEngine COM object CryptoCard have designed to use with .NET. I should be able to add that to the web service in the next few days. Once that snaps in, a lot of things will fall into place.
Lets hope I can get the RADIUS side worked out with IAS soon.