Passwords are the most used authentication method in the RIPE Database. This mechanism has two major design problems. The MD5 hash is public, when running a single query (not for bulk queries). And in case of email updates, plain text passwords are sent by email to update the database. Find below some recommendations on how to secure your objects until these issues have been addressed.
Background
The content of the RIPE Database is presented in form of RPSL data objects . The authentication to authorise updates to these data objects is based on the RPSS standard . MD5 password is the main form of authentication used in the RIPE Database as described in Authentication Methods Used in the RIPE Database . Even where MNTNER objects are maintained by other MNTNER objects, MD5 passwords are still by far the most common authentication method. The encrypted password is in the form of an MD5 hash with an eight character salt.
The hash for the passwords is stored in MNTNER objects. With the current database model, the hash is exposed to public viewing within the MNTNER object. All these objects can be queried by anyone, but are not available for bulk download . Using simple passwords in this environment is not considered very secure. Complex passwords provide better security, but are still vulnerable to attacks due to the hash being exposed.
To update the RIPE Database by email, passwords are included in plain text in email messages. The RIPE Database provides for using Transport Layer Security (TLS) as a security enhancement for emails. But this is only secure if every step of the email passage from the user to the RIPE Database provides a TLS service. If any of the steps does not provide this service, then the clear text password is exposed to man in the middle attacks.
These two main issues need to be addressed to improve password security and have been mentioned in previous RIPE Meetings. At RIPE 62 in Amsterdam, the community asked the RIPE NCC to provide a report on usage of different authentication mechanisms which the RIPE NCC did shortly after the meeting. At RIPE 63 in Vienna, in light of the results of the analysis mentioned, it was considered necessary to immediately improve the situation and for a proposal to agree on a road map with a solution for the RIPE NCC to address this issue.
Exposure of password hashes
When the RIPE Database data model was designed, the computer power to crack passwords in a reasonable time was not available to an average user. As computer power increased, we deprecated the old CRYPT-PW passwords and move to the stronger MD5 hash with salt. Now with easy access to networks of computers it is time for a more radical approach to secure data in the RIPE Database.
The reason for exposing the hash is based on historical design decisions: To update any object requires the full text of the new object to be submitted to the database. There is currently no concept of partial updates by the conventional update methods used by most users. To update a MNTNER object requires the full copy of the object including all the password hashes and other authorisation tokens. There is also no means of authenticated queries. So it is not possible to hide any part of a MNTNER object and only supply the hidden data to an authenticated user. Putting these two design issues together means the full data must be freely available to any user who queries it. Otherwise the holder of the MNTNER object could not update it unless they kept an up-to-date local copy.
Strong MD5 passwords can be safely used to secure data in the RIPE Database if the hash is only accessible by the holder of the MNTNER.
Plain text passwords
When updates are submitted by email and authenticated by password, it is not possible to guarantee security of the clear text password. Even with TLS, the RIPE NCC has no control over all the stages the email takes.
If updates must be sent by email, then PGP signatures over the update text is the only way to guarantee security.
The RIPE Database now accepts updates using more secure authentication methods. For individual object updates, online forms are available. Passwords can be safely used with these forms and submit using HTTPS. Syncupdates can also be accessed via HTTPS.
For power users there is an API available allowing scripting of updates using HTTPS.
Strong MD5 passwords can be safely used to secure data in the RIPE Database if updates are sent over HTTPS connections.
The way forward
Since the RIPE community (via the RIPE Database working group) sets the direction for all process changes that changes to the behaviour of, or the interaction with, the RIPE Database, the RIPE community needs to agree on a solution in which the existing tools and use cases are minimally affected.
In the meantime
If you submit any updates by email, the RIPE NCC suggests to only use PGP authentication for these updates. Using one of the more secure update processes is safer when using a password.
If a user is worried about the MD5 hash being exposed in the MNTNER object - until the community agrees on a solution - it is recommended to use PGP authentication methods. In case it is not technically possible or convenient for the user to switch to PGP, use of complex passwords which makes the hash safer against dictionary attacks is suggested. Changing the password or passwords regularly is also recommended. The Password Generator has a strength indicator. It is advisable to choose a password that is shown as 'Strong'.
Please note that authentication methods in an object are treated with "OR". That means if an object has a PGP signature as well as multiple MD5 passwords, any of the passwords or the access to PGP private key is enough to authenticate using that MNTNER object.
Comments 0
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.