BetterOS.org : an attempt to make computer machines run better

| | | | | | |

My War Against Cryptographic "Peppers"

Sadly, we are losing the war against peppers.

You might ask "Why would you feel sad that people are using peppers? Don't you want strong security? Why would you want to wage war against strong cryptography?" Let me start out with full disclosure, I do enjoy seeing computer security fail, it highlights the deficiencies in modern software and the need to do things "better", which is what this entire website is dedicated to. If software were always written well, there would be no need for this website.

That being said, that is NOT the reason I am saddened by the gradual acceptance of "peppers". The reason I am so sad is because unlike modern software paradigms and languages which I consider harmful, the concept of a pepper isn't even well thought out or well researched. Its an idea pushed by people who have no business working in security sensitive contexts (which includes basically any programming job). Its disheartening to know that even against an adversary as stupid as the concept of a pepper, good programming is still not winning.

Let me explain what I mean. Peppers are the worst. First of all the term pepper is does not even have a generally agreed upon definition. The reason for this is because it has been re-coined numerous times over a long period of time for various new concepts (which all have been proven to be ill-advised). My theory is that once a programmer learns of the generally accepted good practice of including a "salt" with hashed data, they are so excited by this new knowledge (I understand this feeling), that they want to delve further into security and take their new understanding of hashes and security to the extreme. For a programmer, it is difficult to tell when your knowledge of a subject is rudimentary or extensive, since you can do a lot with a little knowledge, and some people inevitably believe they are qualified (because they just learned about salts) to invent totally new cryptographic concepts. Since "salt" was the name of the eye opening concept, a companion to it "pepper" is the next logical name. So basically everybody that barely understands a salt is making up goofy concepts and calling them peppers.

Pepper has been used to name several concepts. I have seen people claim that a pepper is data unique to a site or application added to a password before hashing. This does nothing to improve security as it does not increase brute force difficulty, prevent dictionary attacks, or prevent precomputed attacks, it only obscures the hash algorithm used, which does not increase security due to Shannon's Maxim. I have also seen it used to describe a random value, unique to a user and password, hashed with a password and stored along with the hash. This is the definition of salt. The same people who use this term have foolishly argued that a salt is something else entirely. I have seen it defined as a value hashed with a password and stored on another server, which is functionally equivalent to the First definition I provided. I have also seen a pepper defined as a small random value added to a password and NOT stored anywhere, then brute forced when the password needs to be verified. This is the main definition I want to argue against in this article.

Proponents of this type of "pepper" claim that it increases security by increasing the length of time required to check a password hash, and hence frustrate brute force attacks by increasing the time needed for each brute force check. This is also how it is currently defined on the most laughable Wikipedia article (sort of, the article isn't even consistent with itself). However, this is not the case, and systems using this method may actually be weaker against brute force attacks because it increases second pre-image collisions.

For example, let us assume a hypothetical hash algorithm, which can be collided, but finding such collisions is computationally difficult. A password storage and verification system is implemented using this algorithm. The system is properly salted, and works well for some time. However, eventually as years go by and computers get faster, and the problem of finding collisions become easier (as in what happens in real life). Concerned about the security of the system, the misinformed programmer reads the Wikipedia page on peppers and implements a 16-bit pepper into the system. Before the pepper was implemented, it would take the hacker an average of 10 million guesses to find a second preimage. After the pepper is implemented, now each guess will generate 65536 hashes, to crack the system, only one of those hashes needs to match the database. Thus a pepper does not frustrate brute force attempts, it only offloads some of the brute force computation off of the hacker and onto the server.

What makes the "pepper" such a frustrating concept is the fact that there is actually A large quantity of information about them. It is mostly of low quality, but the term is occasionally used by well respected people in well respected documentation, however, I have never seen a single one of these well respected sources use the term in a consistent way to any of its popular meanings, and each defines it differently. The typical source for information about on "pepper" in its popular form are blog articles and forum comments. Many of these sources (and there are many) also advocate usage of algorithms such as MD5, which is an algorithm with known collisions, thus making vulnerabilities introduced by peppers even easier to exploit. The amount of misinformation is staggering. Computer security and cryptography is a very well researched, documented, and studied field, all the good concepts are known, I do not understand why there is so much bad information online on the subject.

There is, however, a widely accepted cyptographic concept that does acheive the same goals as a "pepper" attempts to acheive. It is known as "key stretching", and many implementations of secure systems and cryptography libraries include key stretching algorithms.

Computer security is not like home security. In home security, you can increase effective security by making your home less attractive to burglars, adding cameras, alarms, puppy dogs, all are helpful and reduce your risk of burglary. This is because a burglar will notice your precautions and consider that even though your home might be technically penetrable, it would be more difficult and would carry a higher chance of failure for the burglar. For a home burglar, failure means going to prison or getting shot. Hackers are not home burglars. Hackers have a completely different set of motivations, many are motivated by political or social goals, some are motivated by the challenge, and some are motivated by money or power. For a hacker, a more secure system might be more difficult to breach, but the important difference is that "failure" for a hacker does not mean prison or bodily harm. A failed hacking attempt is often not even noticed, and even when it is, tracking the perpetrator is nearly impossible (as is necessary for the sake of freedom). So for a hacker, failure probably just means, "ehh, I'll try again tomorrow." Hackers are also highly intelligent, and I would bet that many of them are computer security professionals during the day, or at the very least skilled programmers. When designing a secure system, it is necessary to consider this, you are building a system to defend against people that are probably smarter than you or I. Adding little things that you think make the system "more secure" is not good enough, the system needs to be built upon proven concepts, and pepper is not one of these.