[Django] #30561: Time for peppering user passwords in Django?
Django
-----------------------------------------+------------------------
Reporter: linluc | Owner: nobody
Type: New feature | Status: new
Component: Uncategorized | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
Peppering passwords has been a controversial topic widely discussed in
many stack overflow questions. Having ran my 20+ personal email addresses
through HIBP page the findings are clear: all emails/passwords of mine
that had been leaked fall in the following categories: SQL injections,
mis-configured databases, exposed database admin panels or strayed
database backup files.
And that’s exactly what a pepper value in the hashing process is
protecting from. Breaching the whole server with physical access to the
file system is rather rare nowadays.
According to this NIST document [ Digital Identity Guidelines
Authentication and Lifecycle Management]
“In addition, verifiers SHOULD perform an additional iteration of a key
derivation function using a salt value that is secret and known only to
the verifier.”
So, why not in Django?
--
Ticket URL: <https://code.djangoproject.com/ticket/30561>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: linluc | Owner: nobody
Type: New feature | Status: new
Component: Uncategorized | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Old description:
> Peppering passwords has been a controversial topic widely discussed in
> many stack overflow questions. Having ran my 20+ personal email addresses
> through HIBP page the findings are clear: all emails/passwords of mine
> that had been leaked fall in the following categories: SQL injections,
> mis-configured databases, exposed database admin panels or strayed
> database backup files.
>
> And that’s exactly what a pepper value in the hashing process is
> protecting from. Breaching the whole server with physical access to the
> file system is rather rare nowadays.
>
> According to this NIST document [ Digital Identity Guidelines
> Authentication and Lifecycle Management]
>
> “In addition, verifiers SHOULD perform an additional iteration of a key
> derivation function using a salt value that is secret and known only to
> the verifier.”
>
> So, why not in Django?
New description:
Peppering passwords has been a controversial topic widely discussed in
many stack overflow questions. Having ran my 20+ personal email addresses
through HIBP page the findings are clear: all emails/passwords of mine
that had been leaked fall in the following categories: SQL injections,
mis-configured databases, exposed database admin panels or strayed
database backup files.
And that’s exactly what a pepper value in the hashing process is
protecting from. Breaching the whole server with physical access to the
file system is rather rare nowadays.
According to this NIST document [ Digital Identity Guidelines
Authentication and Lifecycle Management]
https://pages.nist.gov/800-63-3/sp800-63b.html :
“In addition, verifiers SHOULD perform an additional iteration of a key
derivation function using a salt value that is secret and known only to
the verifier.”
So, why not in Django?
--
Comment (by linluc):
pages,nist,gov,/800-63-3/,sp800-63b,html
--
Ticket URL: <https://code.djangoproject.com/ticket/30561#comment:1>
Django
Reporter: linluc | Owner: nobody
Type: New feature | Status: closed
Component: Uncategorized | Version: 2.2
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => invalid
Comment:
This is a discussion topic for the DevelopersMailingList.
--
Ticket URL: <https://code.djangoproject.com/ticket/30561#comment:2>