Copied from comment on blog

OK. I seem to understand the changes you're making. Let's see the reasoning.

Making your API key on NuGet.org more secure is one more step in that direction.

Hmm. That's not much to go on. Let's assume the MO is "better security" since that seems to be the entirety of what the reason is.

I'll summarize by saying that a lot of people's concerns are due to the use of keys in automated environments. These environments that are supposed to be fully autonomous now require manual intervention every 90 days, or 4 times a year. This manual intervention is an action of privilege. Someone that has the nuget credentials must generate a new API key and update their configuration. Ironically, those that took the most trouble to secure and lock down their API key the most will likely have the most difficulty updating it. This change punishes those that were doing that, and drives a mentality of "well if it's going to change every 90 days I guess I won't worry about it too much". Those that encrypted it, locked down ACLs, etc, are now faced with a troublesome task.

Furthermore, those that did take care to lock things down may have done so in a way that the general ops / development team couldn't even do. Now, since we know the API key is going to expire, I might be inclined to open up the API key access so that anyone in ops / dev can update it, including sharing the nuget credentials used to make the API keys in the first place.

It's difficult to say whether or not this increases security without knowing what the risks are. A few that I can think of:

Leaked Access Key: This can either be unintentional, such as an accidental inclusion in a GitHub repository. It can also be "intentional" insomuch that the person intentionally committed it, not fully aware of the power it provides. In the former case, rotating keys helps marginally. Leaked keys are usually scraped in minutes, not days, because it's easy to automate. The latter can't really be helped. If they need to change it every 90 days, they'll just keep committing it in the open. In either case, this warrants immediate action, such as account suspension or revocation of all keys.

Staff turn over is another. A person may have taken a photo of it with their phone so they wouldn't have to look it up, written it down, etc. Ideally, an organization would immediately rotate the API key after the employee left. Changing every 90 days helps reduce the risk of the API key being in the open indefinitely. In this case, I agree that changing helps.

Since Let's Encrypt has been brought up, there is a good argument for 90 day certificates: it encourages people to completely automate the process. There is no such automation here, it's an entirely manual process that is error prone. Let's Encrypt cert-bot does all of the work for the user after a one-time initial registration.

Finally, there is the issue of choice. This will be entirely forced, without a concise explanation of what the security risks are.

Support Expiring API Keys #3092

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions