VM Password reset - Unable to set Password Complexity requirement for Special Characters

[nxsbi]

ISSUE TYPE

• Bug Report

COMPONENT NAME

UI

CLOUDSTACK VERSION

4.17.0

CONFIGURATION

N/A

OS / ENVIRONMENT

SUMMARY

Unable to Set Password Complexity requirement to include special characters

STEPS TO REPRODUCE

Our organization wants to enforce password requirements upon password resets on the VM. The default password requirement is 6 characters. I have updated that to 14 characters using vm.password.length

However, there is no provision to enforce inclusion of select special characters (like !@#%^&*()-) -- exclude the $

Is there some way to achieve this?

EXPECTED RESULTS

Our organization wants to enforce password requirements upon password resets on the VM. The default password requirement is 6 characters. I have updated that to 14 characters using vm.password.length

However, there is no provision to enforce inclusion of select special characters (like !@#%^&*()-) -- exclude the $

Is there some way to achieve this? 

ACTUAL RESULTS

Password reset only includes numbers, upper and lower case

[DaanHoogland]

@nxsbi at the moment this is not possible. This is a new feature. You'll have to implement this if you need it. You can also alter the password generator for your need it.

[nxsbi]

Can you point me to where the code for this is? I would like to see if this is something I have skills to do…

[weizhouapache]

@nxsbi check generateRandomPassword in https://github.com/apache/cloudstack/blob/main/utils/src/main/java/com/cloud/utils/PasswordGenerator.java

it will be a small change I think

[sanjeev98kumar]

Will this be a good first issue to start with? I am looking for my first PR.

[DaanHoogland]

yes, it would @sanjeev98kumar , do you want me to assign it to you?

[sanjeev98kumar]

Yes

On Tue, Nov 8, 2022, 7:54 PM dahn @.***> wrote:

yes, it would @sanjeev98kumar https://github.com/sanjeev98kumar , do you want me to assign it to you?

— Reply to this email directly, view it on GitHub https://github.com/apache/cloudstack/issues/6861#issuecomment-1307303677, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3G47RJ45JYRPPENHZ42VXLWHJPDLANCNFSM6AAAAAARUJLCGY . You are receiving this because you were mentioned.Message ID: @.***>

-- The information contained in this electronic communication is intended solely for the individual(s) or entity to which it is addressed. It may contain proprietary, confidential and/or legally privileged information. Any review, retransmission, dissemination, printing, copying or other use of, or taking any action in reliance on the contents of this information by person(s) or entities other than the intended recipient is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us by responding to this email or telephone and immediately and permanently delete all copies of this message and any attachments from your system(s). The contents of this message do not necessarily represent the views or policies of BITS Pilani.

[DaanHoogland]

@nxsbi @sanjeev98kumar the related code is in PasswordGenerator. If you follow the flow from ResetVMPasswordCmd, it calls _mgr.generateRandomPassword() and will lead you to PasswordGenerator.generateRandomPassword(passwordLength);. In that method a pattern could be read from a global setting to be used. Let me know if you need more info.

[sanjeev98kumar]

@DaanHoogland please assign #6819 issue and unassign this issue #6861

[Pavan-Nambi]

hey @DaanHoogland should i update code here with some regex and add configValuesForValidation.add("vm.password.complexity") referring to config.java ?

i am not completely sure if this is how i should approach any assistance would be highly appreciated

thankyou!

[Pavan-Nambi]

and adding something like this static final ConfigKey<Integer> vmPasswordComplexity = new ConfigKey<Integer>("Advanced", Integer.class, "vm.password.complexity", "1", "Specifies the complexity of a randomly generated password", false); in this file and changing logic as suited in generateRandomPassword() will do?

[Pavan-Nambi]

apologies for pinging , I am bit new to open source(recently started exploring) and have never saw this much huge codebases so i am a bit overwhelmed

[DaanHoogland]

apologies for pinging , I am bit new to open source(recently started exploring) and have never saw this much huge codebases so i am a bit overwhelmed

@Pavan-Nambi that is all perfectly allright. I think you are asking the right questions.

About your implementation plan:

hey @DaanHoogland should i update code here with some regex and add configValuesForValidation.add("vm.password.complexity") referring to config.java ?

Do not add values to Config.java. the other file sounds much better.

static final ConfigKey<Integer> vmPasswordComplexity = new ConfigKey<>("Advanced", Integer.class, "vm.password.complexity", "1", "Specifies the complexity of a randomly generated password", false);

complexity as integer doesn´t sound right. Is this intended to be the length? The length is only one of the facets of the complexity of a password.

If you want implement a regex , I would make that a string configuration value.

For a PW usually a number of char sets is required/allowed and a length and for each of the sets, usually a minimum of one occurance is required. making an extreme example: one digit below 6 one digit above 5 one capital letter one lower case one of (,),[,],{,},<,> one of ,,.,!,?,:,; etc

I am not sure if this makes sense en whether it answers your question. You can create a PR we we can go from there, ask your questions there and others can suggest improvements until we consider it good for merge.

[DaanHoogland]

@Pavan-Nambi I assigned this issue to you. if you decide not to continue, please let us know.

[Pavan-Nambi]

apologies for pinging , I am bit new to open source(recently started exploring) and have never saw this much huge codebases so i am a bit overwhelmed

@Pavan-Nambi that is all perfectly allright. I think you are asking the right questions.

About your implementation plan:

hey @DaanHoogland should i update code here with some regex and add configValuesForValidation.add("vm.password.complexity") referring to config.java ?

Do not add values to Config.java. the other file sounds much better.

static final ConfigKey<Integer> vmPasswordComplexity = new ConfigKey<>("Advanced", Integer.class, "vm.password.complexity", "1", "Specifies the complexity of a randomly generated password", false);

complexity as integer doesn´t sound right. Is this intended to be the length? The length is only one of the facets of the complexity of a password.

Hey sorry for that yaa actually i copy pasted above line in file which is for length and just modified it to complexity for quick reference haven't checked it correctly ya gotcha integer doesn't make sense here , thanks for pointing it out!!

ok i will make a PR asap

thankyou for taking your time to explain!

[Pavan-Nambi]

@Pavan-Nambi I assigned this issue to you. if you decide not to continue, please let us know.

will do!

[JoaoJandre]

@DaanHoogland and @Pavan-Nambi, I think this is moving in the wrong direction; after reading @nxsbi 's request, they do not seem to want ACS to generate a strong random password. What they want is to force their users to comply with a password policy in their VM's passwords.

ACS's generated passwords are shown in the management server logs, they are also stored in plaintext on the database, in the job_result column of the async_job table; therefore, it is not a good practice to allow your users to keep these generated passwords, even if they are "strong" passwords. They (the passwords) are also stored in the VR in plain text, in the /var/cache/processed directory, in files with the pattern vm_password.json.*. Therefore, these passwords will always be subject to leak due to internal attacks (e.g. an admin that has access to the cloud infra)

Instead, @nxsbi could use cloud-init to configure the target OS to set a password policy; then, when users log in, they are forced to create a password and comply with the company's password policy.

Some of our clients use cloud-init to force their users to change their password as soon as they log into their VM's. To achieve this, one can (in Linux):

1. Access a VM with cloud-init.
2. Create a script file: sudo touch /var/lib/cloud/scripts/per-instance/reset_password.sh
3. Add the Linux command to expire the user's password:

   #!/bin/bash
   passwd --e <default-user>

4. Make the file executable: sudo chmod +x /var/lib/cloud/scripts/per-instance/reset_password.sh
5. Create a template based on this VM. All VMs created based on this template will force the user to change the password on their first login.

Furthermore, if you want to force the user to use some password policy, you should do something similar to that by setting in the operating system a password policy.

The same process shown above can be achieved for other operating systems. You just need to adapt the commands.

[Pavan-Nambi]

ohh oops so we should automate this process like using ansible or smthng? or this should be taken care manually by organisations if they need it..? @JoaoJandre

[weizhouapache]

ACS's generated passwords are shown in the management server logs, they are also stored in plaintext on the database, in the job_result column of the async_job table; therefore, it is not a good practice to allow your users to keep these generated passwords, even if they are "strong" passwords. They (the passwords) are also stored in the VR in plain text, in the /var/cache/processed directory, in files with the pattern vm_password.json.*. Therefore, these passwords will always be subject to leak due to internal attacks (e.g. an admin that has access to the cloud infra)

@JoaoJandre that's right. However, we cannot manage the password policy in guest os (virtual machines).

What cloudstack can manage are (1) the initial random password for new vms (2) the new random password when reset vm password and new password is not passed. (3) the user-defined new password when reset vm password

@Pavan-Nambi 's PR #7134 seems to address (1) and (2), which is good. The PR can be improved to address (3) as well.

[JoaoJandre]

ohh oops so we should automate this process like using ansible or smthng? or this should be taken care manually by organisations if they need it..? @JoaoJandre

I don't think this is within ACS's scope, as it interferes directly in the guest OS. This should be taken care by organisations if they need it. One solution to doing so is what I proposed.

ACS's generated passwords are shown in the management server logs, they are also stored in plaintext on the database, in the job_result column of the async_job table; therefore, it is not a good practice to allow your users to keep these generated passwords, even if they are "strong" passwords. They (the passwords) are also stored in the VR in plain text, in the /var/cache/processed directory, in files with the pattern vm_password.json.*. Therefore, these passwords will always be subject to leak due to internal attacks (e.g. an admin that has access to the cloud infra)

@JoaoJandre that's right. However, we cannot manage the password policy in guest os (virtual machines).

What cloudstack can manage are (1) the initial random password for new vms (2) the new random password when reset vm password and new password is not passed. (3) the user-defined new password when reset vm password

@Pavan-Nambi 's PR #7134 seems to address (1) and (2), which is good. The PR can be improved to address (3) as well.

Yes, I agree with you, but given my remarks, I don't think that making a stronger ACS generated password is actually useful. It will not make the VM safer if we consider internal attacks as possible attack vector in a threat model.

Furthermore, implementing something like this might mislead users into thinking that if they make a strong pattern they will be safer.

[weizhouapache]

ohh oops so we should automate this process like using ansible or smthng? or this should be taken care manually by organisations if they need it..? @JoaoJandre

I don't think this is within ACS's scope, as it interferes directly in the guest OS. This should be taken care by organisations if they need it. One solution to doing so is what I proposed.

ACS's generated passwords are shown in the management server logs, they are also stored in plaintext on the database, in the job_result column of the async_job table; therefore, it is not a good practice to allow your users to keep these generated passwords, even if they are "strong" passwords. They (the passwords) are also stored in the VR in plain text, in the /var/cache/processed directory, in files with the pattern vm_password.json.*. Therefore, these passwords will always be subject to leak due to internal attacks (e.g. an admin that has access to the cloud infra)

@JoaoJandre that's right. However, we cannot manage the password policy in guest os (virtual machines). What cloudstack can manage are (1) the initial random password for new vms (2) the new random password when reset vm password and new password is not passed. (3) the user-defined new password when reset vm password @Pavan-Nambi 's PR #7134 seems to address (1) and (2), which is good. The PR can be improved to address (3) as well.

Yes, I agree with you, but given my remarks, I don't think that making a stronger ACS generated password is actually useful. It will not make the VM safer if we consider internal attacks as possible attack vector in a threat model.

Furthermore, implementing something like this might mislead users into thinking that if they make a strong pattern they will be safer.

@JoaoJandre please note, the password is only visible for administrators (in cloudstack DB, logs, VRs, etc), not for everyone. Strong passwords may not provide strong security, but definitely better than weak passwords.

Masks can 'create a false sense of security', but they are still useful, right ?

[weizhouapache]

There is a related PR: #6947

[JoaoJandre]

Nonetheless, this will do nothing to fix the internal attack vector (if that is considered) and also it does not improve VM's password policy security. Defining a pattern for random passwords generated by ACS will not force users to improve those passwords when they change direction in the operating system. Therefore I still think this solution will not be that useful for the @nxsbi use case.

It is interesting to improve the security of random passwords by adding special characters. However, enabling users to define password "standards" to be managed by ACS will not do anything to improve end-users' password security in VM's operating system (they can always change in the VM, without going through ACS).

To make it clear, I do think that adding special characters to improve random passwords is an interesting addition. What I do not think is interesting is the "password pattern" definition, for random passwords generated. Furthermore, the way it is implemented, it can cause a few misunderstandings; (i) operators can think that these standards are somehow propagated to VM's operating system (which does not happen), and (ii) if the operator defines a quite complicated pattern, that loop might never end (it is a bit too simple solution, generate a random string, and then check if it matches the pattern, if it does not, repeat).

[weizhouapache]

@JoaoJandre you are mostly right.

However, reading through @nxsbi 's description, I think what he wants to improve is the random generated password when reset vm password. @Pavan-Nambi 's PR https://github.com/apache/cloudstack/pull/7134 can be improved to match his requirement.

@stephankruggg 's PR #6947 and #6863 can use the same check on the specified new password too.

[nvazquez]

I have removed the GSOC2023 label since there are work in progress PRs for this issue

[Pavan-Nambi]

This issue is open for new contributors/any new prs.