Shostack + Friends Blog Archive


Delta Blood bank

Delta Blood Bank sent a letter Friday to donors, warning them a computer that held their personal information had been stolen and advising them to take steps against identity theft and credit card fraud.

In addition to the letter…The blood bank will no longer require Social Security numbers from its donors…

No longer require social security numbers? Why were they required in the first place? Using social security numbers as an ID number (or password) has been a bad idea for a long time. As Chris Hibbert pointed out in 1994:

Database designers continue to introduce the Social Security Number as the
key when putting together a new database or when re-organizing an old one.
Some of the qualities that are (often) useful in a key and that people think
they are getting from the SSN are Uniqueness, Universality, Security, and
Identification. When designing a database, it is instructive to consider
which of these qualities are actually important in your application; many
designers assume unwisely that they are all useful for every application,
when in fact each is occasionally a drawback. The SSN provides none of them,
so designs predicated on the assumption that it does provide them will fail
in a variety of ways.

Of course, the costs of that the bad design were borne by customers, not the organization. Further, the SSN choice was a standard, and so hard to fight. Now, new rules like SB 1386 push some of the cost of that choice back where it belongs.

If your organization does business in California and collects, or over-uses SSNs, now would be a fine time to talk about bad PR and other costs of doing business that way, and push to make a liability-reducing change.


One comment on "Delta Blood bank"

  • Jonathan Conway says:

    The assumption of the uniqueness and stability (they and are changed) of SSNs is especially problematic from a database perspective (though I’m more concerned about the privacy and security aspects).  Having personally dealt with databases that had been designed with an SSN as primary key I can testify that duplicate SSNs are common enough to be a real problem—both as issued by the SSA and because of data entry problems, identity theft, and merged redundant DBs.  In a pool of a few tens of thousands of active “clients” (penal industry euphemism) we had several dozen duplicate SSNs for different distinct individuals and the process of cleaning up the schema, application logic, and business processes that been mistakenly based on SSNs was costly and desperately incomplete.

Comments are closed.