In this article we suggest a technical solution to the issue of publicly displaying MD5 password hashes in the RIPE Database.
Outline
The current business process and design of the RIPE Database requires the MD5 password hashes to be publicly displayed, as described in Password Management in RIPE Database .
To change this behaviour, we propose restricting access to the MD5 hashes contained within a MNTNER object to only those users who have the required authorisation to modify that MNTNER object [1]. This means:
- Filtering out all "auth:" attributes from all query results on MNTNER objects [2]
- Adjusting Webupdates to require maintainer password authorisation over HTTPS before presenting the object to the user for updating
As a side effect, it will no longer be possible for users to query MNTNER objects and submit updates via email or Syncupdates based on the query results, because the returned object is missing mandatory "auth:" attributes. The only practical way to maintain the MNTNER object is to use Webupdates. In theory, it will be possible to keep a local copy of the full object with "auth:" attributes and use that for updates, but there is a risk of overwriting intermediate changes if a user does that, especially if a MNTNER object has shared management.
Note: This behaviour change will only apply when updating a MNTNER object.
Examples of MNTNER object queries
A current query for a MNTNER object will return these results, including the "auth:" attributes (you can enlarge the images by clicking on them):
Figure 1: Current query results
The new query results will look like this after implementation of the change, without any "auth:" attributes displayed and the "source:" attribute showing that the object has been filtered:
Figure 2: New query results
Examples of MNTNER object update work flow
To update a MNTNER object with Webupdates, a user starts by searching for the MNTNER name. Note that at this point no session password has been entered:
Figure 3: Search for MNTNER object
This search will return the MNTNER object ready to update. Note that no session password has been entered yet. The full object is returned, including the "auth:" attributes:
Figure 4: Full MNTNER object displayed without authorisation entered
After implementation of the change, the update process for a MNTNER object with an MD5 password [3] will start in the same way:
Figure 5: Search for MNTNER object
The implemented change takes effect when the Search button is clicked on the previous page. If no session passwords have been entered [4], a prompt will be displayed to enter a password that will allow the user to modify this MNTNER object:
Figure 6: Authorisation password request
The entered password will be validated against the (list of) credentials that are allowed to modify this MNTNER object. If it matches any one of them, the MNTNER object will be returned ready to update. This will include the "auth:" attributes. Note that a session password is now shown as stored:
Figure 7: Full MNTNER object displayed with authorisation entered
The MNTNER object can now be changed, and when the Update button is clicked, the changes will be authorised by the previously entered password.
Password reset process
As part of this process, the MNTNER object needs to be identified and included in the signed document sent to RIPE NCC Customer Services. After this modification, it is the filtered MNTNER object that will be included in this document. The reset process removes all existing "auth:" attributes and replaces them with a single "auth:" attribute containing the users new password hash. So nothing is lost in this process by filtering out the existing "auth:" attributes.
Next steps
- If the community agrees to the deployment of this change, the RIPE NCC will develop and deploy it in a short space of time.
- The RIPE NCC will then contact all the maintainers of MNTNER objects containing passwords and ask them to change these for new, strong passwords.
Notes
[1] There is a corner case if a MNTNER with both password and PGP credentials that are used by different people. Only the user with the password will be able to access and update the full MNTNER object through Webupdates. The other user with the PGP key can still submit a valid, signed update through mail or Syncupdates but cannot gain access to the full object to see the password hashes.
Statistics in Authentication Methods Used in the RIPE Database give some perspective on these corner cases.
[2] To keep the design and code simple, all "auth:" attributes will be filtered from any queried MNTNER object. Even if the MNTNER object does not include any passwords. The only way to access a MNTNER object in full is by using Webupdates.
This filter will be applied at the core level of the RIPE Database software, so these attributes will be filtered out regardless of which query method is used. By removing the whole set of attributes, the public will not know which authentication method is used by any MNTNER or how many different values apply. Unlike the "-B" query flag to include the email attributes filtered from all objects by a default query, there will be no query flag option to include the "auth:" attributes.
[3] If the MNTNER object doesn't have any "auth:" attributes with MD5 passwords and is only protected by PGP Keys and/or X.509 certificates, no password is required to access this MNTNER. The full MNTNER object will be returned after the initial search request page.
[4] If a session password is already stored in the user's session, this will be validated against the MNTNER object's required credentials. If it is correct, no popup window will ask the user for a password. If it is not correct (a session password could be there from some previous work on other objects) the popup window will ask the user for a password. If this entered password is invalid, an error condition will take the user back to the search object stage.
Comments 5
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.
Philipp Kern •
Wouldn't phasing out MD5 hashes altogether in favour of GPG/PGP and X.509 make more sense instead of letting everyone else suffer to protect the precious bad hashes? Or instead adding better hash flavours (like many-round hashes)?
Kaveh Ranjbar •
Hello, Thank you for your comment, the issue is already discussed in details in the RIPE NCC Database Working Group Mailing list, In short based on current adoption of PGP and X.509 by maintainers (https://labs.ripe.net/Members/kranjbar/authentication-methods-used-in-the-ripe-database) and limitations of using these methods over web it is not practical nor realistic to force all users to use any of those methods, but obviously it is a better choice and if a user is comfortable using PGP, implementing this change will not effect them, they can choose to authenticate their objects solely by PGP for example. The issue of changing hash flavors was also brought up, but in general most community members as well as security advisors are against publishing any type of hash publicly, that might be secure enough today but in a few years time we might again be in the same situation, that said, as mentioned in the article we will look for a more comprehensive solution after this immediate issue is resolved. We prefer to use a centralized authentication method handled by a dedicated auth. provider which might store passwords internally in a way much more secure than MD5 hashes. Kaveh Ranjbar, Database Group Manager, RIPE NCC
Hank Nussbacher •
There is a bug in Webupdates. The mntner object I am trying to update has two auth tags - with different passwords. I have only one of the auth tags. I have checked this by taking the original saves mntner and resubmitted it *without any changes* via email to auto-dbm@ripe.net and I received a SUCCESS message. Now I am trying via Webupdates and using the auth MD5 pswd I have and I am receiving an error of "You are not authorized to edit this maintainer". I suspect there is a a bug in Webupdates handling double auth tags.
Hide replies
Kaveh Ranjbar •
Hello, We can not reproduce the behavior in our system, could you please kindly contact ripe-dbm@ripe.net with you specific objects? Then we can check the logs and see what exactly happened. Kaveh Ranjbar, Database Group Manager, RIPE NCC UPDATE: We have been able to spot a corner case with some hashes which can causes this issue and we are working on a fix. The fix will be in production shortly. It is not related to multiple AUTH: lines but is actually caused by the hashes which have more than one space after MD5-PW keyword. Thank you for raising this. All the best, Kaveh.
Kaveh Ranjbar •
UPDATE: This issue is fixed now and there should be no problem updating your maintainer object. Please us know (ripe-dbm@ripe.net) if you still experiencing problems. Thanks again for letting us know. Regards, Kaveh.