Treat API key as secret and store them securely

[rkg-mm]

Team API keys should be treated as a secret and not stored in plaintext, instead stored as and compared against the hash. They should not be available on UI like currently in Dependency-Track, except once when generating them. Instead they should get a name and only the name be displayed in UI, to allow identify & delete them.

[mum-viadee]

As already stated in DependencyTrack/dependency-track#2552 the API keys should definitely treated more securely. They should be generated for user accounts, not for teams. Having api keys for teams seems to me like a wrong architectural decision. An API key should belong to a single user. This is helpful for auditing actions in Dependency Track. A user shoud be able to generate an API key for himself. There could be technical accounts like CI users that only have API keys and no password at all. Hence loging in on the gui with a technical account would not be possible.
Teams should, at least from an Dependency Track kind of view, only containers for handling permissions in an RBAC way.

[rkg-mm]

As already stated in DependencyTrack/dependency-track#2552 the API keys should definitely treated more securely. They should be generated for user accounts, not for teams. Having api keys for teams seems to me like a wrong architectural decision. An API key should belong to a single user. This is helpful for auditing actions in Dependency Track. A user shoud be able to generate an API key for himself. There could be technical accounts like CI users that only have API keys and no password at all. Hence loging in on the gui with a technical account would not be possible. Teams should, at least from an Dependency Track kind of view, only containers for handling permissions in an RBAC way.

I see your point but would disagree here. It would drastically increase the effort if I needed a special account (managed by our IT in Active Directory) for each team. With many teams I would have to request from our IT an account every time a new project is set up. Since the team is unable to gain access to the Key by themselves, I don't see a problem. Ideally it would be visible which API key is used to do an action in the logs, and naming the API keys would be helpful too. But then I see no further benefit from using a separate user.

[mum-viadee]

In order to use tools such as the Dependency Track in a regulated environment like a financial institute , it is essential that actions can be assigned to a single, specific user. How useful is an audit trail (see Dependency Track) if it says that someone from a team of 50 people has signed a vulnerability as a false positive? It is practically useless.
Users should be able to generate API keys themselves. Like in GitHub, for example. There is no need for an administrator to create keys for users. Administrators shouldn't even see plaintext api keys of users.

[rkg-mm]

What if it says the API key named "build server" of team X has done it?.

I agree with the plaintext keys, thats my original request.

[rkg-mm]

So your workflow would be

1. set up team
2. set up CI-User and add to team
3. login as CI-user and create API key
4. Configure CI build with API key?

[mum-viadee]

So your workflow would be

1. set up team

2. set up CI-User and add to team

3. login as CI-user and create API key

4. Configure CI build with API key?

Almost, Maybe an administrator could create this ci-user as a technical user without password, generate an api key and stores this key in the configuration of the CI-server. The api key should only be visible to the administrator once he created it.

[mum-viadee]

You just can't enforce non repudiation, if api keys are generated for teams.