Hi Tore,
On 19 Sep 2024, at 13:13, Tore Anderson <tore@fud.no> wrote:
* Edward Shryane
However, if someone leaves a company, any credentials they had knowledge of should be changed. They should not have continued access to make updates on behalf of the company.
Hi again Ed,
This is also true for PGP keys and X.509 certificates. If the policy going forward is that all database updates should be traceable to a specific individual user account, these authentication methods would also need to be retired, at least if you care about consistency.
You are correct, PGP keys and X.509m certificates are not tied to an individual (also MD5 hashed passwords), and it is not an explicit policy to make updates traceable to an individual. However, if we agree that it's a good practice not to share the authentication method (any method) as you get accountability for changes, then per-user API keys supports that. It is also less likely that a key will be compromised if it's known only by one individual, this is true for API keys as well the alternatives.
That said, for all of these the (ex-)employees are not expected to retain a copy of the secret material, be it an API key, a private PGP key, or a X.509 RSA key. The secret typically gets copied into the system that needs it right after it was created, and then promptly forgotten by the employee.
You can guarantee this by removing the SSO user from your maintainer, that any of their API keys can't be used to authenticate as that maintainer. With the alternatives, you must remove the credentials themselves from the maintainer.
It's of course fine if an organisation has a policy to change every single secret their employees have ever been in contact with every time an employee leaves just to be on the safe side, but I don't think it is something the RIPE NCC should enforce for every LIR.
Agree it's not someting the RIPE NCC should enforce, but it is a good practice and the API key design should make that as easy as possible. Regards Ed Shryane RIPE NCC