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 Tuesday March 05 2019, @06:21PM (2 children)
You mean... the thing I thought of about ten years ago knowing that it adds nothing to security to anyone who has access to the program, but maybe a little to obfuscation.
I used "peppers" on hash data in a DRM scheme I knocked up ten years ago using X509 certificates inside the application, one unique one to each client, that both sign each other. The program checks the signatures at different points of the program using different methods. It also checks that some files themselves aren't modified (i.e. the program itself and modules that it loads) again via certificates but also via hashes of some parts of some data files in certain orders, including some deliberate "oops I reused that variable without clearing the previous data" 'peppering' of the hash before it starts (in order to make it difficult to discover what a stored hash in the binary actually represents, so it's difficult to modify).
It made a pretty good DRM scheme, at least comparable to a commercial offering, but without all the junk and hassle... and basically ultimately pinned to OSCP. Tampering with the base program, any data file, or any certificate (hard-coded or not) is hard to do. Every "purchaser" gets a unique certificate. The program has to go on the net to verify that the certificates are still valid (i.e. that the time is still right, that they had not been revoked having been discovered in the wild, etc.) and it only allows offline-caches of the certificate status for a certain period.
But against any determined hacker, all that would be... "tamperable"... if given enough time and effort. But not if they don't know where every hash-check is, what it's hashing, what data the hash started with (the "pepper" in this article), and where that hash is stored (I did a lot of sucking in data from all kinds of places that are indistinguishable from other program data, and then referring to it obliquely later, and conjoining parts to make hashes and checking them at a much later time, and failing - again much later - if they didn't match).
(Score: 2) by chromas on Tuesday March 05 2019, @10:39PM (1 child)
Sounds like I just need to find these checks and replace them with a stub that just returns True or whatever. No need to deal with the certs.
(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.