OpenNebula

Also I have found that the middle attribute (the username to impersonate) in the token doesn't seems to be enforced. You can set this to any valid string.

An empty middle attribute in the token:

token=serveradmin::token-expiry-time
authstring=serveradmin:user1:encrypted-token

Also it is perfectly valid to reuse the encrypted token (as long as timestamp is not expired) to impersonate another user. Impersonating oneadmin with a token generated with user test1:

token=serveradmin:test1:token-expiry-time
authstring=serveradmin:oneadmin:encrypted-token

Same for:

token=serveradmin:random-string:token-expiry-time
authstring=serveradmin:oneadmin:encrypted-token

Also, as I said earlier the cryptography used for generating the token is weak and shouldn't be used for plain-text communications.

Hi

About the authstring structure ("server_user:target_user:token") with token being encrypted "server_user:target_user:expire":

• The first target_user is used by OpenNebula core to get the user structure. The token target_user is not used by the core nor the driver. It is used as "salt", so tokens are different for the same user (different expire times) and for the same time (different target_users).

• I'd say that the security of the token it self is not weak, as it should be hard enough to break the service account password and generate fake tokens.

Regarding the communication channel, it is assumed to be secure, if the token is captured it can be reused (that's the reason to use the expire time). We could also check the target_user in the token and the authstring. So if the token is compromised only one account will be compromised.

Note that it is the same (even worse) for the XML-RPC channel; if the authstring is compromised it can be reused (without expire time). If oned is running in a host different of that used by any client tool (CLI, suntone,...) it should be proxy'ed through SSL.