Hacker...cracker...cyber-attacker. As these criminals become more sophisticated so must your efforts to thwart them. One defense strategy, known as distributed isolation, disperses the attack surface of a computer system into isolated pieces. This strategy effectively divides system functionality and data in a way that makes it nearly impossible for an attacker to join them back together.
Two-factor authentication works in a similar way. Under this authentication method, a user needs two things to access the system; something you know (i.e. username and password) and something you have (i.e. authentication token or cell phone). Without both, an untrusted user cannot log into the system.
The first tactic in this strategy is to separate passwords from other data in your database. Large corporations typically keep passwords in an LDAP database and website data in a relational database. In this scenario, if the relational database is compromised the passwords in the LDAP database would be safe. Mashup APIs like RPX abstract out the nuances of provider specific authentication and allow your website users to authenticate with their existing identities from Facebook, Google, Yahoo!, Twitter, MySpace, AOL, Windows LiveID or other OpenID providers. This simple strategy would have prevented the type of security breach that occurred at RockYou.com where 32 million email addresses and passwords were exposed.
The next tactic is to separate encryption keys from encrypted data. Encryption keys should not be stored in the same database that contains encrypted data, especially when using symmetric-key encryption. Ideally, a random encryption key is generated for each encrypted item from a data set stored in the file system or in the cloud. This way, not only would an attacker need to compromise your database they also need to compromise your file system or cloud data storage infrastructure in order to decrypt the data.
The final tactic is to separate highly confidential data from less private data. Similar to the previous tactic highly confidential data should not be stored in the same database as less private data. The confidential data should be encrypted, then serialized in some manner and stored in a separate data set.
For example, let’s assume that I have a brokerage account that stores highly confidential beneficiary information for an expensive asset. Access to this information is protected by RPX. It uses myOpenID as the OpenID provider, which in turn uses my cell phone for two-factor authentication through CallVerifId™. After logging in, I choose to assign a new beneficiary to this asset. When I submit the information, the beneficiary information is serialized as XML, randomly encrypted from a set of keys stored in the file system, and stored in the Amazon S3 cloud infrastructure as a bin file with a generated Globally Unique Identifier as the file name.
In order to access this information an attacker would need to compromise the data in either one of two ways: 1) Use my cell phone, OpenID url, and OpenID password to login as me, or 2) Compromise the website file system, the relational database, and the Amazon S3 cloud infrastructure...then reverse engineer the website code to determine how to fit all the pieces back together.
As you can see from this example, a properly implemented distributed isolation defense strategy makes it nearly impossible for an attacker to compromise your data. Let’s hope your service provider agrees!
James Bell
Comments