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

On 15/11/11:47 10:08 AM, Alexander Zubkov wrote:
>> You are right, we could filter out only the lines with MD5 hashes. The
> reasons we have proposed to filter all "auth:" attributes are:
> 
> You are right. Here pros and cons is on the side of hiding all auth
> attributes.
> 
>>> 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.
> 
> But this fact should not be stopper for implementing this for other
> users, which think a little more about security. :)
> By the way, if there is desire to force switching of hash scheme. This
> could be done during password updates. During update RIPE DB server is
> receiving plain password and can replace corresponding MD5 field
> "automagically".

This would work if all the data was regularly updated. A lot of the data
in the RIPE Database is static. It is still in use and is still correct.
But it is not changed for years.

> 
>>     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.
> 
> There is also couple of things, I think should be discussed.
> 
> 1) When object is being updated, the copy of it is sent by e-mail. This
> copy contains unfiltered object. For this case stronger hashing scheme
> should be preferred to for various reasons (mail interception, when
> object is sent to internal mail list where only some should know password).

I presume here you refer to updating the MNTNER object. If this is done
by Webupdates or by using the API it will be sent over HTTPS. We could
recommend as a best practise (or even enforce if required) that MNTNER
objects are not updated by email. Then the hash will never be exposed.

> 
> 2) Proposed updating procedure (when one should enter password to see
> unfiltered object) prevents updating object that is covered by other
> types of auth attributes too.
> For example if we have mntner object, which is maintained by mntner that
> have MD5-PW and PGP-KEY auth. And we have only PGP-KEY and want to
> modify the object, then we will be unable to do so, because we will not
> get unfiltered object without knowing password.
> Even more, if maintainer object with MD5-PW is protected by separate
> maintainer object, which have only KEY auth, this pocedure will be
> broken too.

These are the two corner cases we highlighted in the article on RIPE Labs.

In the first example the person with the password will have to take the
responsibility for maintaining the MNTNER object. If a MNTNER object has
two credentials, which both allow the same data to be updated, we assume
there must be some business relationship between the two people who use
those credentials.

In the second example the separate MNTNER object with only PGP will need
to add a password in order to update the first MNTNER object.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Group

> 
>> 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
> 
> 
>