Password column limit (128 char) in the Password table exceeded when using passwords exceeding 2000 characters (sqlalchemy<1.1.0)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| OpenStack Identity (keystone) |
High
|
wangxiyuan | ||
| Pike |
High
|
Unassigned | ||
| Queens |
High
|
Unassigned |
Bug Description
Type: Automation Test case
Last Successful Run: Newton
Test Release: Pike
Test:
'openstack --os-username 'keystoneuser00
Response:
String length exceeded. The length of string 'RgJSa?
Debug Response:
https:/
Uptill Newton, SHA512 was used for hashing, however this had a number of vulnerabilities, and in Ocata a much stronger password hashing scheme was adopted by Keystone.
Security Note: https:/
Blueprint: https:/
The new Hashing scheme doubles the size of the Salt value which causes it to exceed the 128 character restriction on the DB column. However Keystone’s configuration still indicates 4096 characters as being the maximum allowed password, so our test case should have succeeded.
Based on initial conversation with Morgan Fainberg and Lance Bragstad, this seems to be an issue in the following code section:
https:/
which is retrieving the class version of the hybrid_property and not the instance version.
N.B:
- CONF.identity.
- Default hashing configuration (for Pike) is used
- Same issue seen both on creating a user (with long password) or updating them
summary: |
- Limit for the Password column in the Password table exceeded when using - passwords exceeding 2000 characters + Password column limit (128 char) in the Password table exceeded when + using passwords exceeding 2000 characters |
Morgan Fainberg (mdrnstm) wrote : Re: Password column limit (128 char) in the Password table exceeded when using passwords exceeding 2000 characters | #1 |
Changed in keystone: | |
status: | New → Confirmed |
importance: | Undecided → High |
milestone: | none → queens-3 |
wangxiyuan (wangxiyuan) wrote : | #2 |
Strange, I can't reproduce with Master branch (backend is Mysql)
http://
Did I miss something? Or the bug is for LDAP backend? or it's only the issue with Pike?
Kam Nasim (knasim-wrs) wrote : | #3 |
wangxiyuan,
- Identity Backend is set up as SQL (Postgres)
- I was working off Pike (pulled on stable/pike)
wangxiyuan (wangxiyuan) wrote : | #4 |
Still can't reproduce
use keystone stable/pike branch and postgresql: psql (PostgreSQL) 9.5.10
Kam Nasim (knasim-wrs) wrote : | #5 |
the test case that first hit this issue (and can consistently reproduce in our environment) was doing password update operations for admin users (those assigned an admin role).
Not sure how the Role Assignment (and backend) is related to the Identity CRUD operations but just another data point to consider when attempting reproduction.
Lance Bragstad (lbragstad) wrote : | #6 |
The same hashing process should take place regardless of creating a new user or updating the password for an existing user by an admin. Kam, are you saying you can only recreate this using the admin override?
Colleen Murphy (krinkle) wrote : | #7 |
Marking incomplete while waiting on an answer to Lance's clarification question.
Changed in keystone: | |
status: | Confirmed → Incomplete |
Kam Nasim (knasim-wrs) wrote : | #8 |
Lance, yes in our testing and the results I discussed with you guys on IRC, we were using the keystone admin account. The Keystone admin account has an admin role on the admin project. I have not attempted to reproduce this with other accounts.
Colleen Murphy (krinkle) wrote : | #9 |
Sorry, missed that discussion.
Changed in keystone: | |
status: | Incomplete → Confirmed |
Deepak Mourya (mourya007) wrote : | #10 |
Hey i am not able to reproduce the bug with Pike environment .
openstack --os-username 'admin' --os-password 'nomoresecret' --os-project-name admin --os-auth-url http://
The above command run successfully and changed the password.
Changed in keystone: | |
status: | Confirmed → Incomplete |
Changed in keystone: | |
milestone: | queens-3 → none |
wangxiyuan (wangxiyuan) wrote : | #11 |
This error happens if Sqlalchemy lib's version < 1.1. Bump its version to >=1.1 can solved this problem.
Changed in keystone: | |
assignee: | nobody → wangxiyuan (wangxiyuan) |
status: | Incomplete → Confirmed |
wangxiyuan (wangxiyuan) wrote : | #12 |
Fix proposed to branch: master
Review: https:/
Changed in keystone: | |
status: | Confirmed → In Progress |
summary: |
Password column limit (128 char) in the Password table exceeded when - using passwords exceeding 2000 characters + using passwords exceeding 2000 characters (sqlalchemy<1.1.0) |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: master
commit bc6b2f1b0b70b99
Author: wangxiyuan <email address hidden>
Date: Mon Oct 29 11:13:18 2018 +0800
Bump sqlalchemy minimum version to 1.1.0
Sqlalchemy add a new class for hybrid property in v1.1.0[1]. It
can solve the password length problem for User password SQL obj.
[1]: https:/
Change-Id: I7a18bd528607ec
Closes-bug: #1735250
Changed in keystone: | |
status: | In Progress → Fix Released |
Changed in keystone: | |
milestone: | none → stein-2 |
This issue was fixed in the openstack/keystone 15.0.0.0rc1 release candidate.
This is an issue with the SQLAlchemy hybrid_ property. expression use in the user ref, where .expression is returning Password.password.
This appears to be an incorrect use of hybrid_ property. expression.
The net result is that in some cases we store the un-hashed password (in memory only) on the Password.password which is 128 character max. The unhashed password is overwritten before persisting to the DB by the logic in the .settr.