[ncc-services-wg] Securing MD5 Hashes in the RIPE Database

[Sorry for the long reply]

Hello Alexander,

Thank you for your feedback. If you agree, I would suggest we continue rest of this discussion in the db-wg mailing list (CCed).

On Nov 11, 2011, at 4:30 PM, Alexander Zubkov wrote:
> 
> Why filter all auth attributes? What if someone will want to use public key to send encrypted mail? :)
> 

You are right, we could filter out only the lines with MD5 hashes. The reasons we have proposed to filter all "auth:" attributes are:

a) It is simpler and more straight forward. Think about the new users who will start using RIPE Database after these changes are made, system filtering all "auth:" attributes looks like rational behavior but filtering only some type of "auth:" attributes needs some explanation of the history. In two years, a lot of us will forget why that was implemented and then it will be just another behaviour of the system that we all have to live with :)

b) The PGP Key referenced in the "auth:" attribute is not intended to be used as a pointer to a public-key for email encryption and actually it shouldn't be used for that purpose. Users might not have access to the private-key for decrypting emails (for example in automated setups) and -even if thy have the access- the value is not there to advertise the public-key.

Also note that a MNTNER object is a container. It often contains credentials for several different people. The holder of the MNTNER object itself may be different from each of the people with credentials contained within it. If you encrypt an email based on a PGP credential contained within a MNTNER object, who would you send that email to? It is quite likely none of the email addresses in the MNTNER object relate directly to the person holding that PGP credential. The whole authentication model of the RIPE Database is complex with many levels of indirection.

For these reasons, if anyone wants a key to be used for encryption users can be directly referred to the public-key in the database or there can be references to the public-key in the remarks lines of different objects, including role objects.

But that's just our opinion and point of view, hiding only the MD5 "auth:" attributes will serve the purpose just as well.

> Also what about implementing stronger schemes for plain passwords like SHA-256,512?

I can see two different scenarios here:

1- We use different hash function and keep the keys published, In this case:

	a) This still leaves the door open for dictionary attacks. A strong hash does not help with a weak password.

	b) Processing power is constantly improving. We started with CRYPT-PW until it was considered to be week and was replaced with MD5. Now SHA 256/512 is a strong hashing function, but this might not be the case in 5 years.

	c) Experience has shown it takes years for users to change data. When we switched from CRYPT-PW to MD5 we allowed about a year for users to upgrade. At the end of that period we still had to lock many MNTNER objects that still only had CRYPT-PW.

	d) We didn't find any business case for keeping the hashes public.

2- Another scenario could be the case that we use different hash function and still go ahead and hide the hashes, hence in practice we use different hashing system for internal storage of password hashes

	a) It is definitely good idea and the way to go, after hiding the hashes we should think about making the internal storage more secure.

	b) In long term we may suggest moving the authentication to a system specifically designed for this purpose, for example RIPE Access. That system might even use HSMs to keep hashes safe but it will be that system's responsibility.

Again, this is just clarifying our line of thinking for making that technical proposal, we might have missed something or our assumptions might be wrong, that's why we need community's feedback on the issue.

And to emphasize Peter Koch's comments at RIPE 63's Database Session, there is a need to take a look at the bigger picture as well. This proposal only addresses publication of MD5 hashes. The issue of clear text password transport over email is still open and there might be other issues as well and that's why a security analysis of the whole process is useful and needed.

Thank you again for contributing to the subject.

Kind Regards,
Kaveh.

---
Kaveh Ranjbar,
Database Group Manager, RIPE NCC