In Depth
Protecting Data at Rest
New approaches to protecting data at rest (and avoiding the wrath of your customers).
By Simson Garfinkel
For example, the Unix password system uses hashed passwords to increase the operating system's overall security. Here's how it works: Instead of storing user names and passwords in the user database, Unix systems store user names and passwords processed with cryptographically secure one-way hashes such as MD5. When a person tries to log in to the Unix system, the operating system takes his password, hashes it and compares the result to the value stored in the database. If they match, the user is allowed to log in. But if an attacker breaks into the system and accesses the database directly, all the attacker gets is the hashes, not the actual passwords.
A few years ago Peter Wayner, an independent consultant and author who specializes in cryptographic applications, came up with a method for using one-way hash functions to protect other kinds of information stored in a database. For example, a database that includes the hash of a person's SSN still allows SSNs typed on Web forms to be validated, but such a database makes it virtually impossible for the database operator (or hacker) to browse the database and download a list of names and SSNs. That's because the simple SQL statement "Select * from Customers" would no longer return the customer SSNsâ¬it would just return the hashes of those SSNs.
Wayner calls his approach "translucent databases," and it's good for a lot more than just storing SSNs. For example, you can use a translucent database to eliminate phone numbers, e-mail addresses, names, addresses and other kinds of sensitive informationâ¬while still giving people the ability to look up and use records that contain this information. In his book, Wayner shows how to use the translucent database technology to build a baby-sitter matchmaking application. Even though this database somehow contains a list of young teenage girls who are spending the evening in expensive houses with otherwise unguarded small children, the translucent database technology makes it essentially impossible to dump out that highly sensitive information. Even the data bank's own operators can't make it reveal its secrets. Public-key cryptography can be layered on top of these databases so that the sitter's cell phone number can be decoded by Mom and Dad but not by Uncle Ernie.
Option 4: Blow It Up
Probably my favorite system for protecting data in a database against browsing or large-scale downloading is a system called Vast that was developed at the Georgia Institute of Technology by David Dagon, Wenke Lee and Richard Lipton. Vast uses cryptographic techniques to dramatically increase the size of a database. A 5- or 10-gigabyte database can be inflated so that it takes 10 or 20 terabytes to store. Individual records can be accessed relatively quickly, but any attacker attempting to read all of the data immediately runs into scalability issues. And downloading random slices of the database won't reveal anything useful, because as Vast's creators put it, "a secret is broken into shares over a large file, so that no single portion of the field holds recoverable information."
$firstKeyword
Security Directions: A Virtual Conference
Available On Demand Sept. 30 - Dec. 30
Join us for a virtual event with candid, expert information on top security challenges and issues - all from the comfort of your desktop.
Protecting PII: How to Work with IT to Manage Risk
Understand the critical nature of the test data privacy problem and get tips on how to work with IT to implement a test data privacy program.



