MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
Dear Database Working Group Members, 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@ripe.net> on 2 Apr 2015 and RIPE NCC Security officer encouraged me to contact your group to work together on this issue. In 2011, I had grabbed all the MD5s of the RIPE database before they were taken out from the public view and I don't think I was the only security researcher who downloaded all the hashes. This john-compatible file (containing MNT logins and MD5 hashs) was never exposed to public but the hashs can be (VERY) easily cracked. From the discussion with RIPE Security (who received a copy of this file), 27.000 usable hashes (on a total of 36.000) appeared to be valid til now. By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database , I see : "The MD5 hash is public, when running a single query (not for bulk queries)." I assume this was a known problem but the RIPE didn't alert that all the hashs have been retrieved, although there were some urgency to change the passwords or to use a safer authentication method. When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015. The 90 day period can be adjusted by adding more days at the end if RIPE shows a good progress of the migration. I wanted to do responsible disclosure when I saw the RIPE Responsible Disclosure Policy which is a Really Good Thing, I think. According to the RIPE transparency, as recommended by RIPE NCC Security, therefore I am now contacting this working group to work together because deprecation of MD5 is an important change in the RIPE database and it must be debated in a democratic manner. My analysis is simple: The MD5 authentication is broken for years and it's time to change to a more secure method. I think people needs to be encouraged to move to SSO authentication. Using MD5 now is unsafe and dangerous, especially with unchanged 4 year-old passwords. Please share your thoughts about this situation. I will be happy to debate with you. I want to thank Ivo Dijkhuis, RIPE NCC Information Security Officer, for the quality of the exchanges we had. Regards, -- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/
Dear Pierre, On Tue, May 05, 2015 at 05:12:15AM +0900, Pierre Kim wrote:
I am contacting you to share the thoughts on the usage of MD5 in the RIPE database.
Thank you for reaching out.
By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database
When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015.
For clarification: does this mean you will make publically available a list of all hashes + mntner names you retrieved in 2011 combined with a plaintext string which fits the hash? Kind regards, Job
Dear Database Working Group Members, By public information, I mean, MNTER names with associated MD5 Hashes (without plaintext strings). -- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/ On 5/5/15, Job Snijders <job@ntt.net> wrote:
Dear Pierre,
On Tue, May 05, 2015 at 05:12:15AM +0900, Pierre Kim wrote:
I am contacting you to share the thoughts on the usage of MD5 in the RIPE database.
Thank you for reaching out.
By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database
When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015.
For clarification: does this mean you will make publically available a list of all hashes + mntner names you retrieved in 2011 combined with a plaintext string which fits the hash?
Kind regards,
Job
On 4 May 2015, at 22:12, Pierre Kim <pierre.kim.sec@gmail.com> wrote:
I think people needs to be encouraged to move to SSO authentication.
In case a RIPE Database user wishes to do this, there are instructions to use Single Sign-On authentication available here: https://www.ripe.net/participate/member-support/ripe-ncc-access Kind regards, Alex Band Product Manager RIPE NCC
Hi Pierre I would like to just clarify a few points in your email. Firstly the article you referred to was published in November 2011. At that time your could query for a MNTNER object and the MD5 hash was returned. Although there was no file available on the FTP site with a list of all MNTNER objects, as you know it was possible to download all the other bulk object files and create a list of all referenced MNTNER objects. There was no limit on how many of these that could be queried so it was not difficult to get a list of all MD5 hashes. Two days later, in November 2011, another article was published outlining the process of hiding the MD5 hasheshttps://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database This was accepted by the community and it was implemented in January 2012https://www.ripe.net/ripe/mail/archives/db-wg/2012-January/003856.html Since then it has not been possible to query for a MNTNER and receive the MD5 hash. In this second article, and again in the announcement to the DB WG, it stated "The RIPE NCC will then contact all the maintainers of MNTNER objects containing passwords and ask them to change these for new, strong passwords." As far as I remember all MNTNER holders with MD5 passwords were contacted and advised to change them. cheersDenis WalkerIndependent Netizen From: Pierre Kim <pierre.kim.sec@gmail.com> To: db-wg@ripe.net Sent: Monday, 4 May 2015, 22:12 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods Dear Database Working Group Members, 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@ripe.net> on 2 Apr 2015 and RIPE NCC Security officer encouraged me to contact your group to work together on this issue. In 2011, I had grabbed all the MD5s of the RIPE database before they were taken out from the public view and I don't think I was the only security researcher who downloaded all the hashes. This john-compatible file (containing MNT logins and MD5 hashs) was never exposed to public but the hashs can be (VERY) easily cracked. From the discussion with RIPE Security (who received a copy of this file), 27.000 usable hashes (on a total of 36.000) appeared to be valid til now. By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database , I see : "The MD5 hash is public, when running a single query (not for bulk queries)." I assume this was a known problem but the RIPE didn't alert that all the hashs have been retrieved, although there were some urgency to change the passwords or to use a safer authentication method. When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015. The 90 day period can be adjusted by adding more days at the end if RIPE shows a good progress of the migration. I wanted to do responsible disclosure when I saw the RIPE Responsible Disclosure Policy which is a Really Good Thing, I think. According to the RIPE transparency, as recommended by RIPE NCC Security, therefore I am now contacting this working group to work together because deprecation of MD5 is an important change in the RIPE database and it must be debated in a democratic manner. My analysis is simple: The MD5 authentication is broken for years and it's time to change to a more secure method. I think people needs to be encouraged to move to SSO authentication. Using MD5 now is unsafe and dangerous, especially with unchanged 4 year-old passwords. Please share your thoughts about this situation. I will be happy to debate with you. I want to thank Ivo Dijkhuis, RIPE NCC Information Security Officer, for the quality of the exchanges we had. Regards, -- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/
Dear Denis, Thank you for your explanation in detail about what happened in 2011. It is indeed interesting to know. -- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/ On 5/5/15, denis walker <ripedenis@yahoo.co.uk> wrote:
Hi Pierre I would like to just clarify a few points in your email. Firstly the article you referred to was published in November 2011. At that time your could query for a MNTNER object and the MD5 hash was returned. Although there was no file available on the FTP site with a list of all MNTNER objects, as you know it was possible to download all the other bulk object files and create a list of all referenced MNTNER objects. There was no limit on how many of these that could be queried so it was not difficult to get a list of all MD5 hashes.
Two days later, in November 2011, another article was published outlining the process of hiding the MD5 hasheshttps://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database This was accepted by the community and it was implemented in January 2012https://www.ripe.net/ripe/mail/archives/db-wg/2012-January/003856.html Since then it has not been possible to query for a MNTNER and receive the MD5 hash. In this second article, and again in the announcement to the DB WG, it stated "The RIPE NCC will then contact all the maintainers of MNTNER objects containing passwords and ask them to change these for new, strong passwords." As far as I remember all MNTNER holders with MD5 passwords were contacted and advised to change them. cheersDenis WalkerIndependent Netizen
From: Pierre Kim <pierre.kim.sec@gmail.com> To: db-wg@ripe.net Sent: Monday, 4 May 2015, 22:12 Subject: [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
Dear Database Working Group Members,
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@ripe.net> on 2 Apr 2015 and RIPE NCC Security officer encouraged me to contact your group to work together on this issue.
In 2011, I had grabbed all the MD5s of the RIPE database before they were taken out from the public view and I don't think I was the only security researcher who downloaded all the hashes.
This john-compatible file (containing MNT logins and MD5 hashs) was never exposed to public but the hashs can be (VERY) easily cracked. From the discussion with RIPE Security (who received a copy of this file), 27.000 usable hashes (on a total of 36.000) appeared to be valid til now.
By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database , I see : "The MD5 hash is public, when running a single query (not for bulk queries)." I assume this was a known problem but the RIPE didn't alert that all the hashs have been retrieved, although there were some urgency to change the passwords or to use a safer authentication method.
When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015. The 90 day period can be adjusted by adding more days at the end if RIPE shows a good progress of the migration. I wanted to do responsible disclosure when I saw the RIPE Responsible Disclosure Policy which is a Really Good Thing, I think.
According to the RIPE transparency, as recommended by RIPE NCC Security, therefore I am now contacting this working group to work together because deprecation of MD5 is an important change in the RIPE database and it must be debated in a democratic manner.
My analysis is simple: The MD5 authentication is broken for years and it's time to change to a more secure method. I think people needs to be encouraged to move to SSO authentication. Using MD5 now is unsafe and dangerous, especially with unchanged 4 year-old passwords.
Please share your thoughts about this situation. I will be happy to debate with you.
I want to thank Ivo Dijkhuis, RIPE NCC Information Security Officer, for the quality of the exchanges we had.
Regards,
-- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/
Hi Pierre, On 04/05/15 22:12, Pierre Kim wrote:
Dear Database Working Group Members,
By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database , I see : "The MD5 hash is public, when running a single query (not for bulk queries)." I assume this was a known problem but the RIPE didn't alert that all the hashs have been retrieved, although there were some urgency to change the passwords or to use a safer authentication method.
When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015.
What public information exactly do you mean?
The 90 day period can be adjusted by adding more days at the end if RIPE shows a good progress of the migration. I wanted to do responsible disclosure when I saw the RIPE Responsible Disclosure Policy which is a Really Good Thing, I think.
What migration? RIPE has changed the database scheme to hide passwords, recommended all MNTners to change their password, and offers stronger means of authentication. What more do they need to do right now?
According to the RIPE transparency, as recommended by RIPE NCC Security, therefore I am now contacting this working group to work together because deprecation of MD5 is an important change in the RIPE database and it must be debated in a democratic manner.
My analysis is simple: The MD5 authentication is broken for years and it's time to change to a more secure method. I think people needs to be encouraged to move to SSO authentication. Using MD5 now is unsafe and dangerous, especially with unchanged 4 year-old passwords.
Please share your thoughts about this situation. I will be happy to debate with you.
At this point, I'm very curious as to: 1) What information do you plan to disclose in 90 days? 2) What do you expect of RIPE in that period? -- chris
Dear Chris, My email was intended to propose having a safer authentication method. I was hoping that RIPE will either : - force users to change their passwords. After 4 years and the RIPE recommendation, 27.000 hashes are still being used on a total of 36.000 without update. Only 25% of the hashes have been updated. - deprecate MD5 in profit of stronger authentication methods. Having 75% of valid hashes in the nature is a concern, I think. Any security researcher who downloaded all the hashes could misuse this information. Regards, -- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/ On 5/6/15, Christiaan Ottow <chris@6core.net> wrote:
Hi Pierre,
On 04/05/15 22:12, Pierre Kim wrote:
Dear Database Working Group Members,
By reading https://labs.ripe.net/Members/kranjbar/password-management-in-ripe-database , I see : "The MD5 hash is public, when running a single query (not for bulk queries)." I assume this was a known problem but the RIPE didn't alert that all the hashs have been retrieved, although there were some urgency to change the passwords or to use a safer authentication method.
When I discussed it with RIPE NCC Security, I gave a 90 day disclosure policy about this "public" information, starting from the 16 Apr 2015.
What public information exactly do you mean?
The 90 day period can be adjusted by adding more days at the end if RIPE shows a good progress of the migration. I wanted to do responsible disclosure when I saw the RIPE Responsible Disclosure Policy which is a Really Good Thing, I think.
What migration? RIPE has changed the database scheme to hide passwords, recommended all MNTners to change their password, and offers stronger means of authentication. What more do they need to do right now?
According to the RIPE transparency, as recommended by RIPE NCC Security, therefore I am now contacting this working group to work together because deprecation of MD5 is an important change in the RIPE database and it must be debated in a democratic manner.
My analysis is simple: The MD5 authentication is broken for years and it's time to change to a more secure method. I think people needs to be encouraged to move to SSO authentication. Using MD5 now is unsafe and dangerous, especially with unchanged 4 year-old passwords.
Please share your thoughts about this situation. I will be happy to debate with you.
At this point, I'm very curious as to: 1) What information do you plan to disclose in 90 days? 2) What do you expect of RIPE in that period?
-- chris
Hi Pierre, On 05/05/15 23:20, Pierre Kim wrote:
Dear Chris,
My email was intended to propose having a safer authentication method.
I was hoping that RIPE will either : - force users to change their passwords. After 4 years and the RIPE recommendation, 27.000 hashes are still being used on a total of 36.000 without update. Only 25% of the hashes have been updated. - deprecate MD5 in profit of stronger authentication methods.
Having 75% of valid hashes in the nature is a concern, I think. Any security researcher who downloaded all the hashes could misuse this information.
I agree that having these hashes out there is a concern, and that it would be good if the MD5-crypt authentication method were disabled. However, that is a policy decision with quite some impact, and I don't think one person should be forcing the RIPE community to do so by threatening to disclose the entire list of hashes. In common practice of responsible disclosure for software vulnerabilities, it is completely unaccepted to not only disclose the vuln but also dump the database, and here we're not even talking about a simple software vuln but about a policy change that affects many stakeholders. I'm speaking only on behalf of myself as a member of the RIPE community, but I'd like to continue this meaningful discussion without a proverbial knife to anyone's throat. -- chris
Dear Chris, I would like to make it clear that the objective is not to threaten to disclose the information but improve the security in RIPE. The main point is the information has been known for 4 years and during 4 years only 25% of the hashes were changed and this should be corrected. I contacted database working members trying to solve this security problem in a democratic manner. Please don't hesitate to submit constructive solutions to this problem. Regards, On 5/6/15, Christiaan Ottow <chris@6core.net> wrote:
Hi Pierre,
On 05/05/15 23:20, Pierre Kim wrote:
Dear Chris,
My email was intended to propose having a safer authentication method.
I was hoping that RIPE will either : - force users to change their passwords. After 4 years and the RIPE recommendation, 27.000 hashes are still being used on a total of 36.000 without update. Only 25% of the hashes have been updated. - deprecate MD5 in profit of stronger authentication methods.
Having 75% of valid hashes in the nature is a concern, I think. Any security researcher who downloaded all the hashes could misuse this information.
I agree that having these hashes out there is a concern, and that it would be good if the MD5-crypt authentication method were disabled.
However, that is a policy decision with quite some impact, and I don't think one person should be forcing the RIPE community to do so by threatening to disclose the entire list of hashes. In common practice of responsible disclosure for software vulnerabilities, it is completely unaccepted to not only disclose the vuln but also dump the database, and here we're not even talking about a simple software vuln but about a policy change that affects many stakeholders.
I'm speaking only on behalf of myself as a member of the RIPE community, but I'd like to continue this meaningful discussion without a proverbial knife to anyone's throat.
-- chris
-- -- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/
On Wed, May 06, 2015 at 06:20:50AM +0900, Pierre Kim wrote: Dear Pierre
I was hoping that RIPE will either : - deprecate MD5 in profit of stronger authentication methods.
Did you mean MD5 or passwords? Making MD5 obsolete was proposed in 2010 during the RIPE61. My short presentation on this topic could be foung here: http://ripe61.ripe.net/presentations/349-better_security_for_maintainers.pdf Best regards, Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Dear Piotr, Thank you for this document. I didn't know you proposed to change the hashing algorithm in 2010. Currently, passwords are encrypted by default to MD5 in the RIPE database. Using passwords is not safe because the MD5 hashes were distributed and are prone to collision attacks. Using an other cryptography hashing algorithm to encrypt passwords is an interesting solution and can be the easiest migration solution. Regards, On 5/6/15, Piotr Strzyzewski <Piotr.Strzyzewski@polsl.pl> wrote:
On Wed, May 06, 2015 at 06:20:50AM +0900, Pierre Kim wrote:
Dear Pierre
I was hoping that RIPE will either : - deprecate MD5 in profit of stronger authentication methods.
Did you mean MD5 or passwords?
Making MD5 obsolete was proposed in 2010 during the RIPE61. My short presentation on this topic could be foung here: http://ripe61.ripe.net/presentations/349-better_security_for_maintainers.pdf
Best regards, Piotr
-- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
-- -- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/
Pierre, On Tue, 5 May 2015 05:12:15 +0900 Pierre Kim <pierre.kim.sec@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@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
All,
On 07 May 2015, at 17:29, Shane Kerr <shane@time-travellers.org> wrote:
Pierre,
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.
I agree, but does somebody see what impact it has to lock the maintainers that don’t update their passwords? How do we get them out of the locked state again? — chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 20.5.2015 20:29, Christiaan Ottow wrote:
I agree, but does somebody see what impact it has to lock the maintainers that don’t update their passwords? How do we get them out of the locked state again?
There's procedure for lost MNTNER password recovery, I think this is enough even for these cases... :-) https://apps.db.ripe.net/change-auth/#/ - -Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVXPDBAAoJEKa4QYLLxXGSzxkP/25McuP6Wr3v65m9JgZ/1doc 6QmJixoDNC58vUNKLscFL0/6lpzLWgpjbbzx/4ZzQ9u9yKFifS437Dg9cSapIapQ lU2ZCxW7K0w3LZBHjwISHfCt4ru4W0x+IKxN03iOqA5dLRQFGtG1DsIAhr1Axl5x ViAs985GqMXBPC06mHfAhD+pjmht3bnGKMUsU6qcQ4cRyuId/QOCFF4tsjSqoFT3 dJsMqc4SCg2Whu1d0oU70cS2k8s5aVL2MTmHYTtMxFZC1lN7zlo0N85pCPFict0K mOwCwSsQq1RSqNSmwXrBnbvEkik4jxEkhd7uhzqKFXe/EI5h5K3s7I7KDO2T+Y99 SFoa5jZkqYw0dsKjYLduO9MlCZyzhFA9CHEcYVpojVpPZpj5RQ48bFmsLBo56wNO Yn0gPmcPbreXfphY4gfrl0MihRHPI9Dwm3Z2jtFh0F3i/GjrML2Q3qvYnXyTxfJw ViwOVldN5MxtgnEdh08jVjBHb7LIIXPtrRakc7P4Yaxq3zEkXWTx/IOdtEXpUCqX tDieNhsGu0L7gTtEOW9P6XB8pxtp4ZX0zcm8N4zqFN2MMjjo1wK91v3tKJUVtNSn Xzp72Ii3qT+kmj/EiU+TxsjkPvLyVZU6sOMD+3+s3dcjK/9VNheI/wKmQd5pxHCL oMYcxbqPJCG+ukyD9Iy4 =MoPX -----END PGP SIGNATURE-----
Dear Database Working Group Members, Shane, Chris, Daniel - thanks for your proposals. As for my understanding on the proposals, it is technically possible to force users to change their passwords or to encourage them using a stronger authentication method. Also, there seems to be a resistance on migrating the hashing algorithm. On the other hand, I am concerned MD5 hashes are prone to collision attacks from a security perspective. MD5 is an obsolete now. It is rather recommended to use another cryptography hashing algorithm to encrypt passwords. Now, as Shane stated in his interesting post, long transition times don't really make much difference and the situation can be fixed with a workaround by advocating XX days to fix the credentials by showing a warning in whois output. But this doesn't affect the hashing algorithm which is prone to collision attacks. What are members' views on this? Regards, On 5/21/15, Daniel Suchy <danny@danysek.cz> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 20.5.2015 20:29, Christiaan Ottow wrote:
I agree, but does somebody see what impact it has to lock the maintainers that don’t update their passwords? How do we get them out of the locked state again?
There's procedure for lost MNTNER password recovery, I think this is enough even for these cases... :-)
https://apps.db.ripe.net/change-auth/#/
- -Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJVXPDBAAoJEKa4QYLLxXGSzxkP/25McuP6Wr3v65m9JgZ/1doc 6QmJixoDNC58vUNKLscFL0/6lpzLWgpjbbzx/4ZzQ9u9yKFifS437Dg9cSapIapQ lU2ZCxW7K0w3LZBHjwISHfCt4ru4W0x+IKxN03iOqA5dLRQFGtG1DsIAhr1Axl5x ViAs985GqMXBPC06mHfAhD+pjmht3bnGKMUsU6qcQ4cRyuId/QOCFF4tsjSqoFT3 dJsMqc4SCg2Whu1d0oU70cS2k8s5aVL2MTmHYTtMxFZC1lN7zlo0N85pCPFict0K mOwCwSsQq1RSqNSmwXrBnbvEkik4jxEkhd7uhzqKFXe/EI5h5K3s7I7KDO2T+Y99 SFoa5jZkqYw0dsKjYLduO9MlCZyzhFA9CHEcYVpojVpPZpj5RQ48bFmsLBo56wNO Yn0gPmcPbreXfphY4gfrl0MihRHPI9Dwm3Z2jtFh0F3i/GjrML2Q3qvYnXyTxfJw ViwOVldN5MxtgnEdh08jVjBHb7LIIXPtrRakc7P4Yaxq3zEkXWTx/IOdtEXpUCqX tDieNhsGu0L7gTtEOW9P6XB8pxtp4ZX0zcm8N4zqFN2MMjjo1wK91v3tKJUVtNSn Xzp72Ii3qT+kmj/EiU+TxsjkPvLyVZU6sOMD+3+s3dcjK/9VNheI/wKmQd5pxHCL oMYcxbqPJCG+ukyD9Iy4 =MoPX -----END PGP SIGNATURE-----
-- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/
Dear working group, The RIPE NCC has been working together with the chairs on an initial implementation plan to deal with this issue. In a nutshell we will encourage (and facilitate) users to update their old passwords or migrate to SSO or PGP starting 29 June, before removing these passwords altogether on 13 July. Regardless of whether the password hashes will be disclosed after the 90 days disclosure period that was communicated to us earlier, we feel that we cannot postpone this given the public exposure this problem has recently had in this working group. The working group is of course more than welcome to discuss further enhancements in addition to these measures. Such as: changing the hashing algorithm, password ageing, or even deprecating passwords altogether. And if and when consensus is reached on any of those issues, we can plan an implementation. The plan in more detail: 1) Encourage users to update their passwords a) Facilitate updating passwords We will deploy a simple web form next week that allows a user to update an existing password simply by entering the maintainer, the old password, and the new password (twice to catch typos). While it is technically possible to achieve this using web updates today, it's sufficiently involved to discourage most users of the database. b) Encourage users to use more secure authentication mechanisms We have updated the documentation with recommendations on which authentication mechanism to use. In short we encourage the use of SSO accounts for web updates, and PGP signing for sync and mail updates: https://www.ripe.net/manage-ips-and-asns/db/support/security/protecting-data c) Alert active maintainers On Monday 29 June we will send out warning emails to active maintainers (used to create or update objects during the last 12 months) that have old, pre November 2011, passwords. We will explain the situation and encourage these maintainers to update their passwords using the tool above, or start using PGP or SSO instead as described in the documentation. d) Alert other users We will also send out a general announcement about this issue. 2) Remove old passwords We will remove ALL old passwords on Monday 13 July. Note that we do not plan to contact inactive maintainers individually beforehand, or send notifications about this change. Instead we will include a remark in these maintainers explaining why these maintainers were locked and refer to the "forgot mntner password process": https://apps.db.ripe.net/change-auth The reason for this is simple. We are simply not able to handle the additional load of supporting password resets for 20,000 inactive maintainers. We can and will however, deal with access recovery requests for these maintainer as needed. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
On 16 Jun 2015, at 22:46, Pierre Kim <pierre.kim.sec@gmail.com> wrote:
Dear Database Working Group Members,
Shane, Chris, Daniel - thanks for your proposals. As for my understanding on the proposals, it is technically possible to force users to change their passwords or to encourage them using a stronger authentication method. Also, there seems to be a resistance on migrating the hashing algorithm.
On the other hand, I am concerned MD5 hashes are prone to collision attacks from a security perspective. MD5 is an obsolete now. It is rather recommended to use another cryptography hashing algorithm to encrypt passwords.
Now, as Shane stated in his interesting post, long transition times don't really make much difference and the situation can be fixed with a workaround by advocating XX days to fix the credentials by showing a warning in whois output. But this doesn't affect the hashing algorithm which is prone to collision attacks.
What are members' views on this?
Regards,
On 5/21/15, Daniel Suchy <danny@danysek.cz> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 20.5.2015 20:29, Christiaan Ottow wrote:
I agree, but does somebody see what impact it has to lock the maintainers that don’t update their passwords? How do we get them out of the locked state again?
There's procedure for lost MNTNER password recovery, I think this is enough even for these cases... :-)
https://apps.db.ripe.net/change-auth/#/
- -Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJVXPDBAAoJEKa4QYLLxXGSzxkP/25McuP6Wr3v65m9JgZ/1doc 6QmJixoDNC58vUNKLscFL0/6lpzLWgpjbbzx/4ZzQ9u9yKFifS437Dg9cSapIapQ lU2ZCxW7K0w3LZBHjwISHfCt4ru4W0x+IKxN03iOqA5dLRQFGtG1DsIAhr1Axl5x ViAs985GqMXBPC06mHfAhD+pjmht3bnGKMUsU6qcQ4cRyuId/QOCFF4tsjSqoFT3 dJsMqc4SCg2Whu1d0oU70cS2k8s5aVL2MTmHYTtMxFZC1lN7zlo0N85pCPFict0K mOwCwSsQq1RSqNSmwXrBnbvEkik4jxEkhd7uhzqKFXe/EI5h5K3s7I7KDO2T+Y99 SFoa5jZkqYw0dsKjYLduO9MlCZyzhFA9CHEcYVpojVpPZpj5RQ48bFmsLBo56wNO Yn0gPmcPbreXfphY4gfrl0MihRHPI9Dwm3Z2jtFh0F3i/GjrML2Q3qvYnXyTxfJw ViwOVldN5MxtgnEdh08jVjBHb7LIIXPtrRakc7P4Yaxq3zEkXWTx/IOdtEXpUCqX tDieNhsGu0L7gTtEOW9P6XB8pxtp4ZX0zcm8N4zqFN2MMjjo1wK91v3tKJUVtNSn Xzp72Ii3qT+kmj/EiU+TxsjkPvLyVZU6sOMD+3+s3dcjK/9VNheI/wKmQd5pxHCL oMYcxbqPJCG+ukyD9Iy4 =MoPX -----END PGP SIGNATURE-----
-- Pierre Kim pierre.kim.sec@gmail.com @PierreKimSec https://pierrekim.github.io/
Hi, On Wed, Jun 17, 2015 at 04:34:43PM +0200, Tim Bruijnzeels wrote:
The RIPE NCC has been working together with the chairs on an initial implementation plan to deal with this issue.
"works for me" (emphasis on "old passwords" - we do have a long and complicated and new! MD5 hash on our maintainer, but since this is no longer published by whois or the RIPE DB dumps, we consider it an acceptable risk) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear working group, On Monday 13 July, the RIPE NCC will remove all RIPE Database maintainer MD5 passwords that have not been changed since November 2011. We are taking this step as a preventative security measure. This decision was taken in response to discussion on the RIPE Database Working Group mailing list and in close consultation with the working group co-chairs. The contacts of maintainers actively used in the past year have already received individual emails instructing them to change their password. If you have not received this email, but you have reason to believe that your password has not been modified since November 2011, you should change your password before Monday. Go to this page to change your password: https://apps.db.ripe.net/change-auth/mntner-renew-password.html If you find that you are locked out of your maintainer after 13 July, you can still regain access to your maintainer later, using this process: https://apps.db.ripe.net/change-auth/#/ If possible, we urge you stop using passwords and adopt a more secure authentication method such as Single Sign-On or PGP: https://www.ripe.net/manage-ips-and-asns/db/support/security/protecting-data If you have any questions, do not hesitate to contact us at: ripe-dbm@ripe.net. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team
Dear working group,
On Jul 8, 2015, at 4:49 PM, Tim Bruijnzeels <tim@ripe.net> wrote:
On Monday 13 July, the RIPE NCC will remove all RIPE Database maintainer MD5 passwords that have not been changed since November 2011.
As announced we have now removed the passwords that have not changed since November 2011. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Team
2015-07-13 18:17 GMT+03:00 Tim Bruijnzeels <tim@ripe.net>:
Dear working group,
On Jul 8, 2015, at 4:49 PM, Tim Bruijnzeels <tim@ripe.net> wrote:
On Monday 13 July, the RIPE NCC will remove all RIPE Database maintainer MD5 passwords that have not been changed since November 2011.
As announced we have now removed the passwords that have not changed since November 2011.
Poor implementation of a good idea. Now expects a wave of applications for the restoration of access to mnt- objects. E-mail newsletter for these maintainer you tried to do? Where instructions to restore access? -- Vladislav V. Prodan System & Network Administrator support.od.ua
Hi,
Poor implementation of a good idea.
I beg to differ.
Now expects a wave of applications for the restoration of access to mnt- objects.
Well, the process is not too complicated.
E-mail newsletter for these maintainer you tried to do?
The affected maintainers were contacted beforehand. We had one customer who contacted us about it. They didn't even know their password anymore, so the restoration process had to be done anyway.
Where instructions to restore access?
See the database FAQ. All the best, Martin
Hi, On Tue, Jul 14, 2015 at 12:20:20PM +0300, Vladislav V. Prodan wrote:
E-mail newsletter for these maintainer you tried to do? Where instructions to restore access?
Maintainers *have* been contacted well in advance, with a simple web form to change their passwords provided. If people can't be bothered, they will notice now. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
At 12:22 14/07/2015 +0200, Gert Doering wrote:
Hi,
On Tue, Jul 14, 2015 at 12:20:20PM +0300, Vladislav V. Prodan wrote:
E-mail newsletter for these maintainer you tried to do? Where instructions to restore access?
Maintainers *have* been contacted well in advance, with a simple web form to change their passwords provided.
Of the dozen or so maintainers I have access to, one had an old MD5. I got an email a few weeks ago, I changed the pswd, end of story. If you are now locked out, you have only yourself to blame. -Hank
If people can't be bothered, they will notice now.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear working group,
On Jul 14, 2015, at 12:22 PM, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, Jul 14, 2015 at 12:20:20PM +0300, Vladislav V. Prodan wrote:
E-mail newsletter for these maintainer you tried to do? Where instructions to restore access?
Maintainers *have* been contacted well in advance, with a simple web form to change their passwords provided.
We contacted 7100 active maintainers, meaning maintainers that had made any successful update over the last 12 months. Out of this group 5709 (80%) have reset their password. The remaining maintainers can use the normal maintainer reset process here: https://apps.db.ripe.net/change-auth/#/ As communicated on 17 June inactive maintainers were not contacted:
Note that we do not plan to contact inactive maintainers individually beforehand, or send notifications about this change. Instead we will include a remark in these maintainers explaining why these maintainers were locked and refer to the "forgot mntner password process": https://apps.db.ripe.net/change-auth
The reason for this is simple. We are simply not able to handle the additional load of supporting password resets for 20,000 inactive maintainers. We can and will however, deal with access recovery requests for these maintainer as needed.
Note that many inactive will have forgotten their passwords, so the reset process cannot be used by them. Also many of these maintainers are not actively used, and therefore resetting the passwords for them is not as time critical. Considering that we would not have been able to deal with the load of performing due diligence checks for ALL these maintainers, and the risk we were running with the old password hashes surfacing, we could not postpone and buy more time either. Therefore we opted for helping this group on a case by case basis and spreading the load. Kind regards, Tim Bruijnzeels
If people can't be bothered, they will notice now.
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
2015-07-14 16:57 GMT+03:00 Tim Bruijnzeels <tim@ripe.net>:
Dear working group,
On Jul 14, 2015, at 12:22 PM, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, Jul 14, 2015 at 12:20:20PM +0300, Vladislav V. Prodan wrote:
E-mail newsletter for these maintainer you tried to do? Where instructions to restore access?
Maintainers *have* been contacted well in advance, with a simple web form to change their passwords provided.
We contacted 7100 active maintainers, meaning maintainers that had made any successful update over the last 12 months. Out of this group 5709 (80%) have reset their password.
Ok, your position is understandable. It could not be registered in ripedb. In the past and it was not just sign up with a clean slate, without the mnt-by. And now the maintainer of discrimination inactivity. Well, do not tell me it was almost 4 years writable controlled by AS. Now it will be easier to divert the issue to LIR, let it manually registers a new record for the maintainer for their customers. -- Vladislav V. Prodan System & Network Administrator support.od.ua
participants (13)
-
Alex Band -
Christiaan Ottow -
Daniel Suchy -
denis walker -
Gert Doering -
Hank Nussbacher -
Job Snijders -
Martin Gollowitzer -
Pierre Kim -
Piotr Strzyzewski -
Shane Kerr -
Tim Bruijnzeels -
Vladislav V. Prodan