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

Dear Alexander and others

The RIPE NCC can put forward technical proposals and provide statistics
and reality checks based on our in depth knowledge of the software and
design and access to the database contents. But in the end the community
will need to formulate a policy, perhaps around a (modified) technical
proposal or something completely different. One of the main issues of
this latest discussion seems to involve access to password protected
data by PGP credential holders. So I thought at this point it would be a
good idea to re-run my previous analysis and gather a few additional
statistics on the use of different credentials. Then the community can
better judge the scale of any problems, the effectiveness of workarounds
and consider cost benefit issues.

Here is a summary of some of the significant numbers with comments. I
have rounded them off (mostly) to integers and ignored the (almost
insignificant) X.509 usage. So some summations may be slightly out. All
percentages relate to the total number of MNTNERs in use.

Total number of MNTNERs in use = 33323
MNTNERs with only password = 28556  86%
MNTNERs with only PGP = 1532  5%
MNTNERs with password and PGP = 3167  10%

Authentication is a logical OR. So password and PGP, in terms of
authentication security level (while hashes are exposed) is the same as
the lower security of password. So 96% of all MNTNERS use passwords.

Now I looked at the issue of MNTNERs maintaining other MNTNERs. This is
where the most corner cases exist with any plan to hide password hashes.
In this I did not include MNTNERs that maintain themselves and also have
additional MNTNERs maintaining them. I assumed these to be self
maintained but simply have extra numbers of credentials to authenticate
against.

Total MNTNERs not self maintained = 1550  5%
Subset of these 'not self maintained' MNTNERs that have passwords = 1428  4%
(These are the ones that need authentication from their maintaining
MNTNER to view the full object.)
Number of unique MNTNERs maintaining these 'not self maintained' MNTNERs
= 909  3%

So the concern is about the 3% of MNTNERs that maintain the 4% of
MNTNERS that are not self maintained and have passwords. So I looked at
what credentials these 3% (909) MNTNERS use.

Password only    = 686  2%
PGP only         =  91  0.3%
Password and PGP = 128  0.4%

So the two corner cases relate to:

a) 0.3% (91) of MNTNERs that would need to have a password added
(besides the PGP keys) in order to update the MNTNERs they maintain.
b) 0.4% (128) of MNTNERs that 'may' need an extra password adding if the
existing password and PGP key do not belong to the same person. This to
avoid the situation of needing to update a MNTNER maintained by this
MNTNER if the person with the existing password is not available.

Maybe another relevant number is the average number of MNTNER objects
modified per day over the last 7 days is 22.

One final question that comes to mind. If we were to move to SHA512 and
hide the password hashes from the public and then address the other
issue of passing clear text passwords by insecure methods, would
passwords then be considered as a strong authentication?

If these issues are considered important enough that they must be
addressed in any solution without any weakening of the 0.3% PGP only,
indirect authentication, then this must be included in any final policy
and design. This can be done but would complicate a designed solution
and more thought would be needed to find a way to handle this.

I hope this helps with the communities considerations on this issue.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Group



On 16/11/11:47 10:24 AM, Alexander Zubkov wrote:
> Thank You for this answer. Most qeustions/complains went away.
> But one is still not clear to me.
> 
>> 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.
> ...
>> 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.
> 
> This is good point. But it looks like to me that this will bring
> inconvenience to users of KEY-schemes. Which are more secure and thereby
> should be encouraged, not punished. :)
> There should be no case where some information can be got only with
> password if KEY auth is present too.
> May be it should be added some possibility to send signed search
> reqests? Or may be output unfiltered object, encrypted with one of the
> keys.
> 
>> 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.
> 
> You missed the point or I described badly. Let's look at example:
> 
> mntner:  test1-mnt
> auth:    MD5-PW ...
> mnt-by:  test2-mnt
> 
> mntner:  test2-mnt
> auth:    MD5-PW ...
> auth:    PGPKEY-...
> mnt-by:  test2-mnt
> 
> So test2-mnt have 2 auth options. Let it be 2 different people. In that
> case only one having MD5-PW can see unfiltered test1-mnt. This is I
> called "punishing of users of KEY-schemes".
> 
>