Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create-for-rbac: deprecate '--password' #7538

Closed
yugangw-msft opened this issue Oct 10, 2018 · 9 comments

Comments

@yugangw-msft
Copy link
Contributor

@yugangw-msft yugangw-msft commented Oct 10, 2018

Per security team's suggestion, to avoid security leak caused by simple password, we will retire this argument and only use the password auto-gen option
For users with any objections/feedback, please comment here

@ppanyukov

This comment has been minimized.

Copy link

@ppanyukov ppanyukov commented Nov 22, 2018

Are you planning to retain az ad sp credential reset --password feature? If so then this suggestions is probably OK, otherwise I have a feeling this is going to break quite a few things for many. At least we do need to set explicit passwords in some cases using credential reset.

@yugangw-msft

This comment has been minimized.

Copy link
Contributor Author

@yugangw-msft yugangw-msft commented Nov 26, 2018

Are you planning to retain az ad sp credential reset --password feature

I will retain it, for the same reason you have stated

@varunsh-msft

This comment has been minimized.

Copy link
Member

@varunsh-msft varunsh-msft commented Dec 26, 2018

Hi @ppanyukov, Can you please share some scenarios where one may need to explicitly set passwords using credential reset? Just trying to understand the scenarios. By choosing passwords, users end up using well known/ commonly used passwords, and that leads to compromise of the service principal. OAuth credentials not intended for usage by human users are not typically chosen in other platforms either.

This is an excerpt from OAuth 2.0 Threat Model and Security Considerations
5.1.4.2.2. Use High Entropy for Secrets
When creating secrets not intended for usage by human users (e.g. client secrets or token handles), the authorization server should include a reasonable level of entropy in order to mitigate the risk of guessing attacks. The token value should be >=128 bits long and constructed from a cryptographically strong random or pseudo-random number sequence (see [RFC4086] for best current practice) generated
by the authorization server.

@yugangw-msft

This comment has been minimized.

Copy link
Contributor Author

@yugangw-msft yugangw-msft commented Jan 2, 2019

@varunsh-msft, the flow exists, that users can extend an existing password's expiration period longer instead of getting a new password. The reason is the old password might have been propagated to several scripts, and updating them across comes with some risks

@varunsh-msft

This comment has been minimized.

Copy link
Member

@varunsh-msft varunsh-msft commented Jan 4, 2019

In that case, is it possible to validate that the supplied password is a GUID? If one generated the password using Azure CLI, then it will be a GUID going forward. So, if they want to extend the expiration, they can supply the same GUID back. I am concerned that by allowing any password to be specified, one can specify easy to guess passwords.

@yugangw-msft

This comment has been minimized.

Copy link
Contributor Author

@yugangw-msft yugangw-msft commented Jan 4, 2019

Yes, we can sure validate the password is strong and even recommend strong ones on getting weak ones. With that, can we apply the same check on the creating scenario. Note, the create-for-rbac is a very very frequently used commands, so less breaking is always my preference.

@varunsh-msft

This comment has been minimized.

Copy link
Member

@varunsh-msft varunsh-msft commented Jan 4, 2019

No no, the creating scenario must not allow choosing a password :). Let us not go backwards. We already discussed that at length. Validating strength is not as good as unique random password per service principal. People can choose easy to guess passwords, even if they are strong, and then reuse them across the place. I also shared OAuth guidance that is to generate passwords.

I only suggested validation of GUID for reset scenario, since you wanted to allow extension of expiration.

@varunsh-msft

This comment has been minimized.

Copy link
Member

@varunsh-msft varunsh-msft commented Jan 4, 2019

Also do keep in mind that Azure Portal, PS az module, and Graph PS module do not allow choosing passwords in any of the scenarios. So, one can argue that even for reset scenario, Azure CLI should not be special, and increase risk to service principals.

@ppanyukov

This comment has been minimized.

Copy link

@ppanyukov ppanyukov commented Jan 7, 2019

Can you please share some scenarios where one may need to explicitly set passwords using credential reset?

@varunsh-msft : some that come to mind:

  • Automated continious Azure environment provisioning. We have scripts in bash/Azure CLI/ansible which set everything up and these can be re-run at any time. The logic of bits that deal with service principals is "create or update". Rather than extract the auto-generated password on the first create (which is fragile), we set it to a known value.

  • We zap/recreate entire environments often, especially in development. If SP passwords change every time we do so, this will break a lot of things that need to use the SP (like web apps or VSTS release pipelines for example) and they will need to be re-configured every time. So we set SP passwords to same values when we recreate environments.

We probably could adjust. The biggest concern with removing abiltiy to reset password to known value is that some things will definitely break, but it's very difficult to say what exactly and when. From my experiece, these things tend to break at the worst possible moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.