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)