July 19, 2017
Posted by on
Heads-up on a great Humble Bundle on crypto, security, hacking, and all sorts of related topics. As a pay-what-you-like deal it’s amazing given these books are worth. I’m really keen to read Threat Modeling: Designing for Security and Cryptography Engineering: Design Principles and Practical Applications; that is my bed side reading set for months to come. Offer ends around the end of July, and found via Bruce Schneier’s blog.
February 6, 2014
Posted by on
A Boston Globe blog reported that a trickier approach to dealing with hackers might be a better approach. Essentially make the data messy and it will not be as desirable. It certainly sounds interesting as a concept. Brainiac wrote “rather than trying to block hackers, maybe it’s better to distract them.”
The approach is built into a new piece of software called Honey Encryption, created by Ari Juels and Thomas Ristenpart, and it works on a simple model. After hackers steal a trove of encrypted data, they hunker down to crack the code. It can take them thousands of tries before they’re able to guess the right cryptographic key, and Honey Encyyption makes them pay for each failed attempt.
Each time hackers enter the wrong password, Honey Encryption adds a piece of fake data to the dataset—by the time hackers finally get access to the data, it’s swimming with so many fake credit card numbers, for example, they’ll have no idea which ones are real.
Pardon? I think the readers might be missing a key aspect of the information here. This is a very specific circumstance and very unlikely frequency where this is plausible.
For this approach to work the “honey encryption” software needs to be running with the stolen data-set. In fact it is unlikely that the data would be stolen at all, rather it is being attacked on it’s normal infrastructure. Frequently when data is stolen the database itself is extracted on mass; the encryption used on the information in the database is broken later. A hacker is not going to willingly run an application which does Honey Encryption on the data they are trying to hack. Is the assumption that the software for accessing the encrypted data is somehow packaged with the data in the DB? Huh? No! This means that for the times where the hack attempt is happening on the system live this approach might work, but otherwise it does not apply.
The same software could also alert very quickly to the admin teams that a potential attack is in progress too. This is the approach taken with the “honey words” concept, where a dataset is setup with a number of “deliberately bad” datasets for each user account so that when the hacker tries to decrypt the data an alert or action is triggered. That makes a heap of sense.
So this approach adds junk data into a live system to increase the ratio of bad data to good data for when it gets stolen? Yes, and as long as the good data is not altered by the “honey” then the end user is not affected, but the system owners can know of a potential exposure. Interesting.