Talk:Pepper (cryptography)

Nomination for Deletion?

The creator of the article seem to be coining words, and it's done terrible compared to DWARF.

From the explanation of the article, I feel this "pepper" is not so much different from salt in a cryptographical sense, and given that no source has been cited, this article probably should be removed.

Dannyniu (talk) 06:42, 15 August 2016 (UTC)

It is completely different to cryptographic salt. This topic is not covered that often and so many people who use salted hashes don't know about peppering unless specifically taught it.

I've actually looked for resources about peppering before, and couldn't find any well put together articles on it. This article is very helpful to explain to people what peppering is.

interkin (talk) 2:42, 23 May 2017 (UTC)

Unfortunately, although it might be helpful to explain what people think "peppering" is, use of a pepper is not a generally accepted as good practice in cryptography (unlike a salt, which is essential). As far as I can tell, the term pepper as it is commonly used, was collectively coined by amateurs who recently learned what a "salt" is (and frequently don't understand even that fully), and got way to excited about their new knowledge and wanted to apply the naming convention to their own inventions, which are not proven and often weaken security. The fact that this article has not been deleted yet makes me question the general accuracy of all of Wikipedia. This article is dangerous as anyone attempting to implement this concept will create a very insecure system. This article should either be deleted immediately or a clear warning about the dangers of a "pepper" being added to the article. Prushik (talk) 03:05, 19 January 2018 (UTC)

Please note that while this article seems to have been greatly approved (its at least internally consistent now, the example actually matches the description), it still has the enormous problem of describing something that is completely made up. The only cited source does seem to be a reliable source and describes something pretty close to what is described here, yet after carefully reading the source it never uses the term "pepper". Anybody wonder why? It's because "pepper" is not an accepted cryptographic term or concept. If it were, there would be no shortage of good sources since password hashing is hardly an obscure topic. Prushik (talk) 21:22, 12 November 2019 (UTC)

Pepper has two meanings

Pepper can mean one of two things:

• A hardcoded secret that is the same for all passwords. For example mentioned in the article about Dropbox password hashing.
• A random secret that is not stored, and has to be brute-forced for every password. The name "pepper" was defined in the paper "Brute Force Attack on UNIX Passwords with SIMD Computer".

Sjoerd (talk) 12:54, 12 December 2016 (UTC)

Dubious

The definition of pepper as random values that the code validating a hash must iterate through is not common, particularly with the introduction of hashing algorithms with cost parameters. At face value, this particular paper doesn't even offer that definition: it only actually equates pepper to a "secret salt" and describes one way to implement it. I don't have access to the paper it in turn cites, but that doesn't mention the word pepper in its abstract. Ms7821 (talk) 16:51, 24 September 2017 (UTC)

As for Sjoerd's citation, that also doesn't define pepper bits as discarded, only in their implementation. I wonder if it's worth only defining pepper as complementary to a salt (and therefore coined repeatedly over the years). I'm concerned that recent articles (like the Dropbox one) may be hedging their wording based on this article's over-precise claims. Ms7821 (talk) 17:00, 24 September 2017 (UTC)

OK, I've made a bunch of changes. Hopefully that improves things Ms7821 (talk) 18:36, 24 September 2017 (UTC)

Where I saw the Dubious marking, it says that the length of the salt only needs to be enough to be unique to each user. That seems entirely wrong. If you only have 8 users and thus a 3-bit salt, then the attacker can do 8x pre-computation of rainbow tables associated with each salt value to prepare for stealing the password database. Since the cost of having a longer salt is minimal, it is common AFAIK to use 128-bit salts. That is way, way more than enough for them to be unique, but it makes pre-computation infeasible. — Preceding unsigned comment added by 2620:8D:8000:107C:A4D4:13A6:8824:79D4 (talk) 13:02, 1 November 2024 (UTC)

Completely agree! It's certainly misleading as it is, and it has no citation. I'm going to remove that part of the text, unless someone can justify it. StagDancer (talk) 17:03, 6 November 2024 (UTC)

poor example

Although the overall explanation about pepper as an additional security feature in terms of salt&pepper might be ok, the example and it's explanation is choosen poorly. Using a salt is to make hashes more unique and thereby hide the information if two users may used the same password - that's what a salt is meant to mitigate. As it's explained, the pepper shpuld prevent rainbow a database as it's not stored in it but in a file as example. So, a better example would be: "passwird + salt + pepper". The proof could be: 1) the different salt hides that both users use the same password and the pepper, as stored elsewhere, prevent rainbow attacks when the database gets leaked. As now the example even weakens the security as it's compareable to use same salt twice, wich in fact has the same level of security than not using a salt at all. Also it's only very specific in the scenario about leaking a database and hence prevent rainbow attacks by storing the pepper outside of it. This could also be generalized as salt and pepper in terms of cryptographic hashing can be used differently. 2A0C:D242:4434:200:159F:2EE0:30E:F319 (talk) 20:11, 30 September 2019 (UTC)

a "Unique pepper per user" is called a "salt"

A "unique pepper per user" is called a "salt". This section should be removed, and the "types of peppers" section should be updated as well. This article continues to be incorrect and misleading. Prushik (talk) 18:30, 19 December 2022 (UTC)