Bug 994751

Summary:	Beaker account passwords are stored as unsalted hashes
Product:	[Retired] Beaker	Reporter:	Dan Callaghan <dcallagh>
Component:	scheduler	Assignee:	Dan Callaghan <dcallagh>
Status:	CLOSED CURRENTRELEASE	QA Contact:	tools-bugs <tools-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	0.13	CC:	aigao, asaha, dcallagh, jingwang, llim, psklenar, qwan, rmancy
Target Milestone:	0.16	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-17 03:01:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dan Callaghan 2013-08-08 00:15:33 UTC

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 07:06:31 UTC

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-28 04:36:20 UTC

(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 05:18:34 UTC

On Gerrit: http://gerrit.beaker-project.org/2562

Comment 7 Dan Callaghan 2014-03-17 03:01:27 UTC

Beaker 0.16.0 has been released.

Comment 8 Petr Sklenar 2014-03-20 10:31:17 UTC

I guess this is related issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1078790

Comment 9 Nick Coghlan 2014-03-21 02:58:39 UTC

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.