Protecting Your Data in the RIPE Database
RIPE Database Security Basics
Every object in the RIPE Database must be protected. This is done using a so-called mntner (maintainer) object. It serves as a "lock" to protect another object that you control. Practically, this means that in a certain object – such as an inetnum – you refer to this mntner with the "mnt-by:" attribute. For more information on creating and managing maintainers, please refer to the Maintainers document.
A mntner can hold one or more authentication methods that you can use to unlock and modify the objects it protects. We will recommend the best authentication method for each use case below.
Available Authentication Methods
When editing RIPE Database objects on our website, we highly recommend using your RIPE NCC Access (SSO) account. It works seamlessly with all other RIPE NCC services, meaning that you only need one set of credentials for everything. It provides strong security, optional two-step verification and the facility to recover a lost password yourself. You can add as many SSO accounts to a maintainer as you like, giving you personalised, granular control.
When you edit an existing object that is protected using an MD5 password, you will be asked to authenticate using your password first. You will then be able to automatically associate your RIPE NCC Access account with the maintainer in the same dialogue box. You can manually associate your SSO account by editing your mntner object and adding this "auth:" attribute:
- auth: SSO <your-sso-email _at_ example _dot_ org>
Then, simply log in with your SSO credentials in the top right corner of our website and make changes to your objects. Please note that the email addresses of the SSO accounts will not be publicly visible in the RIPE Database. Only authorised users can see them.
If you use another method to update the RIPE Database that doesn't use our website, such as email-updates, a script or external application, it is not possible to use SSO at this time. In these cases we recommend that you use a PGP key.
This is one of the strongest protection methods available. You can set this up by first generating a private/public key pair in PGP software of your choice. Then you create a key-cert object in the RIPE Database in which you store the public key. Lastly, you point to the key-cert object from your mntner using the following "auth:" attribute:
- auth: PGPKEY-<id>
Here, the <id> is the PGP key ID of the public key included in the object in the usual eight digit hex format.
You can send PGP signed updates to the RIPE Database using for example syncupdates or by emailing <auto-dbm _at_ ripe _dot_ net>. Signing your RIPE Database updates from the command line is usually as simple as typing :
gpg --clearsign update.txt
Alternatively, there are many plug-ins available for your email client that will do this automatically. When you submit your signed update, the database software will check the signature using the public key stored in the key-cert object referenced in the "auth:" attribute of the relevant mntner object. If the cryptographic signature is correct, the update will proceed, otherwise it will be refused.
For more information, please refer to our PGP documentation.
We don't recommend the MD5 authentication method for everyday use as it has several downsides:
- The MD5 hashing algorithm is not very secure
- Setting up, maintaining and recovering MD5 passwords is cumbersome
- When used for email updates, an unencrypted, cleartext password must be sent over the Internet
You should only use MD5 passwords if you talk to the RIPE Database API directly, because this is the only compatible authentication method at this time. The API is accessed over HTTPS, and your password will be encrypted on the communication channel.
To set up an MD5 password in your maintainer, you must include an "auth:" attribute with a value corresponding to an MD5 hashed password and the MD5-PW keyword:
- auth: MD5-PW <MD5 hashed password>
When submitting an update to create, modify or delete an object protected by a maintainer, the message sent to the database server must include a line containing:
- password: <cleartext password>
If this password, when hashed, matches the one stored in the mntner object, the update will proceed, otherwise it will be refused.
Given the flexibility of the RIPE Database and the maintainer system, there can be cases where you find yourself unable to authenticate. Currently, only certain combinations of authentication and update method are compatible, as shown in this table:
* It works, but is not recommended
We recommend that if you predominantly use the web interface, you only use SSO and if you mainly use email updates, you use PGP.
Depending on your use case, it is important to carefully consider which authentication method you put on each maintainer you manage. For example, there are three basic situations where authentication might fail when trying to use the web interface:
- The object you are trying to modify is protected by a maintainer that is not yours. You therefore rightfully do not have access.
- The object you are trying to modify is protected by a maintainer with several SSO accounts, none of which are yours. The maintainer also doesn't have a shared MD5 password that would allow you to authenticate.
- The object you are trying to modify is protected by a maintainer that only has a PGP key as the authorisation.
For cases 1 and 2, you need to ask the administrative or technical contact of the maintainer to give you the appropriate access. For case 3, you can use another update method that does support your authentication, such as email.
Lastly, in case your maintainer is protected with an MD5 password that you forgot, you can reset it here.
For a complete description of how to interact with the RIPE Database, including data protection, please see the following documents: