password hashing should support bcrypt
Bug #862730 reported by
James E. Blair
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Invalid
|
Wishlist
|
Yogeshwar |
Bug Description
The initial fix to https:/
Passlib, which is used in the implementation above, supports bcrypt, but suggests that py-bcrypt be installed if bcrypt is to be used; so the packaging for keystone should add a dependency to python-bcrypt when bcrypt hashing is implemented.
Changed in keystone: | |
assignee: | nobody → Yogeshwar (yogesh-srikrishnan) |
Changed in keystone: | |
importance: | Undecided → Low |
importance: | Low → Wishlist |
To post a comment you must log in.
Reference=> http:// packages. python. org/passlib/ new_app_ quickstart. html#recommende d-hashes
Based on what I read all the three are good.I do agree that people could prefer one over the other. As we agreed over the chat we would be providing options to chose any of the three schemes.
If you’d like to set up a configuration that’s right for your application, the first thing to do is choose a password hashing scheme. Passlib contains a large number of schemes, but most of them should only be used when a specific format is explicitly required. For new applications, there are really only three choices [1]:
* bcrypt
* sha512_crypt
* pbkdf2_sha512
All three password hashes share the following properties:
* no known vulnerabilties.
* based on documented & widely reviewed algorithms.
* basic algorithm has seen heavy scrutiny and use for at least 10 years.
* public-domain or BSD-licensed reference implementations available.
* in use across a number of OSes and/or a wide variety of applications.
* variable rounds for configuring flexible cpu cost on a per-hash basis.
* at least 96 bits of salt.
The following comparison should help you choose which hash is most appropriate for your application; if in doubt, any of these is a good choice, though PBKDF2 is probably the best for portabilit