support alternative password hashing in keystone

Bug #1543048 reported by Morgan Fainberg
270
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
High
Morgan Fainberg

Bug Description

Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt.

NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost.

The proposal is as follows:

  * Allow selected support of different password hashing algorithms from with passlib architecturally

  * Expand to support bcrypt

  * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12

  * Keep the default the same as today

  * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required)

  * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

Set this as wishlist as it would be at best a nice-to-have.

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

I would have included scrypt support as a "nice to have" as part of the proposal as well, but passlib does not currently implement scrypt and I expect we should maintain a single library for password hashing for code maintenance/supportability reasons.

Revision history for this message
Jeremy Stanley (fungi) wrote :

There's nothing wrong with using SHA-2/512, AS LONG as you use it in a key derivation function (you really just shouldn't use the bare hashing algorithm to secure keys/passwords). I've been going with passlib's pbkdf2_sha512 scheme to great satisfaction in another (non-OpenStack) project, and recommend it highly. Something like:

    passlib.context.CryptContext(all__vary_rounds=0.1, default="pbkdf2_sha512",
        pbkdf2_sha512__default_rounds=1000, schemes=["pbkdf2_sha512"])

Revision history for this message
Steve Martinelli (stevemar) wrote :

Marking bug 1176134 as a dupe of this bug, since this bug as more detail. I'll add the description here:

=====
1176134: Password handling should be pluggable

As of now in sql backend, password handling code is embedded in identity driver. (ie), number of iteration, how the hash value is calculated, salt value etc. Ideally it should be pluggable with the current code be the default implementation
=====

Changed in keystone:
status: New → Triaged
Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

Moving this to "high" as sha512_crypt is totally insufficient for password hashes.

Changed in keystone:
importance: Wishlist → High
Changed in keystone:
assignee: nobody → Morgan Fainberg (mdrnstm)
status: Triaged → In Progress
Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

Totally insufficient in the way it is implemented as described by Jeremy use in a key derivation methcanism is just fine. However, keystone is using sha512_crypt instead of pbkdf2_sha512 or bcrypt or scrypt, etc.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to keystone (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/438808

Dolph Mathews (dolph)
information type: Public → Public Security
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on keystone (master)

Change abandoned by Morgan Fainberg (<email address hidden>) on branch: master
Review: https://review.openstack.org/438808
Reason: Abandoning, no backports needed can go with a more comprehensive fix

Changed in keystone:
assignee: Morgan Fainberg (mdrnstm) → Gage Hugo (gagehugo)
Gage Hugo (gagehugo)
Changed in keystone:
assignee: Gage Hugo (gagehugo) → nobody
Changed in keystone:
assignee: nobody → Gage Hugo (gagehugo)
Changed in keystone:
assignee: Gage Hugo (gagehugo) → nobody
assignee: nobody → Morgan Fainberg (mdrnstm)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.openstack.org/438701
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=8ad765e0230ceeb5ca7c36ec3ed6d25c57b22c9d
Submitter: Jenkins
Branch: master

commit 8ad765e0230ceeb5ca7c36ec3ed6d25c57b22c9d
Author: Morgan Fainberg <email address hidden>
Date: Mon Feb 27 13:06:07 2017 -0800

    Support new hashing algorithms for securely storing password hashes

    Support bcrypt, pbkdf2_sha512, or scrypt in password hashing for
    passwords managed within keystone. sha512_crypt is insufficient to
    hash passwords in a secure way for storage in the DB. Keystone defaults
    now to using bcrypt but can handle scrypt and pbkdf2_sha512 with a number
    of tuning options if desired.

    Closes-bug: #1543048
    Closes-bug: #1668503
    Change-Id: Id05026720839d94de26d0e44631deb34bcc0e610

Changed in keystone:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone 12.0.0.0b2

This issue was fixed in the openstack/keystone 12.0.0.0b2 development milestone.

Changed in keystone:
milestone: none → pike-3
milestone: pike-3 → pike-2
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.