Support for a "pepper"

Issue #38 open
Eli Collins repo owner created an issue

(Imported from Google Code)

Some password hashing systems make use of a so-called "pepper". Like a salt, but there is a single one, stored externally from the password database, and hopefully in a manner which is as difficult for an attacker to access as possible.

Typical scheme seems to be to create a wrapper hash format, which calculated orighash(hmac(password, pepper), salt).

Some systems also store multiple peppers, allowing migration if one is considered compromised.

Will have to study this some more, not currently sure if this provides any useful security protections (e.g. in the case of a database compromise). Also need to decide where to insert this - as an extension, as a feature of CryptContext, or as a separate hash algorithm?

Comments (5)

  1. Eli Collins reporter

    (Imported from Google Code)

    Along with or in addition to this, there is the concept of an "obese pepper", as laid out by Solar Designer in a slideshow presentation (todo: add link to this), derived from the memory-hard ROMix portion of SCrypt. The core idea is to create a pepper many gigabytes in size, but use only small (state-dependant) portions of it in a given hash - making stealing the pepper time-prohibitive for an attacker.

  2. Eli Collins reporter
    • changed status to open

    (Imported from Google Code)

    Shored up plans for 1.7 release, feel this strongly needs inclusion. Looking into things, this will probably involve a couple of steps:

    1) standard pepper api for the hashes (via settings & context kwds),

    2) pepper config options for CryptContext, and

    3) add a new hash or hashes (e.g. based on bcrypt/scrypt/pbkdf2) which can support thse. kdf(hmac_sha256(msg=pepper, key=saslprep(password))) should be a sufficient basis for a simple pepper.

    4) I still want to investigate obese pepper concept, but that should perhaps be delayed until a later release.

  3. Eli Collins reporter
    • edited description
    • marked as minor
    • changed component to hash
    • changed milestone to 1.8

    Bumping this forward to v1.8; though it may slip from there as well.

    This isn't a commonly requested feature, and needs some more use-case and security analysis. While some work has been done, really need to investigate how to integrate properly with bcrypt / pbkdf2 / argon2.

    In particular, argon2 has a "keyid" and "associated data" fields that aren't fulled filled out.

    Right now, think the best design would be a hash which allowed recording a "keyid" in the hash, and a accepted a callback which resolved keyid -> value before calculating hash. This way applications could do rolling migration to newer pepper values periodically / after a breach.

  4. Log in to comment