Securing MD5 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.