Re: We've asked the Information Commissioner's Office to confirm it is aware of the issue. ®
I am more concerned that account data is stored in a manner by which an off-by-one on the customer index just gives you all the access to that other data no matter who you are (i.e. poor permission control) and that there's no attempt to test that customer indexes match across tables (i.e. that you put in a "where this.index = that.index" kind of clause that would just return empty results if you mess up one of the indices.
I'm more concerned however that modern companies are still just keeping huge tables of customer data that even they don't need access to in that manner, where a slip of a coder's finger results in actual real results of other customers.
We're still just designing these systems incorrectly, shoving everything as rows into the same tables with no thought of restricting data.
Hint: If your customer index table contained nothing more than an index and a decryption key, and your customer address table contained only an unencrypted index and everything else encrypted, then index-mismatches like this would stop you hitting this class of bug. Not everything, but the simple things at least.
Or permission controls. Or some kind of audits and checks rather than just trusting the result out of the database. Some kind of script checking why suddenly 10,000 accounts are returning different data to ten seconds ago, after you just updated, etc. etc.
But, no, lob it all "in the database" and just blindly spaff results around with no checking.
Biting the hand that feeds IT
