2 ms·
The problem with blind hashing is that database transaction log likely has enough data to link blind hash back to the user record. Further, databases such as Po
by DenisM 14y ago
The problem with blind hashing is that database transaction log likely has enough data to link blind hash back to the user record. Further, databases such as PostgreSQL or Oracle have version stamps on all records, which allows precise calculation of record age, allowing them to be linked together. MSSQL, depending on your index structure(I.e. if you use heaps), migh also betray the fact that records were created at the same time due to ordering of records. Most certainly, page allocation algorithm is likely to betray some of the same, albeit with less precision.
Bottom line is that if you're worried about database file or backup leaks, blind hashing is not adding meaningful security. It only helps with SQL injection and text dump vectors.
Edit: Duh, it's covered further in the slides!
- nn2 14y agoDon't use a off the shelf database. They are overkill for this. This only needs a very single table key->value store where every transaction is only a single access. I would just map it to a hash table mapped directly to the raw disk. Doesn't need transactions with a log if done right. The hash spreads out the allocation, no information leaks for the allocation. If you don't have a log there are no time stamps. Modern disks are big enough that you dont need to worry about resizing the hash table. And the random salt makes collisions unlikely enough.