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 using webupdates or syncupdates, 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.
You can 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 to <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.
For a complete description of how to interact with the RIPE Database, including data protection, please see the following documents: