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

On 11/15/2011 02:21 PM, Denis Walker wrote:
>
>
> 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.

1) If we do not want to enforce security to others. Then it is there 
fault that they using weak password schemes, passwords at all, etc... 
You, I and other people shouldn't care at all.

2) If we wish to enhance security, i.e. take care of people, who don't 
mind about it. Than this feature, of course, will not fix those, who not 
updating database. But is it bad because of this? No, it will take care 
of some people, will not harm others and this is good. :)
Also this will reduce number of mails: "You are using obsolete password 
hash. Change it or you will be deleted". This is less work anyway.

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

May be I'm doing something wrong, but when I updating objects through 
web, I receive result in the browser and by e-mail too. This is handled 
by udp-to and mnt-nfy attributes, for example.
So it is one more way of hash exposure.

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

This is limiting users in the ways they can maintain there objects. You 
say "password there => password only for this case", which is bad. And 
when there is no password at all, "auth:" will be filtered anyway and 
one should remember what it looks like to update it.
On business relationship... what if man with password is on vacation or 
sick, or it turned to evil?

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

Sounds like workaround, not solution. Also, "MNTNER object with only 
PGP" can be in sutuation where ha can not "add a password", because it 
is maintained by third maintainer. :)

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