Bug 1258867 - Encrypted database fields should allow spaces
Summary: Encrypted database fields should allow spaces
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: PKI
Version: 3.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ovirt-3.5.5
: 3.5.5
Assignee: Alon Bar-Lev
QA Contact: Petr Kubica
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-01 12:29 UTC by Alon Bar-Lev
Modified: 2016-02-10 19:14 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-10-26 13:45:18 UTC
oVirt Team: Infra
Embargoed:
alonbl: ovirt-3.5.z?
alonbl: ovirt-3.6.0?
rule-engine: planning_ack?
alonbl: devel_ack+
rule-engine: testing_ack?

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 45587 0 master MERGED utils: allow spaces within encrypted fields Never
oVirt gerrit 45817 0 ovirt-engine-3.6 MERGED utils: allow spaces within encrypted fields Never
oVirt gerrit 45818 0 ovirt-engine-3.5 MERGED utils: allow spaces within encrypted fields Never

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.
Note You need to log in before you can comment on or make changes to this bug.