Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?
-
Hi. I've been using XCP-ng Center to manage my homelab for a while, but recently decided to give Xen Orchestra a go (mostly due to the fantastic backup options which are provided with the Premium package or built from source option). I'm enjoying using it so far (apart from an issue with some mouse and keyboard input lag, which I'm going to look more into myself to see if I can improve), but when I exported the Xen Orchestra configuration (from Settings -> Config -> Export/Download Current Config), I noticed that the resulting .json file contains the passwords for the two hosts in my homelab in plaintext.
Is this an intentional decision or an oversight? Shouldn't the password hashes be stored in the .json file (as they appear to be for the users)? Does Xen Orchestra need to store plaintext versions to connect to the hosts? Maybe I'm missing something, but would appreciate some clarification, thanks.
-
@amp88 FWIW, there's an open issue on GH dealing with this.
-
@Danp said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
@amp88 FWIW, there's an open issue on GH dealing with this.
Ah, thanks for letting me know.
-
The easiest route would be to create a password on the archive itself, yes. Ping @julien-f that can answer all questions and put some context
-
@amp88 said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
Shouldn't the password hashes be stored in the .json file (as they appear to be for the users)? Does Xen Orchestra need to store plaintext versions to connect to the hosts?
No, server passwords cannot be saved as hashes like we do for users, the use cases are completely different:
- for users, the password cannot be retrieved from the hashes. However that's not an issue because, when a user logs in, its password is hashed and compared to the stored hash
- for servers, we need to send the password itself, not a derived hash to the XCP-ng/XenServer host
There is no way to securely hide these password except from encrypting them with a password provided by an external source, like a passphrase from the user, which may not be bad idea
-
@julien-f said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
@amp88 said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
Shouldn't the password hashes be stored in the .json file (as they appear to be for the users)? Does Xen Orchestra need to store plaintext versions to connect to the hosts?
No, server passwords cannot be saved as hashes like we do for users, the use cases are completely different:
- for users, the password cannot be retrieved from the hashes. However that's not an issue because, when a user logs in, its password is hashed and compared to the stored hash
- for servers, we need to send the password itself, not a derived hash to the XCP-ng/XenServer host
There is no way to securely hide these password except from encrypting them with a password provided by an external source, like a passphrase from the user, which may not be bad idea
OK, thanks for the explanation. Allowing the user the option to secure the exported configuration with a password would be a welcome addition
-
FYI, this feature has been released
-
Would it be "stupid" to use the hash of the user's (asking for the export) password to encrypt "by default" the export?
-
@julien-f said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
FYI, this feature has been released
Great, and thanks for letting me know
-
@Andre said in Exported Xen Orchestra Config Contains Plaintext Host Passwords - Is This Intentional?:
Would it be "stupid" to use the hash of the user's (asking for the export) password to encrypt "by default" the export?
No, because:
- XO does not the password of the user, just a hash
- The hash cannot be used because it can be regenerated for various reasons (e.g. a change of security settings such as the used algo)
-
-
J jeffmetal referenced this topic on
