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

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

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

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.

> 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