Outdated password hashing used (SHA1)

[niekbosch]

Vulnerability Details When using the core authentication driver, passwords are hashed using the SHA1 hashing algorithm. This is not considered secure for a long time now. During our security audit, this was considered one of the more important problems.

To Reproduce See the code in 'src/um/User.cc', line 346:

password = one_util::sha1_digest(passwd);

Version Completed for affected components

• Affected Component: Core authentication driver
• Hypervisor: n.a.
• OpenNebula Version: We run version 5.2.1, but I also found this in the latest master branch
• Browser: n.a.

Additional context Our security auditor gave this recommendation:

Use a hashing algorithm specifically designed for storing passwords like Argon2, PBKDF2, bcrypt or scrypt. More information can be found here: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Progress Status

• [ ] Branch created
• [ ] Code committed to development branch
• [ ] Testing - QA
• [ ] Documentation
• [ ] Release notes - resolved issues, compatibility, known issues
• [ ] Code committed to upstream release/hotfix branches
• [ ] Documentation committed to upstream release/hotfix branches

[niekbosch]

I appreciate the work, especially how there is no explicit database conversion needed.

However, although the move to sha256 improves hashing a bit, this is still not a very secure solution. The first problem I found with both this new implementation and the previous one, is that no salting is being used. You can revert a password back to its plain text format with a simple tool like this: https://crackstation.net/

With the above in mind, also remember that for some reason, you can look at your own password hash. What's more, group admins can also look at password hashes of all users in their groups. That's a considerable security risk, especially when combined with the above tool!

Furthermore, like I described in the original issue body, security auditors advise to use much stronger algorithms. This blog (first hit when googling 'is sha 256 secure') gives some more background: https://dusted.codes/sha-256-is-not-a-secure-password-hashing-algorithm

[rsmontero]

Thanks for the feedback @niekbosch !!!!

So yes you are right, the password driver was initially thought for trusted environments and rely on other auth drivers (x509, ssh keys...) when a stronger security is required.

Nevertheless I agree that OpenNebula could benefit from improving the password security. In order to address your both concerns, we can follow a unix approach:

1. Split the auth data, and move the passwords to a "shadow" table in the database that can be accessed only by oneadmin. Group admins will not have access to the shadow passwords
2. Add a salt to the passwords, again same way as UNIX

What do you think?

[jaypif]

Hi all,

I am also really interested by this concern as secure environment are really important. Currently, other auth drivers (x509, ssh keys, ...) are not supported when we want to use XML RPC calls. Only Servers (sunstone of EC2) are able to manage this. Is there a plan to support stronger secure method also for XML RPC ? That is a must have if you want to use Infra as Code tool via public interface.

Thank you

[al3xhh]

Hello @jaypif

The XMLRPC supports all authentication methods, for example CLI is using those authentication methods, it just matter of setting the token. Could you elaborate more on your case so we can see what we should do?

Thanks!

[jaypif]

Hello @al3xhh

That's a good news because I just read this page: http://docs.opennebula.org/5.8/deployment/authentication_setup/external_auth.html#how-should-i-read-this-chapter and it is not very explicit that x509 is also supported for API. Maybe the doc is outdated ?

Thank you

[al3xhh]

Yes, you are right @jaypif that is outdated, we will update it, thank you so much for noticing that!

[niekbosch]

Sorry for being quiet, this moved a bit below on my priority list.

I believe that best practices are:

• Using a secure password hashing algorithm, as described in the original description (ie. "Argon2, PBKDF2, bcrypt or scrypt"). I am pretty sure that there are standard libraries available that do just this. In my eyes, this would be a matter of not replacing SHA1 functions by SHA256 functions, but by PBKDF2 functions for example. I am not sure why SHA256 was chosen. I am no security expert and certainly not an encryption expert, but this is the general recommendation that we get. I believe these algorithms always, automatically use/require a salt.
  • No one should be able to retrieve a password field, not even a hashed password field. It is up to us, owners of an OpenNebula installation, to secure physical, network and database access properly, but OpenNebula should just not have this as an option in the software itself. If using a shadow table is what it needs, that could work. It actually does make sense in a certain way: for people not using the password driver, they do not need the additional field/fields in the core user table. However, it should also just be possible to not have a database query (and thus never an (API) response) that gets/returns the password field.

I believe the whole idea behind a readable password field was so you could use it to store an external identifier in case you use the 'proxy'. In that case, the password field in the database is not used, so it is available for other usage. And with a proxy authenticating the user, you often get an identifier (eg. through SAML) that you need to map to an OpenNebula user. However, to me, it feels like leakage of implementation details (the fact that you re-use a table field) at best. That fact that you have to use 'search password', where you actually want to 'search remote identifier' is a failure in abstracting away the implementation. And it is a security risk to use the password field, because of exactly this issue; people being able to read the hashed passwords.

Anyway, I don't want to sound to negative about the proposed solutions, I am just trying to follow best practices. I really do appreciate the time you take to investigate this issue.

Thanks for the feedback @niekbosch !!!!

So yes you are right, the password driver was initially thought for trusted environments and rely on other auth drivers (x509, ssh keys...) when a stronger security is required.

Nevertheless I agree that OpenNebula could benefit from improving the password security. In order to address your both concerns, we can follow a unix approach:

1. Split the auth data, and move the passwords to a "shadow" table in the database that can be accessed only by oneadmin. Group admins will not have access to the shadow passwords

2. Add a salt to the passwords, again same way as UNIX

What do you think?