Oracle Database Redaction Trivial To Bypass, Says David Litchfield
msm1267 (2804139) writes "Researcher David Litchfield is back at it again, dissecting Oracle software looking for critical bugs. At the Black Hat 2014 conference, Litchfield delivered research on a new data redaction service the company added in Oracle 12c. The service is designed to allow administrators to mask sensitive data, such as credit card numbers or health information, during certain operations. But when Litchfield took a close look he found a slew of trivially exploitable vulnerabilities that bypass the data redaction service and trick the system into returning data that should be masked."
I mean it sounds like this is just to protect sensitive data from the day-to-day work of your regular old DBAs. They aren't trying to look at the data, and hack into the system to examine it. They just shouldn't unnecessarily be exposed to it.
No, passwords, SSNs, PINs and Credit Card numbers should be hashed before inserting into any table. There is NO reason for anyone to save that data unhashed.
To compare data, just hash what the customer enters and compare the hashes. Why is this so hard for 99.9% of companies to understand?
As a developer in the industry here I can honestly say nobody in our industry would be dumb enough to use this tool. Security is very important, and i'm sure PCI compliance would be a huge issue. Unless under a dual-control situation and 4-5 physical doors from the outside world, no un-masked CC# exists except on physical card. Yes, it would be nice for that service for software developers to use as a tool for display....like in my case, to provide cleansed data to the screen without manually cleansing data....but the issue is that PCI will dictate where that data can exist, and if it's uncleansed and accessible to a DB admin or software dev, there's too much visibility. They look at it from the standpoint that if a single person has access by themselves then they're likely to steal them. I don't see why they would automatically allow search within masked bytes (at least if it's ultra sensitive).....I can understand if maybe there's a setting like (sensitive to search) so that CC#'s couldn't be brute forced, however a search for a person's last name where all but the first letter are masked would probably be okay.
In the payment card industry, this is called a token, not a hash. The difference is that a hash can be algorithmically generated from the source material, while a token cannot. Because there is no forward link outside the entity that generated the token to go from card to token, the tokens can be different at each merchant, making a loss of token much less of a problem than a loss of hashes would be. It's also 100% infeasible to break the token generating algorithm since there isn't one. In my experience, tokens are simply generated sequentially (skipping those that don't pass Luhn check). Another beauty of tokens is that they can pass validity checks for credit card numbers, so they can be handed to third-party software and treated just like card numbers, but without the risk of breach.
No, passwords, SSNs, PINs and Credit Card numbers should be hashed before inserting into any table. There is NO reason for anyone to save that data unhashed.
To compare data, just hash what the customer enters and compare the hashes. Why is this so hard for 99.9% of companies to understand?
ACH processing requires sending bank account information to the ACH along with how much to bill the individual. Many other forms of automated payment processing formats also require credit card numbers sent - this is all happening with flat files. If you expect credit card numbers to be hashed in your database, then you need to convince the receiving end of that data that they do not need the source to send that data.
If the card company accepts hashes then having the hash is no different than having the card number. In other words, no, it isn't nor should it be, done that way.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Exactly. Look at it this way: your credit card number already IS a hash of your and your banks identities. That doesn't magically make it secure.
/users.html
Sleep your way to a whiter smile...date a dentist!