Reducing Risks from New Database Attack
In yesterday's post on a new database timing attack, I said that it would be difficult to mitigate, at least for existing database applications. If we are starting with a new design then we can make some relatively simple modifications to the data model and some additional changes to application code to reduce the risks from this attack. The key is to use a hash function, like MD5, to calculate a value that can be used for indexing but will not reveal confidential information. Here are the steps:
1. For each column in a table that must be indexed and contains confidential data, add a corresponding column to store the hash value of the confidential data.
2. Create an index on the hash value column.
3. When querying, rather than select on the confidential data, use the hash value in the selection criteria, something like 'SELECT * FROM customer WHERE ssn_md5=MD5(p_ssn)'
In this example, ssn_md5 is a column in the customer table with the hash value of the customer's SSN, MD5 is a function call to calculate the hash value, and p_ssn is an SSN passed in as a parameter to the query.
Since there is no practical way to calculate the confidential data from the hash value, the timing attack is blocked.
Oracle supports functional indexes so you could also use those instead of adding another column to explicitly store the hash value.
Now, as I said this works well with new designs. Retrofitting this onto existing applications is possible but would be a lot of work for all but the simplest systems.
What to do about existing apps? Log monitoring could help identify unusual insert activity and application firewalls might be able to detect troublesome patterns of activity . It looks like the solution for existing applications lie outside the database.
What do you think? If you have any suggestions for other readers, please post them as a comment.
Email This!
Digg it!
Sphere it!
Del.icio.us
Reddit!
Newsvine
