Bug 1258867 - Encrypted database fields should allow spaces
Encrypted database fields should allow spaces
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: PKI (Show other bugs)
3.3
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ovirt-3.5.5
: 3.5.5
Assigned To: Alon Bar-Lev
Petr Kubica
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-01 08:29 EDT by Alon Bar-Lev
Modified: 2016-02-10 14:14 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-26 09:45:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
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)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 45587 master MERGED utils: allow spaces within encrypted fields Never
oVirt gerrit 45817 ovirt-engine-3.6 MERGED utils: allow spaces within encrypted fields Never
oVirt gerrit 45818 ovirt-engine-3.5 MERGED utils: allow spaces within encrypted fields Never

  None (edit)
Description Alon Bar-Lev 2015-09-01 08:29:16 EDT
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 05:02:17 EDT
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 05:44:52 EDT
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 05:48:10 EDT
(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 12:43:14 EDT
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 04:21:44 EDT
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 09:45:18 EDT
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.