Impact Analysis of Removing MD5 Hashed Passwords from the RIPE Database
Dear colleagues, At RIPE 88 during the DB-WG session, I mentioned the need to replace MD5 hashed passwords that are used for authenticating updates in the RIPE Database. Now I’d like to present an impact analysis of doing this, what the alternatives are, and a draft migration plan. Please let me know your feedback. I plan to finalise the contents and present at RIPE 89 next month. Regards Ed Shryane RIPE NCC --- Introduction ------------ In the RIPE Database, some maintainers contain passwords which are protected using the MD5 hash algorithm. However MD5 has been found to have vulnerabilities which make it unsuitable for continued use. Accordingly the RIPE NCC plans to soon phase out the use of MD5 hashed passwords. We describe some alternatives, and a migration plan to deprecate passwords. Why Not Switch to a Stronger Hash Algorithm? -------------------------------------------- Stronger cryptographic hash algorithms exist, but we do not want to simply replace MD5 with a different hash algorithm. If a hash is compromised it would still need to be replaced, so the risks of exposure remain, regardless of the hash algorithm used. It is better to completely remove all password hashes from maintainer objects, so they are no longer part of the RIPE Database. Alternatives to Passwords ------------------------- In order to successfully migrate away from MD5 hashed passwords, we must also ensure that there are viable alternatives, in particular for non-interactive updates. What Alternatives Already Exist? -------------------------------- A number of alternative authentication methods are already available in the RIPE Database: * SSO (Single Sign-On). A user registers a RIPE NCC Access account and associates it with their maintainer. * Over 80% of maintainers already contain an SSO account for authentication. * SSO is an adequate replacement for passwords for interactive updates. * However SSO can only be used interactively (through the RIPE Database website), and not for batch (non-interactive) updates. * PGP can be used to authenticate updates using a signature. * There is no shared secret between the client and server, unlike with passwords. * However PGP can only be used in Syncupdates or Mailupdates, not with the REST API. * PGP signatures were used to authenticate 33% of all successful updates in the past year, but only 6% of all maintainers reference a PGP key, so it is not a widely used solution. * X-509 Certificates can also be used to authenticate updates * Use S/MIME to create a signed mailupdate message * Use Client Certificate authentication with the REST API. * X.509 signed updates were only used in a handful of updates in the past year. Only 29 maintainers reference an X.509 certificate. This means that alternatives to passwords for non-interactive (batch) updates are not widely used. In order to completely replace passwords there must be a usable alternative. 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. Deprecating Insecure Transport of Credentials --------------------------------------------- In addition to deprecating MD5 hashed passwords, we also plan to deprecate any insecure ways of transporting credentials, so that updates are kept secure. Using Mailupdates with password authentication can be insecure, as the mail message may be sent unencrypted, or the message may be spooled to disk during transport, so could be leaked. We found that 16% of successful Mailupdates contained a password. We will no longer allow Mailupdates using a password and only allow an X.509 or PGP signature for authentication. Using Syncupdates over plaintext HTTP with a password can be insecure. We found that 3% of total successful Syncupdates requests over HTTP used a password. Currently a warning is returned if this happens. We will no longer allow HTTP and only allow Syncupdates over HTTPS using an API key or a PGP signature for authentication. Password authentication of Whois REST API queries and updates already require HTTPS, and in the future it will be possible to authenticate using API keys, in addition to client certificate authentication. How Are Updates Performed? -------------------------- In the past 12 months (July 2023 to June 2024 inclusive), there were 4.3 million successful updates to the RIPE Database in total. +-------------+-------------------+-----------------------+ | | Number of Updates | Percentage of Updates | +-------------+-------------------+-----------------------+ | REST API | 2.4M | 56% | | Syncupdates | 1.0M | 24% | | Mailupdates | 0.88M | 20% | | TOTAL | 4.3M | (100%) | +-------------+-------------------+-----------------------+ Looking at the authentication method used for each protocol: +-------------+----------+-----+-----+ | | Password | SSO | PGP | +-------------+----------+-----+-----+ | REST API | 76% | 24% | N/A | | Syncupdates | 16% | 16% | 68% | | Mailupdates | 16% | N/A | 84% | | TOTAL | 50% | 17% | 33% | +-------------+----------+-----+-----+ Passwords were used in half of all successful updates (2.15M out of 4.3M) in the past year. How Many Maintainers Use Password Authentication? ------------------------------------------------- There are approximately 62,000 maintainers in the RIPE database. About 18,000 maintainers have MD5 hashed passwords. About 3,000 of those maintainers only have MD5 hashed passwords and no alternative authentication method. So most maintainers don’t use passwords, and most of those that do have at least one alternative. Any maintainers using passwords will soon need to migrate to an alternative. As mentioned already, 18,000 maintainers contain at least one MD5 hashed password. About half of all updates in the past year were authenticated with a password, but these were submitted by only 1,362 maintainers. There are about 3,000 maintainers that only have an MD5-PW auth: attribute. Only 872 of those maintainers made a successful update in the past year. It may seem that deprecating passwords will be a tall order. However, we found that only a minority of maintainers use them regularly. How Many Maintainers Use an Alternative Authentication Method? -------------------------------------------------------------- There are 51,000 maintainers containing at least one RIPE NCC Access account (SSO). In the past year, we found that 23,000 maintainers authenticated using SSO, by far the most of any authentication method. There are about 4,000 maintainers which reference a PGP key-cert that is not expired. One third of all updates are authenticated with a PGP signed message, but these were submitted by only 477 maintainers. There are only 29 maintainers which reference an X.509 key-cert that is not expired. There are only a handful of updates authenticated using an X.509 certificate each year. Migration Plan To Deprecate Passwords ------------------------------------- Firstly, existing maintainers do not need to wait for any migration away from MD5 hashed passwords as they can be replaced already. If you only perform updates interactively through the RIPE database website, then you can rely on SSO authentication. If you perform batch updates, you can switch to PGP signed updates or client certificate authentication. Following is an outline of how we can migrate away from passwords. We ask the DB-WG community for their feedback and suggestions, and will update the migration plan accordingly. In the coming months, we plan to first phase out any insecure ways of transporting credentials in Mailupdates and Syncupdates, namely: * Stop allowing passwords in Mailupdates. Any mailupdates requests containing only password authentication will fail with an error. Users must switch to PGP signed mailupdates or use the REST API or Syncupdates. * Stop allowing HTTP for Syncupdates. Any Syncupdates requests over HTTP will fail with a 403 Forbidden response. Users must switch to HTTPS. We will notify the DB-WG and affected maintainers in advance of any changes. Once the design is ready and approved, we will introduce API keys alongside password authentication as an alternative for non-interactive updates. Finally we will begin to deprecate passwords as follows: * Encourage maintainers using passwords to switch to an alternative * Stop allowing new passwords to be added to a maintainer * Set an expiration date for existing passwords * Remove passwords automatically from maintainers once they have expired We will plan together with the DB-WG and notify affected maintainers in advance of any changes. The details and timing are to be agreed with the DB-WG. Impact Analysis --------------- What is the impact on RIPE NCC services of removing MD5 hashed passwords in the RIPE Database? RIPE Database Queries Deprecating MD5 hashed passwords will have little impact on queries to the RIPE Database, except for authenticated queries for a MNTNER object. In that case, a password will no longer be allowed for authentication when querying for an unfiltered MNTNER object, and unfiltered MNTNER objects will no longer contain any password hashes. An existing alternative to using password authentication for authenticated queries is client certificate authentication, and in the future API keys will be provided as an additional alternative. RIPE Database Updates Passwords will no longer be allowed when using any RIPE Database update interface. For the Whois REST API, passwords will be replaced by client certificate authentication and API keys. Affected maintainers will need to migrate to an alternative. HTTPS is already required for updates. For Mailupdates, password authentication will no longer be allowed. Affected maintainers will need to migrate to signed updates or use an alternative transport. For Syncupdates, HTTP will no longer be allowed and passwords will be replaced by signed updates or API keys. Affected maintainers will also need to migrate. New Member Signup No impact to New Member Signup, as new LIRs are not asked for a password during the process. All LIR contacts are added as SSO accounts to the newly created maintainer during LIR activation. However, users can still add a password themselves to authenticate updates. LIR Portal There is no impact to interactive users of the LIR Portal, as authentication of changes in the RIPE Database (e.g. Set Default Maintainer) is done using their SSO account credentials. There is no impact to the API Keys feature in the LIR Portal, as these requests are not authenticated with a password. TEST Environment Currently in the TEST environment we depend on a “well-known” maintainer password to authenticate changes normally performed by the RIPE NCC. This will be changed to allow a user to make changes (e.g. setup test data) without a password. However we need to consider how to allow this while also keeping the authentication model consistent with the RIPE Database. RIPE Database Associate Certification When a user signs up to the RIPE Database Associate certification course, we provide them with resources and a user maintainer with a password. In future, a user will use their SSO account credentials to create and update their objects in the database. Training Courses The training materials used in RIPE NCC courses will have to change to account for API keys. Also we will encourage use of other alternatives such as signed updates and client certificate authentication. (END)
Edward Shryane wrote on 18/09/2024 17:39:
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.
API keys would be good and it would be great to see them supported. That said, API keys are plain-text passwords, stored in plain-text on each side. They just happen to be a bit longer than login passwords, and can be implemented to have a more limited authorisation scope, that's all. So when you're implementing them, can you implement mandatory expiry periods, ala github? Nick
Hi Nick,
On 18 Sep 2024, at 17:46, Nick Hilliard <nick@foobar.org> wrote:
Edward Shryane wrote on 18/09/2024 17:39:
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.
API keys would be good and it would be great to see them supported.
That said, API keys are plain-text passwords, stored in plain-text on each side. They just happen to be a bit longer than login passwords, and can be implemented to have a more limited authorisation scope, that's all.
Thanks for your feedback. We plan to implement API keys as part of RIPE NCC access and not in the RIPE database, to allow other NCC services to use the same feature, and keep credentials out of the RIPE database. We will store API keys hashed and not plain-text on the server side. Indeed they must be protected on the client side like a password. Indeed we plan to allow API keys to be limited in scope.
So when you're implementing them, can you implement mandatory expiry periods, ala github?
Nick
Features are not final yet as we are discussing internally. Indeed a mandatory expiry period does seem to be an industry best practice for API keys. We need to keep in mind some implications of automatically expiring API keys, e.g. * We should allow a sufficiently long expiry that it doesn't impose a high burden to manually replace keys, balanced against the risk of a key being compromised. * If we don't sufficiently notify users in advance, they may not rotate their key in time, causing automated updates to fail. We plan to warn users by email and in Whois update notification responses. * If we migrate a group of maintainers from passwords to API keys around the same time, it's likely they will expire at the same time. There may be a spike in support requests to help rotate them. However, an expiring key doesn't lock a user out of their RIPE NCC access account, they will still be able to make updates interactively and generate a new API key themselves. Regards Ed Shryane RIPE NCC
* 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
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/
Hi, I'm in support of switching/adding API keys to this but would not prefer to have them forcefully expire and having to replace them. I would propose a split option: - API key *without* IP/subnet limitation that expires every year - API key *with* IP/subnet access limitation that does not expire Regards, Wessel
Hi Wessel,
On 19 Sep 2024, at 11:36, Wessel Sandkuijl <wsandkuijl@prefixbroker.com> wrote:
Hi,
I'm in support of switching/adding API keys to this but would not prefer to have them forcefully expire and having to replace them. I would propose a split option:
- API key *without* IP/subnet limitation that expires every year - API key *with* IP/subnet access limitation that does not expire
Regards,
Wessel
Thanks for your feedback, I will discuss this option internally and reply to you and the WG with the outcome. Regards Ed Shryane RIPE NCC
Hi Rodolfo,
On 19 Sep 2024, at 11:30, Rodolfo García Peñas (kix) <kix@kix.es> wrote:
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.
Thanks for your feedback!
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.
I agree that we need to allow enough time in the migration plan for everyone to move to other options. The existing alternatives for automated updates are PGP signed messages and client certificate authentication, these are both in the DB documentation. Once we introduce the planned alternative of API keys we will document that also. We will also update related training courses and support individual users directly. We have a clear goal of making this transition as straightforward as possible.
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.
We plan to add features when generating API keys to restrict the scope in different ways, e.g. specific maintainers, source IP ranges etc. although the priority is to deprecate MD5 as soon as possible.
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.
I agree it's important to identify which user was responsible for making changes. Hopefully API keys provides this and is usable by LIRs. We will review any use cases not supported by the switch to (per-user) API keys. Regards Ed Shryane RIPE NCC
Hi, On Thu, Sep 19, 2024 at 09:30:58AM +0000, Rodolfo García Peñas (kix) wrote:
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.
please re-read what Tore wrote. You can not have *automated* updates fail because a *person* left the LIR in question. Tying automated updates to a specific person account is not a robust way to automate things. So I second the wish to be able to create API keys that are tied to a LIR account, but not to a person. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On jue, 19 sep 2024, Gert Doering escribió:
Hi,
On Thu, Sep 19, 2024 at 09:30:58AM +0000, Rodolfo García Peñas (kix) wrote:
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.
please re-read what Tore wrote. You can not have *automated* updates fail because a *person* left the LIR in question.
Hi Gert, I was thinking that certain users would not be personal users, but specific users for these actions. Something like auto-dbm@ripe.net. These users could have a mailbox associated with them, e.g. for change notifications etc. But I understand that this could be something that depends on each LIR and that the option suggested by Tore could be correct. On the other hand, a LIR may have multiple systems for updating database information, so if authentication is implemented at the LIR level, it would be advisable to allow multiple keys.
Tying automated updates to a specific person account is not a robust way to automate things. So I second the wish to be able to create API keys that are tied to a LIR account, but not to a person.
Many UNIX daemons and other operating systems are associated with non-personal accounts. This is the same idea. kix -- 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.
Hi Tore, Thanks for your feedback.
On 19 Sep 2024, at 10:46, Tore Anderson <tore@fud.no> wrote:
... 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.
Correct, MD5 hashed passwords can be shared, and API keys are intended to be created and used by a singe user.
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.
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. Once a users SSO account is removed from a maintainer, any associated API keys will no longer authenticate changes as that maintainer. If IPAM integration stop working, it must be straightforward to identify the cause and solution (i.e. that API key no longer works, generate a new one).
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
We will review any use cases not supported by the switch to API keys. We want to make the migration away from passwords as straightforward as possible. Regards Ed Shryane RIPE NCC
Hello, On 9/19/24 12:33 PM, Edward Shryane wrote:
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. If IPAM integration stop working, it must be straightforward to identify the cause and solution (i.e. that API key no longer works, generate a new one).
That's typical "developer's" reaction... make it someone else's problem. But there's another reason why it's better to have the API keys associated with the organization and not with individual accounts. In case of key compromise, it needs to be invalidated as quickly as possible. Anyone from the organization must be able to do this. From the point of view of the organization, it is very important to see ALL active keys. And not to think about whether a specific user generated an API key or not. NIS2 makes this even more critical for many organizations. Yes, this can be somewhat circumvented by organization shared account. But that's not the best solution from a security point of view. But this still won't solve the problem that other user will generate a key for himself as well. Sure, we try to graft new things onto the really old database. But the maintainer object should be a I think associated with the organization, company. Not with a person. It's not that easy with SSO authorization (like webupdates), but that's easy with API keys. This just wants to change perspective and not try to tie everything to a person. Security cannot really be solved by saying "and that's your problem". So I support idea of having API keys linked with organisation. From a security point of view, it will be more transparent. - Daniel
Hi Daniel, Thanks for your feedback,
On 19 Sep 2024, at 13:00, Daniel Suchy via db-wg <db-wg@ripe.net> wrote:
Hello,
On 9/19/24 12:33 PM, Edward Shryane wrote:
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. If IPAM integration stop working, it must be straightforward to identify the cause and solution (i.e. that API key no longer works, generate a new one).
That's typical "developer's" reaction... make it someone else's problem.
If the IPAM system stops working, it must be clear what caused it, so it can be fixed, regardless of the reason.
But there's another reason why it's better to have the API keys associated with the organization and not with individual accounts.
In case of key compromise, it needs to be invalidated as quickly as possible. Anyone from the organization must be able to do this. From the point of view of the organization, it is very important to see ALL active keys. And not to think about whether a specific user generated an API key or not. NIS2 makes this even more critical for many organizations.
Any administrator can already remove an SSO user from their maintainer if they are suspected to be compromised. Per-organisation keys are harder to control as more than one person can know what they are. It is more difficult to identify who made changes if you have a shared key. Also, if someone leaves the organisation you should invalidate *all* keys that they had knowledge of, rather than the per-user model where you can just remove the user. How do you share per-organisation keys securely? If we display a list of all active keys, then we must keep the plaintext keys on the server-side, which increases the risk of exposure for the RIPE NCC and the organisation. It's good practice when generating a key for a user to only display it once, and then store only the hashed version on the server side. It's the users responsibility to keep it secret. It is possible with the per-user API key model to display a summary of API keys for all users and when they were last used. You can manage users instead of knowing about individual keys.
Yes, this can be somewhat circumvented by organization shared account. But that's not the best solution from a security point of view. But this still won't solve the problem that other user will generate a key for himself as well.
Shared credentials are a security risk, as you don't know who made changes, it is harder to know when they have been compromised. The API key should be known only to the SSO user, that is how they authenticate themselves (the same as their password and 2FA is known only to them), and kept separate from their role (their authorisation to act on behalf of the organisation).
Sure, we try to graft new things onto the really old database. But the maintainer object should be a I think associated with the organization, company. Not with a person. It's not that easy with SSO authorization (like webupdates), but that's easy with API keys. This just wants to change perspective and not try to tie everything to a person.
The authentication part (i.e. the user identifies themselves via an SSO session or API key) should be kept separate from the authorisation part (i.e. this user is allowed to make changes on behalf of our organisation). These two concepts are conflated in the RIPE database model but should be separate (and can be, with SSO accounts and API keys to identify the user).
Security cannot really be solved by saying "and that's your problem".
So I support idea of having API keys linked with organisation. From a security point of view, it will be more transparent.
- Daniel
Thanks again for your feedback. I will discuss your proposal internally to see if we can improve the design (the features of API keys have not been finalised yet). Regards Ed Shryane RIPE NCC
Edward Shryane wrote:
How do you share per-organisation keys securely? If we display a list of all active keys, then we must keep the plaintext keys on the server-side, which increases the risk of exposure for the RIPE NCC and the organisation. It's good practice when generating a key for a user to only display it once, and then store only the hashed version on the server side. It's the users responsibility to keep it secret.
It is possible with the per-user API key model to display a summary of API keys for all users and when they were last used. You can manage users instead of knowing about individual keys.
You don't need to show the full API key to identify it. An API key is, by definition, an opaque string. Thus you are allowed to store extra information there. For instance, an API key could be: RIPE-APIKEY-66F87CB1-af970283c7cdb9c402afe8be2b4f1d107 Where "RIPE-APIKEY-" doesn't provide any security at all, "66F87CB1" is actually an internal identifier for this specific API key, and af970283c7cdb9c402afe8be2b4f1d107 the actual random secret that you salt and hash. You could then list it as: RIPE-APIKEY-66F87CB1-… Not compromising the security of the API key at all. if it is a LIR-level API key, other org members (and ideally also the creator itself) can view that this API key exists, but not the full key. And I think that you *do* want to use an schema similar to this, not just showing a label, so that you can univocally identify the key on all kind of logs, not just with a user-defined label that can be repeated (I suppose that, even without considering a malicious user reusing a label on purpose, many entries will have a label of '', 'api', etc). Regards -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
* 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. 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. 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. Tore
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
Hi Ed, WG, [speaking as myself, not co-chair] In general I like this. I'll let others discuss their very valid points, but I want to bring up another. In the "Notification of RIPE Database changes" emails, I'd love to see an identifier of who and how made the change. Their user account if it's an SSO, a marker says "MD5" if it's a hashed password. the PGP key id if it's signed, etc, etc. And in the future, an identifier for which API key or any type of auth so we can internally identify who made the change. Of course, these identifiers would need to be visible to the admins of a mntner object. IMHO, this would help admins be able to trace which keys are actively in use and be able to fix their internal processes. I'm looking at a notify email that was sent to us 8 minutes ago, and it does identify the IP address, but not which auth method was used. -peter On 2024 Sep 18 (Wed) at 17:39:14 +0200 (+0200), Edward Shryane wrote: :Dear colleagues, : :At RIPE 88 during the DB-WG session, I mentioned the need to replace MD5 hashed passwords that are used for authenticating updates in the RIPE Database. Now I’d like to present an impact analysis of doing this, what the alternatives are, and a draft migration plan. : :Please let me know your feedback. I plan to finalise the contents and present at RIPE 89 next month. : :Regards :Ed Shryane :RIPE NCC
Hi Peter,
On 19 Sep 2024, at 15:34, Peter Hessler <phessler@theapt.org> wrote:
Hi Ed, WG,
[speaking as myself, not co-chair]
In general I like this.
Thank you.
I'll let others discuss their very valid points, but I want to bring up another. In the "Notification of RIPE Database changes" emails, I'd love to see an identifier of who and how made the change. Their user account if it's an SSO, a marker says "MD5" if it's a hashed password. the PGP key id if it's signed, etc, etc.
We already do this if the update is authenticated by SSO or PGP, but not by MD5. We can additionally add "MD5" until it's deprecated, if the DB-WG has no objection ? For example, I see "Changed by SSO account: eshryane@ripe.net" in some update notifications I received this morning when testing the 1.114 release.
And in the future, an identifier for which API key or any type of auth so we can internally identify who made the change. Of course, these identifiers would need to be visible to the admins of a mntner object.
It may be a security risk to reveal information about the API key itself (I will check this internally), but we could return the name of it as defined by the user themselves? At least we can identify which SSO user authenticated the update (either interactively or via an API key).
IMHO, this would help admins be able to trace which keys are actively in use and be able to fix their internal processes.
API keys should not be shared but we can investigate how to identify to which SSO account an API key belongs.
I'm looking at a notify email that was sent to us 8 minutes ago, and it does identify the IP address, but not which auth method was used.
Perhaps the update was authenticated with a password? Regards Ed Shryane RIPE NCC
Hi, On Thu, Sep 19, 2024 at 03:34:43PM +0200, Peter Hessler wrote:
I'll let others discuss their very valid points, but I want to bring up another. In the "Notification of RIPE Database changes" emails, I'd love to see an identifier of who and how made the change. Their user account if it's an SSO, a marker says "MD5" if it's a hashed password. the PGP key id if it's signed, etc, etc. And in the future, an identifier for which API key or any type of auth so we can internally identify who made the change. Of course, these identifiers would need to be visible to the admins of a mntner object.
Indeed. So in the discussion with Tore, Ed said "we're storing the API keys hashed, so we can not show you which keys are active" - solved by a label, done. Show the API key labels in the portal, include the API key label in all relevant notification mails (updates and "expires soon"). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear colleagues, Thank you all for your feedback so far, it is very helpful. I will attempt to summarise as follows (please correct me as necessary): (1) There is a strong preference for shared credentials at the LIR account level, independent of individual users. If a user leaves the company, the shared credential should not automatically expire. The organisation must be able to maintain the API keys including listing and invalidating them. (2) Include scope(s) when creating an API key, such as limiting the source IP ranges. (3) Include API key expiry. Allow API keys to optionally expire, depending on the scope. (4) Make sure there is comprehensive documentation for API keys to help with adoption. I will discuss internally how we can accommodate your feedback and how it affects the migration plan away from MD5 hashed passwords. Regards Ed Shryane RIPE NCC
On 18 Sep 2024, at 17:39, Edward Shryane <eshryane@ripe.net> wrote:
Dear colleagues,
At RIPE 88 during the DB-WG session, I mentioned the need to replace MD5 hashed passwords that are used for authenticating updates in the RIPE Database. Now I’d like to present an impact analysis of doing this, what the alternatives are, and a draft migration plan.
Please let me know your feedback. I plan to finalise the contents and present at RIPE 89 next month.
Regards Ed Shryane RIPE NCC
Edward Shryane wrote on 20/09/2024 09:45:
(1) There is a strong preference for shared credentials at the LIR account level, independent of individual users. If a user leaves the company, the shared credential should not automatically expire. The organisation must be able to maintain the API keys including listing and invalidating them.
this is often implemented using "system" accounts with privileges limited to API access. Nick
Hi Ed,
(1) There is a strong preference for shared credentials at the LIR account level, independent of individual users. If a user leaves the company, the shared credential should not automatically expire. The organisation must be able to maintain the API keys including listing and invalidating them.
Hi Ed, To be clear, I do not see this as an either/or - having the option for creating API keys both at the LIR level *and* at the user level would be ideal, in my opinion. You could of course take the LIR level idea even further, by adding functionality such as (from the top of my head): * Making the creation of LIR-level API keys an optional privilege that only certain users would be permitted to perform * Keeping track of which user created the LIR-level API keys, and giving the option of deleting (some of) them when the user that created them is being deleted * Having the LIR-level API key concept apply not only to the RIPE database updates, but for all RIPE NCC services for which API keys can be used Tore
Tore Anderson wrote on 20/09/2024 12:34:
To be clear, I do not see this as an either/or - having the option for creating API keys both at the LIR level *and* at the user level would be ideal, in my opinion.
In theory that would be nice, but in practice sounds like it would mean adding an extra layer into the authentication model for LIR authentication, in addition to the existing account-based authentication system. Keeping a single layer via using an api-only account would normally keep the architectural model cleaner. But: keeping the architectural model simpler isn't the same as keeping the implementation model easier. Not wanting to back-seat drive or anything, but I'm a major fan of maintainable codebases. Nick
Hi Ed, On 18 Sep 2024, at 17:39, Edward Shryane wrote:
At RIPE 88 during the DB-WG session, I mentioned the need to replace MD5 hashed passwords that are used for authenticating updates in the RIPE Database. Now I’d like to present an impact analysis of doing this, what the alternatives are, and a draft migration plan. […]
Thanks for addressing this. The concept of having public data, with authentication for updating, where the hashed passwords are part of that public dataset, is an awful design. Made for a different time when MAIL-FROM also counted as “authentication”. I have also been addressing this in IRRDv4, the other actively maintained authoritative RPSL database software. In broad strokes, we’ve added something similar as an option, where users are authenticated through a portal with a separate auth database[1]. IRRD’s requirements are rather different than RIPE db, as it is generic software used by different deployments that all have their own policies and requirements. One feature I have not seen in this discussion: someone with the ability to change a mntner can lock out other existing users from a mntner, if they can remove all other auth methods (96% of RIPE mntners are listed in their own mnt-by). While there is a recovery process, it is considerably more impactful. To reduce that risk, IRRD has two levels of users associated with a mntner, and the more restricted one can modify any object, except the mntner object itself. IRRD’s API keys can never change the mntner object they are associated with. So that narrows the scope for mntner takeover. Perhaps something to consider for RIPE db as well. Sasha [1] https://irrd.readthedocs.io/en/stable/admins/webui/
participants (11)
-
Daniel Suchy -
Edward Shryane -
Gert Doering -
Nick Hilliard -
Peter Hessler -
Rodolfo García Peñas -
Rodolfo García Peñas (kix)
-
Sasha Romijn -
Tore Anderson -
Wessel Sandkuijl -
Ángel González Berdasco