Bug 994751 - Beaker account passwords are stored as unsalted hashes
Beaker account passwords are stored as unsalted hashes
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
0.13
Unspecified Unspecified
unspecified Severity unspecified (vote)
: 0.16
: ---
Assigned To: Dan Callaghan
tools-bugs
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-07 20:15 EDT by Dan Callaghan
Modified: 2014-03-20 22:58 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-16 23:01:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Callaghan 2013-08-07 20:15:33 EDT
For user accounts with a password set in Beaker (that is, accounts which are not authenticated through LDAP or Kerberos) Beaker stores the password as an unsalted SHA1 hash. It should at least be salted with a unique salt per user.

Nick has suggested using passlib to do the hard work of managing passwords correctly:

http://pythonhosted.org/passlib/
Comment 2 Nick Coghlan 2013-11-27 02:06:31 EST
I realised we can tackle this for new installations without solving the password migration problem by offering a config option that enables a fallback option that checks for an unsalted hash.

So new installations would get salted hashes by default, while existing installations could enable the option to check for unsalted hash entries in the DB.
Comment 3 Dan Callaghan 2013-11-27 23:36:20 EST
(In reply to Nick Coghlan from comment #2)

Better yet, passlib makes it easy to support the old hashes but automatically upgrade them to new ones after a user successfully authenticates. So for existing installations, no unsalted hashes should ever be left hanging around unless the user never logs in. If a site admin is concerned about that, they can easily find old passwords using a database query and NULL them out to disable the account or reset the password.
Comment 4 Dan Callaghan 2013-11-28 00:18:34 EST
On Gerrit: http://gerrit.beaker-project.org/2562
Comment 7 Dan Callaghan 2014-03-16 23:01:27 EDT
Beaker 0.16.0 has been released.
Comment 8 Petr Sklenar 2014-03-20 06:31:17 EDT
I guess this is related issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1078790
Comment 9 Nick Coghlan 2014-03-20 22:58:39 EDT
Yes, there was an issue during the upgrade where the web service was inadvertently made available before the database update was complete and a couple of accounts attempted to log in and corrupted their password data. The affected accounts have had their passwords reset.

Note You need to log in before you can comment on or make changes to this bug.