Hello, I agree that the use of clear passwords and the use of MD5 is not a secure option. I think it is important to be able to look for alternatives. Thank you very much for this post. If we look at the statistics shown, while there are 18,000 LIRs with MD5 and 3,000 of them only with MD5, the other 15,000 may have users for personal modification, but also (in relation to what Tore indicates), they may have IPAM tools or their own management systems for updating the data. I think it is important to set dates for manufacturers/developers to migrate from MD5/clear passwords to other options. In addition, it could be interesting to provide documentation to help this migration. The error messages that are answered should have as little impact as possible on the LIR systems/IPAM tools, mainly indicating that the modification could not be made. On the other hand, it might be interesting to apply other securitisation methods, such as the LIRs being able to specify source IP ranges for the update of the DB information, use of specific email addresses for each password/PGP/.... These methods could be implemented right now, regardless of the elimination of MD5/passwords. Regarding Tore's point about the use of passwords at LIR level, I think it is better for LIRs to have an identification of which user is doing the modification. In fact, there has been an effort to eliminate generic users in the LIR portal. However, the alternative of creating API keys at LIR level offers an easy migration alternative and leaves it up to the LIR to use them. kix -- Rodolfo García Peñas (kix) http://www.kix.es/ "I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart. On Thursday, September 19th, 2024 at 10:46, Tore Anderson <tore@fud.no> wrote:
* Edward Shryane
Introducing API Keys --------------------
In addition to the existing alternatives, we also propose to introduce API keys linked to an SSO account to replace passwords, that is convenient and secure.
An API key is an auto-generated string associated with a user account that can be used to authenticate updates on behalf of that user. They are already widely used across the Internet, although by different names (e.g. GitHub Tokens, Google Application Passwords, AWS does use API keys, etc.). Other RIPE NCC services already make use of API keys, for example the LIR Portal and RIPE Atlas.
We are investigating how to create a new service to allow RIPE NCC Access accounts to generate API keys that can be used to authenticate updates to the RIPE Database.
The advantages include: * RIPE NCC Access accounts are associated with a maintainer in the RIPE database and not any API keys, so there are no credentials that can be leaked. * API keys can be associated with a SSO account, so there is accountability to identify who authenticated an update. * We can automatically expire API keys after a certain time limit for increased security, in case they are leaked. * Users can more easily migrate away from passwords as API keys can be used in the same way.
Hi Ed,
I'm very supportive of the idea of being able to use API keys to maintain the RIPE database content. However, I'd like to point out a fundamental difference between MD5 passwords and the API key implementation you outline, namely that the MD5 passwords are per maintainer while the API keys are per user account.
This means that they cannot actually be used in the same way, because a maintainer password will keep working even as LIR staff rotate, but a user's API key will not.
This in turn makes the API keys unsuitable for use by automated systems (e.g., integration with an IPAM system), as one certainly do not want those to stop working simply because the person who created the API key in the first place quit the company and had their user account deleted.
To remedy this I suggest that you make it possible to create API keys on the LIR account level as well, i.e., independent of individual user accounts.
Tore
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/