Support for a "pepper"

[GoogleCodeExporter]

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?

Original issue reported on code.google.com by elic@astllc.org on 28 Jun 2012 at 8:55

[GoogleCodeExporter]

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.

Original comment by elic@astllc.org on 18 Feb 2013 at 5:28

[GoogleCodeExporter]

Just to add a few more references --

Mozilla apparently has a 
[https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Password_Storage 
Password Storage] document recommending the use of peppers, and a 
[https://github.com/fwenzel/django-sha2 reference implmentation] on github.

Original comment by elic@astllc.org on 21 Sep 2013 at 9:14

• Added labels: Milestone-Release1.7, Priority-High
• Removed labels: Milestone-Release1.8, Priority-Low

[GoogleCodeExporter]

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.

Original comment by elic@astllc.org on 26 Dec 2013 at 9:48

• Changed state: Accepted