Fog Creek Software
Discussion Board




Best Practices for storage of SSN/SIN?

Hi all,

I'm working on a project that (against our recommendations) is going to need to store Social Security Number (US) and Social Insurance Number (Canadian) information.  Given the recent focus on privacy and identify theft, I'd like to make sure that everyone involved in the project is aware of the potential risks and pitfalls, and takes steps to mitigate them.

Does anyone have any advice (or pointers to additional information) regarding best practices for the design of systems meant to track sensitive information such as SSN/SIN?  I recognize that there will be technical issues (security api, db design, system architecture), data issues (policies regarding access to systems by admins, policy for destruction of old data) and legal issues.

Thoughts?

Darren.
Wednesday, March 05, 2003

Id be interested to here an answer for this, I have heard from others that in the design of an Online shop that you never ever store the whole Credit Card numbers. And I presume a SSN or SIN is quite a bit more important than Credit Card numbers... So my reckoning is that you shouldn't be storing these numbers either normally.

And unless it is for the government, I would say that you shouldn't even have the number to begin with. In Australia I believe only government institutions can request your TFN (the SSN equivalent). Is it the same in the US?

Chris
Wednesday, March 05, 2003

A New Zealand company that asked for your IRD number (the nearest thing to an SSN) would be bizzare and nobody would touch it.

James
Wednesday, March 05, 2003

In the United States many companies demand social security numbers: Banks, Insurance companies, loan companies, employers, and schools.  It is not as common today, but I've also had video-rental stores ask for it.

A. Coward
Wednesday, March 05, 2003

<quote>
I have heard from others that in the design of an Online shop that you never ever store the whole Credit Card numbers
</quote>

Unfortunately if you have to do reoccurring credit card charges its almost impossible to get out of not storing the cc number. Anyone have any good ways to work around this?

Jeff

Jeff
Wednesday, March 05, 2003

Are you sure that you really need to store the actual SSN? If you just need the number for comparison (authentication) purposes maybe you could just store a hash of the SSN.

Andy
Wednesday, March 05, 2003

Thanks for the feedback.

This isn't an online shop -- it's an internal financial application.  The SSN/SIN is needed to pass on to government and financial institutions.  I recognize the business requirement to store it, but it doesn't make me any more comfortable about it.

Darren.
Thursday, March 06, 2003

if it's a financial app it must have all sorts of privildged data. so you probably have lots of security concerns, and are addressing them. what are you afraid of? someone stealing the whole database? hackers? internal employees?

the ssn itself is worthless, most any 9-digit number is one. it's the correlation with other data which is interesting.

when i re-enabled my cell phone i think the employee terminal displayed my id number. i think they got it from my phone number. some nice 'procedural safeguards', eh? and this was in a store no less.

mb
Thursday, March 06, 2003

How about you generate another set of uniqe numbers based on the SSN and some other factors. You can then use this everywhere instead of the SSN.

This would obiously invlove more work, but atleast you will be more comfortable with things.

Prakash S
Thursday, March 06, 2003


Andy: That's a really good idea, using a hash.

Prakash: That's a really good idea too, that
way you partition the security zones and freely
use the user's unique ID in the system while
still mapping to the user's SSN. The idea is
once you start to associate the user's profile
and preferences with a system user id instead
of the SSN .. you can just encrypt the SSN and
User ID association, and take that data off-
line for secure storage. The assumption here
is a hacker can't access can't be compromised.
If you can ensure this reporting generation
works in a section of the network that's
carefully sealed off from the net it's even
better.

So let's say you got User table like this:

ssn              Account Balance
------------------------------------------
555-55-0001      $0
555-55-0002      $50
555-55-0003      $10

You create a user ID mapping to the SS

ssn maps to user_id
5555-55-0001 maps to 1
5555-55-0002 maps to 2
5555-55-0002 maps to 3

And then store the user data like this instead

user_id          Account Balance
------------------------------------------
1                $0
2                $50
3                $10

During reporting you would join the tables and
use the associated SSN instead.

If people need to be able to submit their SSN
as a login challenge.. just store a hash of the SSN
as Andy suggested, although technically there
are still some weakness to this depending on the
cryptographic library that's providing the hash function.

Li-fan Chen
Thursday, March 06, 2003

With regard to storing credit card numbers...

Just did a bunch of research on this.  Typically, you contract with an online transaction processor (like CyberCash, now owned by Verisign) to handle the credit card transaction.  Verisign will store the credit card numbers for you.  You access a merchant portal to settle the transactions or to issue refunds.  You can store the credit card numbers but it takes extra effort (setting up a secure database server not connected to the internet) and is not necessarily needed.

(Technically I believe you do not actually see the credit card number in the merchant portal, instead you settle/refund by using the transaction authorization number which was issued at the time of the original transaction).

Will
Thursday, March 06, 2003

Since you need to pass the number on to government agencies (i.e. it isn't used as a password) a hash won't be appropriate given that hashes are one way (well...the one's that are half decent). In my own experience I have used asymmetrical encryption: When the user stores a secret piece of information on a machine which I am not fully comfortable with (i.e. a co-located machine that is publicly accessible) I encrypt it with public key encryption (i.e. RSA. .NET now has RSA encryption) and store the encrypted block in the database. When necessary I replicate the data to a secure machine, decrypt with the private key (that of course is not on the potentially risky machine) and use it.

Having said that there is still a risk that hackers could simply install a interception/backdoor and grab the data before it's encrypted, but the reality is that most compromised machines are one off get in, smash the windows, and run away with a dupe of the data. As long as you code sign/audit your runtime configuration this isn't as much of a risk.

Cheers!

Jimmy Chonga
Thursday, March 06, 2003

I am a little surprised that no one has mentioned that a portion of people living in the US do not have SSN.  Sure, they may have a Tax Id, but not a SSN.  Your business should be aware that they are limiting their customers.

Also, the only corporations that I'll disclose my SSN too are financial institutions and the government.  Maybe I'm just paranoid but I would shop elsewhere if a video store asked for my SSN.

On a side note, I know employers (farmers) that ask to see, but never copy the SS card for there employees.  To have the SS card on file opens them to additional liability.  I am not exactly sure why.  I think that if INS gives them a visit, it is harder to examine the authenticity of a SSN, if the proof is not on file.

Jonathan
Thursday, March 06, 2003

Interestingly enough, Yahoo has a story about SSN's being stolen from the University of Texas. Evidently someone hacked their system and took 55,200 valid number.

The story's at http://story.news.yahoo.com/news?tmpl=story&u=/ap/20030306/ap_on_hi_te/university_hacked

RocketJeff
Thursday, March 06, 2003

*  Recent Topics

*  Fog Creek Home