This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
- Previous message (by thread): [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
- Next message (by thread): [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Shane Kerr
shane at time-travellers.org
Thu May 7 17:29:25 CEST 2015
Pierre, On Tue, 5 May 2015 05:12:15 +0900 Pierre Kim <pierre.kim.sec at gmail.com> wrote: > I am contacting you to share the thoughts on the usage of MD5 in the > RIPE database. I already discussed the problems concerning MD5 > authentication with RIPE NCC Security<security at ripe.net> on 2 Apr 2015 > and RIPE NCC Security officer encouraged me to contact your group to > work together on this issue. One problem is that increased authentication means more work for users. We can draw an analogy with the use of chip & pin for debit and credit cards. Certainly just signing your name is easier than having to remember a PIN, but is obviously "authentication" in only a vague sense. ;) There are differences from chip & pin and the database. In the case of a credit card transaction, the user will be willing to accept the hassle of a more cumbersome and brittle system in order to get access to the benefits of the system. In the case of the RIPE database, the people updating the information are often doing it for the benefit of *other* people. If we make it too hard for them, they can just say "forget it". That means incorrect and/or stale information, which is bad. In the case of resources allocated or assigned by the RIPE NCC, there is already a contract between the RIPE NCC and the holder. I would be quite happy requiring a strong authentication for those resources and all related records (more-specifics, routes, even contacts). I think resource holders need this authentication to get to the member login anyway? In the case of other resources... it's tricker. Luckily since the passwords are no longer published, I think all we really need to ask is that people change their password. Perhaps we should indeed set a flag date to lock those maintainers that have not updated passwords? Experience shows us that long transition times don't really make much difference, so I'd advocate 60 or 90 days or something like that, during which time we include information about how to fix your credentials in WHOIS output and update replies. Cheers, -- Shane
- Previous message (by thread): [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
- Next message (by thread): [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]