Security Suggestion: API Keys should be offered once

[Stephen.Schaff]

I always cringe a bit when I go to the API Keys page. All the keys are just shown for easy use. While nice from an ease of use point of view, it does not align with what I have seen in other products' API Key features.

I would like to offer this suggestion:

When an API Key is generated, clearly state that this is the ONLY time that key will be shown. From then on, it is differentiated only by its description.

When you go to store the API Key, you don't actually store it. You put it through a one way hash and then store the hashed value.

Then when an application calls Proget using the API key, you put it through the same hash and if the newly hashed value matches the stored hashed value, then access is granted.

This makes a security breach far less likely because:

1. You are not storing the API Keys. Any attack on the ProGet database does not breach any keys.
2. The keys are not re-shown in the UI, so screen scrapers or over the shoulder lookers are less likely to get the key.

(Reasoning: Password storing is a business that already has many products. Most companies have a system in place to keep their passwords safe. API Keys are basically usernames and passwords in one, and should be stored in a Keystore system.)

[stevedennis]

Hi @Stephen-Schaff ,

Thanks for the suggestion! So we had considered the "auto-generated one-time key" in our initial design, but decided against it for several reasons.

1. This enables the less-secure "API Key Spreadsheet Antipattern" - basically people want to store keys they generate -- and since the software doesn't allow it, they go this route. It's the same problem with "change your password every 30 days" policies that create easier-to-guess passwords.

2. This tends to create a lot of stale keys due to a fear to delete them. Administrators can "back-up" the API Keys if they can see them, and add-them back if cleaning up causes a problem.

3. Allowing keys to be entered allows users to more easily migrate from one instance to another - just do a DNS change, and all old automations /old keys will work fine.

API Keys are similar to passwords, but different; passwords are entered by a human to log-in, and in theory should only be "in that human's head" -- where as API Keys are always entered somewhere (usually in a script).

In general, in ProGet, we recommend keeping API Key as limited as possible. This simplifies things for everyone. There's no practical security problems in allowing all users to publish packages to feed.... you should be using package promotion to test/verify packages anyway.