Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×

Comment Re:Put in a separate table (Score 1) 62

No, the SSN is on the tax return or form, still highly insecure. The data associated with the SSN in the IRS DB is linked to the hashed SSN.
So unless someone actually has the tax form (trivial for a few forms, difficult for massive amounts of forms) they cannot associate you with your SSN or your tax data. A corrupt IRS employee (and there are many) can easily enter one SSN into their application and get all your tax & income data. But they can't download EVERYONE's data easily.

We're talking about remedies to large data breaches here, not single experiences. Yes, your data is at risk while your tax form is in the mail or in the hands of an IRS employee, but as soon as it goes into the DB the associative data should be hashed. You don't eliminate breaches this way, you make them easier to deal with.

Comment Re:Put in a separate table (Score 1) 62

It's not foolproof, but it is easy to fix a breach. If your CC database gets hacked, you re-hash with a different salt and then send the new salt to the pre-processors, so the hash they send you is now completely different. That way you have effectively changed everyones CC # a lot quicker and easier than sending everyone a new card. If fact, regular re-hashing should be a standard in the CC industry. You keep the same card and card number but the number in the DB will change regularly.

I've actually used a system like this for processing financial data (not CC data) to keep the data associating account numbers with passwords as difficult as possible to breach. Both the account number and password are hashed. We would change the salts at the broker end every 3 to 5 weeks and keep a record of the past two salts in case some broker equipment didn't get the last update. So if our DB got hacked we didn't have to make everyone change their password or account number.

As far as I know they are still using that system.

Comment Re:Put in a separate table (Score 1) 62

Surprisingly enough, I used to work at the IRS and still have many friends who do.

We could hash all SSN/EIN data at the IRS and just deal with hashes, but the entrenched management there still does everything the old way. Why can't the EDI transaction just hash the SSN and have the IRS compare the hashes at the IRS end? Because the highly political management is too stupid to understand this.

There are many reasons I have left cushy gov't jobs, the lack of technological understanding by the higher ups is just one of them. The Peter Principle is in full force if you work in government.

Comment Re:Put in a separate table (Score 4, Insightful) 62

No, passwords, SSNs, PINs and Credit Card numbers should be hashed before inserting into any table. There is NO reason for anyone to save that data unhashed.

To compare data, just hash what the customer enters and compare the hashes. Why is this so hard for 99.9% of companies to understand?

Comment Re:Name (Score 1) 158

I actually had a business called "rent a nerd" in the early 90's when I was in my mid 20's and in great shape. I got lots of repeat calls from lonely divorced women to fix very simple "problems" with their computers. e.g. Problem: "My screen is blank!" Solution: "Turn up the brightness knob" | Problem: "My software won't load!" Solution: "You have to run the install.exe program, not the readme.txt"

If I hadn't had a girlfriend and/or a conscience at the time I would have made even more money. I did get a lot of free sandwiches & beverages, and got to see a lot of low-neckline shirts.

Slashdot Top Deals

You're at Witt's End.

Working...