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

On 15/11/11:47 1:27 PM, Alexander Zubkov wrote:
> 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.
> 

It is in everyone's interest for the RIPE Database to be a reliable
source of trusted information. When there is a significant improvement
made to security this should be rolled out to all users as soon as
possible. This should also apply to a user who may not be too concerned
themselves with the level of security of data.

What we did with the CRYPT-PW -> MD5 change was to allow a period of
time for users to make the upgrade themselves. After that period we auto
generated new MD5 passwords for all MNTNER objects still containing
CRYPT-PW. We then provided a web service so anyone who knew the original
CRYPT-PW password that we removed could use it to obtain the new auto
generated MD5 password. This password recovery phase lasted for several
years, but at least all the passwords had been upgraded to MD5 at the
start of it.

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

The "upd-to:" and "mnt-nfy:" attributes are only used when data objects
are changed that are maintained by this MNTNER object. However if the
MNTNER object has a "notify:" attribute then any change to the MNTNER
object itself will result in an email containing the details of the
change. We omitted to mention this in the technical proposal but our
plan is to filter the objects shown in these notifications. Where the
change is to the credentials of the MNTNER object we can also add a
comment in the notification that the credentials have changed.

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

If there is no password at all in the MNTNER object the "auth:"
attributes will not be filtered in Webupdates and no password will be
asked for in order to display the object.

There is no requirement for the maintainer of a MNTNER object to be one
of the people who have credentials listed in the MNTNER object and it
can be a separate MNTNER object. So if the maintainer of a MNTNER object
is on vacation and you want to change your password or PGP key right now
with the present system there is nothing you can do.

As we said in the article on RIPE Labs, the authentication model used by
the RIPE Database is complex with many levels of indirection. If there
was a simple solution to this problem that covered all possible issues
we would have done it years ago. Working within the current design we
want the best possible solution to this one issue that covers the
majority of use cases and acceptable workarounds for the corner cases
that can be implemented in a relatively short time period.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Group

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