SoylentNews is people
SoylentNews
You heard me. You know how weak your user’s passwords likely are. You know your users are almost certainly sharing their passwords with multiple sites. You know that a compromise of your database could lead to significant damage coming to them. You know this because it happens all the time, all over the web.
You have a duty to protect the security and privacy of your userbase. They’ve entrusted you with their data, and it is on you to keep it safe. So why aren’t you doing everything possible to accomplish that task? For this blog, we are going to talk exclusively about password storage.
If you ask just about any security professional in the world how best to store a password, you’re liable to hear something about using a cryptographically secure hashing function “with a salt.” Some will go so far as to mention algorithms like Bcrypt or Scrypt. Very few will make any mention to how password policy plays a significant part in ensuring the security of any stored values.
But almost none of them, will even mention the word “pepper.” Now I suspect this isn’t malicious, (obviously). I think even most security professionals simply aren’t informed enough to know or act with regard to this concept.
So today we’re gonna work on that…
(Score: 2) by ledow on Wednesday March 06 2019, @03:42PM
Unfortunately, nowhere near that simple.
Parts of the hash are tied into other things, and many functions - mid-function - rely on certain properties of the hash in order to operate correctly.
It takes ten minutes to go through with a debugger and just pick up the binary decision and remove it when the program is naive. There was no "bool is_certificate_valid()" function to patch out, that was then called from dozens of places.
It's a *lot* harder if you have no idea where that decision happens, or whether it happens at all, and trying to track memory to see what parts of checked for accuracy in the first place.
I don't claim it's invincible (far from it), but every "trivial" attack I worked to combat. You'd need someone with a very good grounding in C/assembler and a very good debugger and a lot of time on their hands to get close to identifying the locations and decisions affected by that.
There's no defence against such a person but a simple "patch these if statements" wouldn't have worked - even if you could identify them all.
The intention was to make it cost as much in time and effort to analyse / defeat as it would have cost to just buy the program. If you get that far, most "hackers" won't bother (even though it only takes one to do so to make a crack for it). Pretty sure I succeeded in that at least but, again, I wouldn't wager a multi-million dollar industry income on it being undefeatable.
P.S. I have written cracks for games in the past - mostly for personal interest and convenience, never distributed. Everything from MS DOS debug to feeding false data to a program and watching it in IDA. Most modern programs aren't susceptible to such things any more, admittedly, but I aimed for enough to put off the eager amateur and give the professional enough of a run for their money that it would at least be worth a blog post on what they found.