Bug 1258867

Summary:	Encrypted database fields should allow spaces
Product:	[oVirt] ovirt-engine	Reporter:	Alon Bar-Lev <alonbl>
Component:	PKI	Assignee:	Alon Bar-Lev <alonbl>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Kubica <pkubica>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.3	CC:	alonbl, bugs, ecohen, gklein, iheim, lsurette, rbalakri, tnisan, yeylon, ylavi
Target Milestone:	ovirt-3.5.5	Flags:	alonbl: ovirt-3.5.z? alonbl: ovirt-3.6.0? rule-engine: planning_ack? alonbl: devel_ack+ rule-engine: testing_ack?
Target Release:	3.5.5
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-26 13:45:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alon Bar-Lev 2015-09-01 12:29:16 UTC

Ever since 3.0 (probably even before) the encryption of database fields that was used is invalid, it uses RSA to encrypt blobs instead of using ciphers within envelope.

It also stores null and empty strings as plain, and to make it even better it trims spaces out of the input for some reason.

To conclude security... if decryption fails it falls back to use the blob as plain text.

This logic was untouched, under the hope that we slowly remove usages of it.

AAA does not use it any more, we should remove all.

For now, we remove the trim() as if the password of trim() actually works so far it will keep working, new passwords with leading/trailing spaces will be rejected.

The risk is if for some reason we have " "* in database field it will be rejected as valid password, fixing it will be re-set password by user to empty one.

Comment 1 Sandro Bonazzola 2015-09-04 09:02:17 UTC

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.

Comment 2 Petr Kubica 2015-09-21 09:44:52 UTC

Hi,
Could you provide any steps how to test it ? 
If I understand it correctly, just try to set new password with leading/trailing spaces ?

Thank you.

Comment 3 Alon Bar-Lev 2015-09-21 09:48:10 UTC

(In reply to Petr Kubica from comment #2)
> Could you provide any steps how to test it ? 
> If I understand it correctly, just try to set new password with
> leading/trailing spaces ?

yes... but which password...?
in 3.6 we are left only with storage password, I am unsure how you set these, tal?
in 3.5 you can use the engine-config -s AdminPassword and play with the admin password.

Comment 4 Petr Kubica 2015-09-22 16:43:14 UTC

Target release is set to 3.5.5 so I verified it in rhevm-3.5.5-0.1.el6ev.noarch

Now user can set the password with leading/trailing spaces in the password.

Comment 5 Red Hat Bugzilla Rules Engine 2015-10-18 08:21:44 UTC

Fixed bug tickets must have version flags set prior to fixing them. Please set the correct version flags and move the bugs back to the previous status after this is corrected.

Comment 6 Sandro Bonazzola 2015-10-26 13:45:18 UTC

oVirt 3.5.5 has been released including fixes for this issue.