Bug #2080

Documentation: Add a note about Symmetric Key (server_cipher) security

Added by Simon Boulet about 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:05/23/2013
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:Documentation
Target version:Release 4.4
Resolution:fixed Pull request:
Affected Versions:OpenNebula 4.0

Description

Here: http://opennebula.org/documentation:rel4.0:cloud_auth

I suggest adding a note about the Symmetric Key (server_cipher) security. The scheme used by this authentication is weak and doesn't protect against any password attack methods. One should encrypt all communications using SSL (and enforce SSL certificates checking) when running the frontend (ex. Sunstone) and the core (oned) on different servers.

Simon

History

#1 Updated by Tino Vázquez about 8 years ago

  • Status changed from Pending to New

#2 Updated by Simon Boulet about 8 years ago

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.

#3 Updated by Ruben S. Montero about 8 years ago

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.

#4 Updated by Carlos Martín almost 8 years ago

  • Category set to Documentation

#5 Updated by Ruben S. Montero almost 8 years ago

  • Target version set to Release 4.4

#6 Updated by Daniel Molina over 7 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
  • Resolution set to fixed

In this guide http://opennebula.org/documentation:rel4.4:cloud_auth there is a reference to the x509 server auth:

You can strengthen the security of the requests from the servers to the core daemon changing the serveruser's driver to server_x509. This is specially relevant if you are running your server in a machine other than the frontend

Also available in: Atom PDF