From info at arin.net Mon Feb 8 10:42:35 2021 From: info at arin.net (ARIN) Date: Mon, 08 Feb 2021 10:42:35 -0500 Subject: [ARIN-consult] =?utf-8?q?Consultation_Now_Open_on_the_Future_of_?= =?utf-8?b?QVJJTuKAmXMgSVJS?= Message-ID: <4DC6E773-BB77-4213-B1EE-F89C779B5B8B@arin.net> ARIN has been engaged in a multi-year project to create and deploy a new and improved Internet Routing Registry (IRR). On 10 June 2020 (https://www.arin.net/announcements/20200610-irr/), we launched IRR-online, an authenticated and web-based service designed to make it simple for users to publish routing information via ARIN?s website. At that time, the existing IRR-email system was temporarily left in place to allow organizations to continue using email-based updates to publish routing information (in the ARIN-NONAUTH data stream). On 1 February 2021 (https://www.arin.net/announcements/20210201-rn/), we deployed a RESTful API to provide a way to securely automate updates to objects in ARIN?s authenticated IRR service. With the availability of automation for ARIN?s new IRR system, we intend to retire ARIN?s previous non-authenticated, email-based IRR service at the end of September 2021. We are providing advance notice of this plan so that organizations using the non-authenticated and email-based IRR will have time to switch publication of their routing registry information to a more current solution. Similarly, by establishing a firm end date for the non-authenticated and email-based IRR, organizations making use of the outdated and non-authenticated IRR data stream can be ready for when ARIN ceases publishing the ARIN-NONAUTH data stream. The authenticated IRR is available to all ARIN resource holders that have resources covered by a signed Registration Services Agreement (RSA) or Legacy Registration Services Agreement (LRSA). Organizations with resources not currently under an RSA/LRSA that wish to use the authenticated IRR may contact ARIN?s Registration Services Department for assistance with bringing those registrations under an RSA/LRSA. We recognize that this change will have significant impacts on our customers and, as always, we?re interested in your feedback regarding this proposed transition. In particular, we would appreciate hearing from the ARIN community regarding these aspects of the proposed transition: 1. For those using ARIN?s email-based and non-authenticated IRR system, does the proposed shutdown date of 30 September 2021 provide sufficient time for migration to another IRR system? 2. For those making use of the ARIN-NONAUTH data stream, is there any reason to provide this information beyond the system shutdown date? The community feedback provided during this consultation will help inform how we move forward. Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult This consultation will remain open through 5:00 PM ET on Monday, 8 March. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) From athompso at athompso.net Mon Feb 8 11:00:58 2021 From: athompso at athompso.net (Adam Thompson) Date: Mon, 08 Feb 2021 10:00:58 -0600 Subject: [ARIN-consult] =?utf-8?q?Consultation_Now_Open_on_the_Future_of_?= =?utf-8?b?QVJJTuKAmXMgSVJS?= In-Reply-To: <4DC6E773-BB77-4213-B1EE-F89C779B5B8B@arin.net> References: <4DC6E773-BB77-4213-B1EE-F89C779B5B8B@arin.net> Message-ID: <214d25ca77b8f5251e8833eb5a0b4b33@athompso.net> On 2021-02-08 09:42, ARIN wrote: > 1. For those using ARIN?s email-based and non-authenticated IRR > system, does the proposed shutdown date of 30 September 2021 provide > sufficient time for migration to another IRR system? Does not apply to me. > 2. For those making use of the ARIN-NONAUTH data stream, is there any > reason to provide this information beyond the system shutdown date? No. The only reason I care about it, is because some people are (or may be) still submitting updates to it. I would like it to go away as soon as possible. -Adam Thompson athompso at athompso.net From job at fastly.com Mon Feb 8 11:34:32 2021 From: job at fastly.com (Job Snijders) Date: Mon, 8 Feb 2021 17:34:32 +0100 Subject: Consultation Now Open on =?utf-8?Q?the?= =?utf-8?Q?_Future_of_ARIN=E2=80=99s?= IRR In-Reply-To: <1B7F88F3-B359-42A2-9EF8-C4164C6E4B97@arin.net> References: <7FD68972-E36B-4AA0-B76F-A2BA4F8344EE@arin.net> <1B7F88F3-B359-42A2-9EF8-C4164C6E4B97@arin.net> Message-ID: Dear ARIN, global community, I object to the proposal to discontinue RIPE-NONAUTH. I propose an alternative course of action. The function of the ARIN-NONAUTH primarily appears to to serve holders of Internet Number Resources which pre-date ARIN (so-called 'legacy holders'). Expectations have been set by ARIN through the concept of 'grandparenting' that for example Reverse DNS works in some capacity, and a degree of IRR service. The ARIN-NONAUTH registry since the ARIN/ARIN-NONAUT split is fairly harmless (either for users with a presence expressed in the registry, or for consumers of the ARIN-NONAUTH data), and clearly benefits a (perhaps somewhwat under-represented) group of stakeholders. My proposal is that ARIN works to apply the 'RIPE-731' cleanup mechanism to ARIN-NONAUTH. This can be accomplished by enabling the 'RPKI aware mode' in IRRd v4: https://irrd.readthedocs.io/en/stable/admins/rpki/#enabling-rpki-aware-mode Enabling the feature should be fairly straightforward for ARIN (as in, minimal cost and minimal burden, existing open source software can be used). The big advantage of RIPE-731 style IRR object filtering is that any RSA / LRSA / global RPKI-capable holders of INRs can ensure the ARIN-NONAUTH database does not contain conflicting information (simply by publishing RPKI ROAs, allowing a graceful path towards obsolence (aka let the thing die out on its own over time) My fear is that discontinuation of the ARIN-NONAUTH service at this point in time (or in September 2021) will have adverse negative effects on the global routing system, which are easily avoided by taking a few intermediate steps (such as RPKI-aware mode on the ARIN-NONAUTH DB). Many considerations that applied to the RIPE / RIPE-NONAUTH split and subsequent continuation of RIPE-NONAUTH also apply to ARIN-NONAUTH. It is not the right time yet. If ARIN for one reason or another cannot become a RPKI Relying Party of the other Trust Anchors (AFRINIC, APNIC, LACNIC, and RIPE NCC), I propose the service is just left 'as-is', and we revisit this topic in June 2022. Kind regards, Job Snijders On Mon, Feb 08, 2021 at 03:57:11PM +0000, John Curran wrote: > From: ARIN > Subject: [arin-announce] Consultation Now Open on the Future of ARIN?s IRR > Date: 8 February 2021 at 10:46:18 AM EST > To: arin-announce at arin.net > > ARIN has been engaged in a multi-year project to create and deploy a > new and improved Internet Routing Registry (IRR). On 10 June 2020 > (https://www.arin.net/announcements/20200610-irr/), we launched > IRR-online, an authenticated and web-based service designed to make it > simple for users to publish routing information via ARIN?s website. At > that time, the existing IRR-email system was temporarily left in place > to allow organizations to continue using email-based updates to > publish routing information (in the ARIN-NONAUTH data stream). > > On 1 February 2021 (https://www.arin.net/announcements/20210201-rn/), > we deployed a RESTful API to provide a way to securely automate > updates to objects in ARIN?s authenticated IRR service. > > With the availability of automation for ARIN?s new IRR system, we > intend to retire ARIN?s previous non-authenticated, email-based IRR > service at the end of September 2021. We are providing advance notice > of this plan so that organizations using the non-authenticated and > email-based IRR will have time to switch publication of their routing > registry information to a more current solution. Similarly, by > establishing a firm end date for the non-authenticated and email-based > IRR, organizations making use of the outdated and non-authenticated > IRR data stream can be ready for when ARIN ceases publishing the > ARIN-NONAUTH data stream. > > The authenticated IRR is available to all ARIN resource holders that > have resources covered by a signed Registration Services Agreement > (RSA) or Legacy Registration Services Agreement (LRSA). Organizations > with resources not currently under an RSA/LRSA that wish to use the > authenticated IRR may contact ARIN?s Registration Services Department > for assistance with bringing those registrations under an RSA/LRSA. > > We recognize that this change will have significant impacts on our > customers and, as always, we?re interested in your feedback regarding > this proposed transition. In particular, we would appreciate hearing > from the ARIN community regarding these aspects of the proposed > transition: > > 1. For those using ARIN?s email-based and non-authenticated IRR > system, does the proposed shutdown date of 30 September 2021 provide > sufficient time for migration to another IRR system? > > 2. For those making use of the ARIN-NONAUTH data stream, is there any > reason to provide this information beyond the system shutdown date? > > The community feedback provided during this consultation will help > inform how we move forward. Please provide comments to > arin-consult at arin.net. You can subscribe to this mailing list at: > > http://lists.arin.net/mailman/listinfo/arin-consult > > This consultation will remain open through 5:00 PM ET on Monday, 8 March. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) From job at fastly.com Mon Feb 8 11:50:49 2021 From: job at fastly.com (Job Snijders) Date: Mon, 8 Feb 2021 17:50:49 +0100 Subject: Consultation Now Open on =?utf-8?Q?the?= =?utf-8?Q?_Future_of_ARIN=E2=80=99s?= IRR In-Reply-To: References: <7FD68972-E36B-4AA0-B76F-A2BA4F8344EE@arin.net> <1B7F88F3-B359-42A2-9EF8-C4164C6E4B97@arin.net> Message-ID: On Mon, Feb 08, 2021 at 05:34:35PM +0100, Job Snijders wrote: > Dear ARIN, global community, > > I object to the proposal to discontinue RIPE-NONAUTH. I propose an > alternative course of action. typo! I meant ARIN-NONAUTH of course :-) Kind regards, Job From owen at delong.com Mon Feb 8 17:55:50 2021 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Feb 2021 14:55:50 -0800 Subject: [ARIN-consult] =?utf-8?q?Consultation_Now_Open_on_the_Future_of_?= =?utf-8?b?QVJJTuKAmXMgSVJS?= In-Reply-To: References: <7FD68972-E36B-4AA0-B76F-A2BA4F8344EE@arin.net> <1B7F88F3-B359-42A2-9EF8-C4164C6E4B97@arin.net> Message-ID: <43DC34D8-99EE-47DE-BB48-681E4823BDFA@delong.com> I suggest to anyone likely to be caught with difficulty in the shutdown of ARIN-NONAUTH, there is a valid and viable alternative in ALTDB: https://altdb.net It?s not user friendly like IRR-ONline, but it?s got pretty much the same automated processor for email submissions as ARIN-NONAUTH and provides roughly the same service. Owen > On Feb 8, 2021, at 08:34 , Job Snijders via ARIN-consult wrote: > > > From: Job Snijders > > Subject: Re: Consultation Now Open on the Future of ARIN?s IRR > Date: February 8, 2021 at 08:34:32 PST > To: arin-consult at arin.net > > > Dear ARIN, global community, > > I object to the proposal to discontinue RIPE-NONAUTH. I propose an > alternative course of action. > > The function of the ARIN-NONAUTH primarily appears to to serve holders > of Internet Number Resources which pre-date ARIN (so-called 'legacy > holders'). Expectations have been set by ARIN through the concept of > 'grandparenting' that for example Reverse DNS works in some capacity, > and a degree of IRR service. > > The ARIN-NONAUTH registry since the ARIN/ARIN-NONAUT split is fairly > harmless (either for users with a presence expressed in the registry, or > for consumers of the ARIN-NONAUTH data), and clearly benefits a > (perhaps somewhwat under-represented) group of stakeholders. > > My proposal is that ARIN works to apply the 'RIPE-731' cleanup mechanism > to ARIN-NONAUTH. This can be accomplished by enabling the 'RPKI aware > mode' in IRRd v4: https://irrd.readthedocs.io/en/stable/admins/rpki/#enabling-rpki-aware-mode > Enabling the feature should be fairly straightforward for ARIN (as in, > minimal cost and minimal burden, existing open source software can be > used). > > The big advantage of RIPE-731 style IRR object filtering is that any RSA > / LRSA / global RPKI-capable holders of INRs can ensure the ARIN-NONAUTH > database does not contain conflicting information (simply by publishing > RPKI ROAs, allowing a graceful path towards obsolence (aka let the thing > die out on its own over time) > > My fear is that discontinuation of the ARIN-NONAUTH service at this > point in time (or in September 2021) will have adverse negative effects > on the global routing system, which are easily avoided by taking a few > intermediate steps (such as RPKI-aware mode on the ARIN-NONAUTH DB). > > Many considerations that applied to the RIPE / RIPE-NONAUTH split and > subsequent continuation of RIPE-NONAUTH also apply to ARIN-NONAUTH. It > is not the right time yet. > > If ARIN for one reason or another cannot become a RPKI Relying Party of > the other Trust Anchors (AFRINIC, APNIC, LACNIC, and RIPE NCC), I > propose the service is just left 'as-is', and we revisit this topic in > June 2022. > > Kind regards, > > Job Snijders > > On Mon, Feb 08, 2021 at 03:57:11PM +0000, John Curran wrote: >> From: ARIN >> Subject: [arin-announce] Consultation Now Open on the Future of ARIN?s IRR >> Date: 8 February 2021 at 10:46:18 AM EST >> To: arin-announce at arin.net >> >> ARIN has been engaged in a multi-year project to create and deploy a >> new and improved Internet Routing Registry (IRR). On 10 June 2020 >> (https://www.arin.net/announcements/20200610-irr/), we launched >> IRR-online, an authenticated and web-based service designed to make it >> simple for users to publish routing information via ARIN?s website. At >> that time, the existing IRR-email system was temporarily left in place >> to allow organizations to continue using email-based updates to >> publish routing information (in the ARIN-NONAUTH data stream). >> >> On 1 February 2021 (https://www.arin.net/announcements/20210201-rn/), >> we deployed a RESTful API to provide a way to securely automate >> updates to objects in ARIN?s authenticated IRR service. >> >> With the availability of automation for ARIN?s new IRR system, we >> intend to retire ARIN?s previous non-authenticated, email-based IRR >> service at the end of September 2021. We are providing advance notice >> of this plan so that organizations using the non-authenticated and >> email-based IRR will have time to switch publication of their routing >> registry information to a more current solution. Similarly, by >> establishing a firm end date for the non-authenticated and email-based >> IRR, organizations making use of the outdated and non-authenticated >> IRR data stream can be ready for when ARIN ceases publishing the >> ARIN-NONAUTH data stream. >> >> The authenticated IRR is available to all ARIN resource holders that >> have resources covered by a signed Registration Services Agreement >> (RSA) or Legacy Registration Services Agreement (LRSA). Organizations >> with resources not currently under an RSA/LRSA that wish to use the >> authenticated IRR may contact ARIN?s Registration Services Department >> for assistance with bringing those registrations under an RSA/LRSA. >> >> We recognize that this change will have significant impacts on our >> customers and, as always, we?re interested in your feedback regarding >> this proposed transition. In particular, we would appreciate hearing >> from the ARIN community regarding these aspects of the proposed >> transition: >> >> 1. For those using ARIN?s email-based and non-authenticated IRR >> system, does the proposed shutdown date of 30 September 2021 provide >> sufficient time for migration to another IRR system? >> >> 2. For those making use of the ARIN-NONAUTH data stream, is there any >> reason to provide this information beyond the system shutdown date? >> >> The community feedback provided during this consultation will help >> inform how we move forward. Please provide comments to >> arin-consult at arin.net. You can subscribe to this mailing list at: >> >> http://lists.arin.net/mailman/listinfo/arin-consult >> >> This consultation will remain open through 5:00 PM ET on Monday, 8 March. >> >> Regards, >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) > > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net ). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rs at seastrom.com Fri Feb 12 14:54:30 2021 From: rs at seastrom.com (Rob Seastrom) Date: Fri, 12 Feb 2021 14:54:30 -0500 Subject: [ARIN-consult] =?utf-8?q?Consultation_Now_Open_on_the_Future_of_?= =?utf-8?b?QVJJTuKAmXMgSVJS?= In-Reply-To: <43DC34D8-99EE-47DE-BB48-681E4823BDFA@delong.com> References: <7FD68972-E36B-4AA0-B76F-A2BA4F8344EE@arin.net> <1B7F88F3-B359-42A2-9EF8-C4164C6E4B97@arin.net> <43DC34D8-99EE-47DE-BB48-681E4823BDFA@delong.com> Message-ID: <95DCBEB6-4124-4D35-86C4-1FBC11A3D148@seastrom.com> I think it has always been implicitly understood that ARIN-NONAUTH is transitional and will be sunset eventually. A hard shutdown with less than 8 months' notice in the middle of a pandemic (which impairs information flows via live conferences) does not seem to be an appropriate way to do this. Therefore I respond in the negative to point 1 of the consultation ("does the proposed shutdown date of 30 September 2021 provide sufficient time for migration to another IRR system"). Some years ago there was a large change in ARIN fees, and a representative from a large ISP stood at the microphone and said that he did not have problems with paying more, but that hitting him out of budget cycle with this change was a hardship. Notwithstanding the existence of ALTDB (which is both no charge and no support), discontinuation of a free service to legacy resource holders presents those dependent on it with a couple of options: sign an LRSA or RSA and get auth and RPKI as part of your contractual relationship with ARIN, or sign up with RADB or some similar non-RIR IRR component. Either of these requires fees, and not providing sufficient advance notice plus an annual budget cycle for stakeholders to get their ducks in a row would reflect poorly on ARIN. I think ARIN set a reasonable standard for community outreach with the "get out the vote" efforts some years back. A two pronged approach of email to contacts and certified mail to billing and administrative contacts is good notification. If we do that and then wait a full year to pull the plug... then part of my objection goes away. I urge that Job's thoughts for orderly burndown be given heavy consideration. Upon further discussion with Job I have the following points to make: * Of the total of 62,352 entries in ARIN-NONAUTH about 10k of those routes show up in the DFZ and about 1,933 are rpki invalid. * That means about 3% of ARIN-NONAUTH are arguably bogus, and about 16% appears to contribute positively to the BGP DFZ from Job's vantage points. * Then there's the other 79% of ARIN-NONAUTH. These might describe 'backup routes', be out dated, or something else. Hard to quantify the damage that might or might not cause. RIPE has had over a year of operational experience with RIPE-731 deployed to remove RPKI-invalid routes from their non-auth (since January 2020) and nothing has blown up... so maybe we can start by doing the same thing. If you haven't read RIPE-731, please do - it's short and to the point. https://www.ripe.net/publications/docs/ripe-731 Speaking for myself and GBPSW/ClueTrust (OrgId: GBPSOF), not my day job or the AC... -r > On Feb 8, 2021, at 5:55 PM, Owen DeLong wrote: > > I suggest to anyone likely to be caught with difficulty in the shutdown of ARIN-NONAUTH, > there is a valid and viable alternative in ALTDB: https://altdb.net > > It?s not user friendly like IRR-ONline, but it?s got pretty much the same automated processor > for email submissions as ARIN-NONAUTH and provides roughly the same service. > > Owen > > > > >> On Feb 8, 2021, at 08:34 , Job Snijders via ARIN-consult > wrote: >> >> >> From: Job Snijders > >> Subject: Re: Consultation Now Open on the Future of ARIN?s IRR >> Date: February 8, 2021 at 08:34:32 PST >> To: arin-consult at arin.net >> >> >> Dear ARIN, global community, >> >> I object to the proposal to discontinue RIPE-NONAUTH. I propose an >> alternative course of action. >> >> The function of the ARIN-NONAUTH primarily appears to to serve holders >> of Internet Number Resources which pre-date ARIN (so-called 'legacy >> holders'). Expectations have been set by ARIN through the concept of >> 'grandparenting' that for example Reverse DNS works in some capacity, >> and a degree of IRR service. >> >> The ARIN-NONAUTH registry since the ARIN/ARIN-NONAUT split is fairly >> harmless (either for users with a presence expressed in the registry, or >> for consumers of the ARIN-NONAUTH data), and clearly benefits a >> (perhaps somewhwat under-represented) group of stakeholders. >> >> My proposal is that ARIN works to apply the 'RIPE-731' cleanup mechanism >> to ARIN-NONAUTH. This can be accomplished by enabling the 'RPKI aware >> mode' in IRRd v4: https://irrd.readthedocs.io/en/stable/admins/rpki/#enabling-rpki-aware-mode >> Enabling the feature should be fairly straightforward for ARIN (as in, >> minimal cost and minimal burden, existing open source software can be >> used). >> >> The big advantage of RIPE-731 style IRR object filtering is that any RSA >> / LRSA / global RPKI-capable holders of INRs can ensure the ARIN-NONAUTH >> database does not contain conflicting information (simply by publishing >> RPKI ROAs, allowing a graceful path towards obsolence (aka let the thing >> die out on its own over time) >> >> My fear is that discontinuation of the ARIN-NONAUTH service at this >> point in time (or in September 2021) will have adverse negative effects >> on the global routing system, which are easily avoided by taking a few >> intermediate steps (such as RPKI-aware mode on the ARIN-NONAUTH DB). >> >> Many considerations that applied to the RIPE / RIPE-NONAUTH split and >> subsequent continuation of RIPE-NONAUTH also apply to ARIN-NONAUTH. It >> is not the right time yet. >> >> If ARIN for one reason or another cannot become a RPKI Relying Party of >> the other Trust Anchors (AFRINIC, APNIC, LACNIC, and RIPE NCC), I >> propose the service is just left 'as-is', and we revisit this topic in >> June 2022. >> >> Kind regards, >> >> Job Snijders >> >> On Mon, Feb 08, 2021 at 03:57:11PM +0000, John Curran wrote: >>> From: ARIN > >>> Subject: [arin-announce] Consultation Now Open on the Future of ARIN?s IRR >>> Date: 8 February 2021 at 10:46:18 AM EST >>> To: arin-announce at arin.net >>> >>> ARIN has been engaged in a multi-year project to create and deploy a >>> new and improved Internet Routing Registry (IRR). On 10 June 2020 >>> (https://www.arin.net/announcements/20200610-irr/ ), we launched >>> IRR-online, an authenticated and web-based service designed to make it >>> simple for users to publish routing information via ARIN?s website. At >>> that time, the existing IRR-email system was temporarily left in place >>> to allow organizations to continue using email-based updates to >>> publish routing information (in the ARIN-NONAUTH data stream). >>> >>> On 1 February 2021 (https://www.arin.net/announcements/20210201-rn/ ), >>> we deployed a RESTful API to provide a way to securely automate >>> updates to objects in ARIN?s authenticated IRR service. >>> >>> With the availability of automation for ARIN?s new IRR system, we >>> intend to retire ARIN?s previous non-authenticated, email-based IRR >>> service at the end of September 2021. We are providing advance notice >>> of this plan so that organizations using the non-authenticated and >>> email-based IRR will have time to switch publication of their routing >>> registry information to a more current solution. Similarly, by >>> establishing a firm end date for the non-authenticated and email-based >>> IRR, organizations making use of the outdated and non-authenticated >>> IRR data stream can be ready for when ARIN ceases publishing the >>> ARIN-NONAUTH data stream. >>> >>> The authenticated IRR is available to all ARIN resource holders that >>> have resources covered by a signed Registration Services Agreement >>> (RSA) or Legacy Registration Services Agreement (LRSA). Organizations >>> with resources not currently under an RSA/LRSA that wish to use the >>> authenticated IRR may contact ARIN?s Registration Services Department >>> for assistance with bringing those registrations under an RSA/LRSA. >>> >>> We recognize that this change will have significant impacts on our >>> customers and, as always, we?re interested in your feedback regarding >>> this proposed transition. In particular, we would appreciate hearing >>> from the ARIN community regarding these aspects of the proposed >>> transition: >>> >>> 1. For those using ARIN?s email-based and non-authenticated IRR >>> system, does the proposed shutdown date of 30 September 2021 provide >>> sufficient time for migration to another IRR system? >>> >>> 2. For those making use of the ARIN-NONAUTH data stream, is there any >>> reason to provide this information beyond the system shutdown date? >>> >>> The community feedback provided during this consultation will help >>> inform how we move forward. Please provide comments to >>> arin-consult at arin.net . You can subscribe to this mailing list at: >>> >>> http://lists.arin.net/mailman/listinfo/arin-consult >>> >>> This consultation will remain open through 5:00 PM ET on Monday, 8 March. >>> >>> Regards, >>> >>> John Curran >>> President and CEO >>> American Registry for Internet Numbers (ARIN) >> >> >> _______________________________________________ >> ARIN-Consult >> You are receiving this message because you are subscribed to the ARIN Consult Mailing >> List (ARIN-consult at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services >> Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net ). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sat Feb 13 08:19:44 2021 From: jcurran at arin.net (John Curran) Date: Sat, 13 Feb 2021 13:19:44 +0000 Subject: [ARIN-consult] =?utf-8?q?Consultation_Now_Open_on_the_Future_of_?= =?utf-8?b?QVJJTuKAmXMgSVJS?= In-Reply-To: <95DCBEB6-4124-4D35-86C4-1FBC11A3D148@seastrom.com> References: <7FD68972-E36B-4AA0-B76F-A2BA4F8344EE@arin.net> <1B7F88F3-B359-42A2-9EF8-C4164C6E4B97@arin.net> <43DC34D8-99EE-47DE-BB48-681E4823BDFA@delong.com> <95DCBEB6-4124-4D35-86C4-1FBC11A3D148@seastrom.com> Message-ID: <9723E887-FE7C-4F83-9B78-3E628B111A3C@arin.net> On 12 Feb 2021, at 2:54 PM, Rob Seastrom > wrote: ... I think ARIN set a reasonable standard for community outreach with the "get out the vote" efforts some years back. A two pronged approach of email to contacts and certified mail to billing and administrative contacts is good notification. If we do that and then wait a full year to pull the plug... then part of my objection goes away. RS - Picking up on one point point regarding notification - that?s a most excellent idea, as the records have notification email addresses so these should definitely be provided notice. I?m not certain how many real-world addresses (e.g. postal) we have that are actually functional ? that?s endemic of the problem with this sort of data, but we can explore that as well. Very helpful - Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Feb 16 11:11:28 2021 From: info at arin.net (ARIN) Date: Tue, 16 Feb 2021 11:11:28 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts Message-ID: Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. Password Check Proposal To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. How would it work? 1. A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online. 2. ARIN encrypts the password and sends part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) and returns all possible matches in their database. (Your actual password is never sent or used in any query.) 3. We compare the full encrypted password to the results sent by HIBP to see if there is a match. 4. If there is a match we will notify the customer. Optional Outcomes We are interested in the community?s thoughts on the possible outcomes when we identify a password that has been exposed in a data breach according to the HIBP service. There are three options: 1. Issue a caution message but allow the password. 2. Issue a warning message and notify the customer that they need to change their password within a defined time period, but not at the current point of login. 3. Issue warning message that requires the customer to select and set a different password immediately. The feedback you provide during this consultation will help inform how we move forward to increase security of ARIN Online for all customers. Thank you for your participation in the ARIN Consultation and Suggestion Process. Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult This consultation will remain open through 5:00 PM ET on 16 March 2021. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) From ken.mix at clearfly.net Tue Feb 16 11:33:35 2021 From: ken.mix at clearfly.net (Ken Mix) Date: Tue, 16 Feb 2021 16:33:35 +0000 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: Hello, I am in strong favor of option 3. A match in HIBP means that a user's account is ripe for a simple credential-stuffing attack. While it may be slightly less convenient having to reset a password immediately, I can't think of a practical reason to leave known compromised credentials active (even if a user has two-factor authentication enabled as a mitigation step). In addition to requiring a password change, it may also be useful to include some canned verbiage explaining the dangers of password reuse and recommending the use of a password manager (vendor agnostic, of course -- it could even be something very brief with link to a reputable third party like the EFF for additional details, e.g. https://ssd.eff.org/en/module/creating-strong-passwords). Regards, Ken Mix -----Original Message----- From: ARIN-announce On Behalf Of ARIN Sent: Tuesday, February 16, 2021 09:12 To: arin-announce at arin.net Subject: [arin-announce] Consultation on Password Security for ARIN Online Accounts Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. Password Check Proposal To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. How would it work? 1. A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online. 2. ARIN encrypts the password and sends part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) and returns all possible matches in their database. (Your actual password is never sent or used in any query.) 3. We compare the full encrypted password to the results sent by HIBP to see if there is a match. 4. If there is a match we will notify the customer. Optional Outcomes We are interested in the community?s thoughts on the possible outcomes when we identify a password that has been exposed in a data breach according to the HIBP service. There are three options: 1. Issue a caution message but allow the password. 2. Issue a warning message and notify the customer that they need to change their password within a defined time period, but not at the current point of login. 3. Issue warning message that requires the customer to select and set a different password immediately. The feedback you provide during this consultation will help inform how we move forward to increase security of ARIN Online for all customers. Thank you for your participation in the ARIN Consultation and Suggestion Process. Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult This consultation will remain open through 5:00 PM ET on 16 March 2021. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From frnkblk at iname.com Tue Feb 16 12:20:52 2021 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 16 Feb 2021 11:20:52 -0600 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: <000001d70488$1402a520$3c07ef60$@iname.com> Perhaps I'm late to the party, but is ARIN already identifying: - excessive failed login from the same IP - excessive failed logins to the same account from different IPS - adding some kind of wait time (e.g. 5 minutes) after some failed logins Does ARIN also allow customers to restrict the IP address space that they can login in from? Perhaps an option to allow logins to only occur from a customer's RIR-registered IP address space? I support option 3. Frank -----Original Message----- From: ARIN-consult On Behalf Of ARIN Sent: Tuesday, February 16, 2021 10:11 AM To: arin-consult at arin.net Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. Password Check Proposal To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. How would it work? 1. A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online. 2. ARIN encrypts the password and sends part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) and returns all possible matches in their database. (Your actual password is never sent or used in any query.) 3. We compare the full encrypted password to the results sent by HIBP to see if there is a match. 4. If there is a match we will notify the customer. Optional Outcomes We are interested in the community?s thoughts on the possible outcomes when we identify a password that has been exposed in a data breach according to the HIBP service. There are three options: 1. Issue a caution message but allow the password. 2. Issue a warning message and notify the customer that they need to change their password within a defined time period, but not at the current point of login. 3. Issue warning message that requires the customer to select and set a different password immediately. The feedback you provide during this consultation will help inform how we move forward to increase security of ARIN Online for all customers. Thank you for your participation in the ARIN Consultation and Suggestion Process. Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult This consultation will remain open through 5:00 PM ET on 16 March 2021. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From bill at herrin.us Tue Feb 16 12:24:21 2021 From: bill at herrin.us (William Herrin) Date: Tue, 16 Feb 2021 09:24:21 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: On Tue, Feb 16, 2021 at 8:11 AM ARIN wrote: > Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. > > Password Check Proposal > > To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. NIST Special Publication 800-63 revision 3 explains how to manage memorized secrets like passwords in a secure manner. This includes checking a database of known compromised passwords (not an external per-password service) and disallowing the use of passwords which appear in that database. I strongly recommend implementing it rather than trying to devise your own criteria. When 800-63 is properly implemented, external password-guessing attacks are effectively useless. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From chris at semihuman.com Tue Feb 16 12:33:21 2021 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 16 Feb 2021 09:33:21 -0800 Subject: [ARIN-consult] [arin-announce] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: Hi John, ARIN staff - To be clear, is this an operation that would be executed only upon a password change? While I definitely support that flow, I?d be curious if we?re also checking the existing account base against known password leaks. If this is being checked upon password change, I believe that Option #3 is the best way to go, as this 1. provides immediate protection of the account and 2. Helps educate users as to the hazards of password re-use. If there?s any planned or existing checks of existing passwords against haveibeenpwned, I?d react to a match with a required password change (with an explanation of the reason why) at next login, or a way to disable the login if the account isn?t logged into within a specific period of time (say, 30 days); this would need to generate a custom message when the user does try to log in that leads to the ?forgotten password? flow. LMK if this helps. Thanks, -C > On Feb 16, 2021, at 8:11 AM, ARIN wrote: > > Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. > > Password Check Proposal > > To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. > > How would it work? > > 1. A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online. > 2. ARIN encrypts the password and sends part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) and returns all possible matches in their database. (Your actual password is never sent or used in any query.) > 3. We compare the full encrypted password to the results sent by HIBP to see if there is a match. > 4. If there is a match we will notify the customer. > > Optional Outcomes > > We are interested in the community?s thoughts on the possible outcomes when we identify a password that has been exposed in a data breach according to the HIBP service. There are three options: > > 1. Issue a caution message but allow the password. > 2. Issue a warning message and notify the customer that they need to change their password within a defined time period, but not at the current point of login. > 3. Issue warning message that requires the customer to select and set a different password immediately. > > The feedback you provide during this consultation will help inform how we move forward to increase security of ARIN Online for all customers. Thank you for your participation in the ARIN Consultation and Suggestion Process. > > Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: > > http://lists.arin.net/mailman/listinfo/arin-consult > > This consultation will remain open through 5:00 PM ET on 16 March 2021. > > Regards, > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. From rs at seastrom.com Tue Feb 16 13:03:28 2021 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 16 Feb 2021 13:03:28 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: <1F59D65F-DF04-4767-BA5F-866E8E1269F3@seastrom.com> > On Feb 16, 2021, at 12:24 PM, William Herrin wrote: > > I strongly recommend implementing it rather > than trying to devise your own criteria. When 800-63 is properly > implemented, external password-guessing attacks are effectively > useless. That has been in the suggestion box for over two years as "ACSP Suggestion 2018.22: Align ARIN password policy with current NIST SP800-63 recommendations". It's all in there in 800-63, account locking guidelines, password length and composition... I concur with Bill's suggestion that we not try to roll our own here. Not opposed to querying with partial hashes (not "encrypted passwords") against haveibeenpwned, but if we demand passwords of at least 20 characters in length (not the bare minimum of 8 as specified in 800-63B 5.1.1.2) with no further requirements for special characters or rotation, I suspect in practice we will never see a match. Note that either forcing longer passwords or the solution proffered in the original consultation can only be applied at password change time; neither can be applied retroactively to all passwords presently in the password store. Any deployment of a new policy should be accompanied by a forced password change for users so that the test can be made. To avoid annoying our constituency with multiple forced password changes, I'd rather not see this done iteratively - that is to say, we should figure out the plan and execute it once. Allowing passwords that have been changed to a password of sufficient length to be subject to more relaxed account locking rules, or even none at all if MFA is enabled... could reduce staff costs associated with locked account recovery. None of this will address system load associated with dictionary-based password guessing attacks; in fact, applying the more relaxed locking guidelines of 800-63 might make it worse. -r -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Feb 16 13:41:05 2021 From: bill at herrin.us (William Herrin) Date: Tue, 16 Feb 2021 10:41:05 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <1F59D65F-DF04-4767-BA5F-866E8E1269F3@seastrom.com> References: <1F59D65F-DF04-4767-BA5F-866E8E1269F3@seastrom.com> Message-ID: On Tue, Feb 16, 2021 at 10:03 AM Rob Seastrom wrote: > None of this will address system load associated with dictionary-based password guessing attacks; in fact, applying the more relaxed locking guidelines of 800-63 might make it worse. Hi Rob, It has been a while since I read it but IIRC you don't lock accounts in 800-63. Instead, you rate-limit attempts. If a particular origin can make only one guess per second and you lock the -origin- for a day if it makes 1000 unsuccessful attempts in a row, even with 100,000 origins attempting to hack you the math says that the time it takes to break a reasonably good 8-character password is functionally infinite -- 6000 years or more. Your worst case is a denial of service attack where distributed attempts to break the same account repeat so continuously that the legitimate account holder can't get through. Unless denial of service is the attacker's intent, they quickly figure out they're not capturing any passwords and move on. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From matt at conundrum.com Tue Feb 16 14:02:06 2021 From: matt at conundrum.com (Matthew Pounsett) Date: Tue, 16 Feb 2021 14:02:06 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <000001d70488$1402a520$3c07ef60$@iname.com> References: <000001d70488$1402a520$3c07ef60$@iname.com> Message-ID: On Tue, 16 Feb 2021 at 12:20, Frank Bulk wrote: > Does ARIN also allow customers to restrict the IP address space that they > can login in from? Perhaps an option to allow logins to only occur from a > customer's RIR-registered IP address space? > There are people that manage address space they don't personally occupy, particularly right now while so few people are reporting to offices. I would not be in favour of this addition to the plan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue Feb 16 14:44:07 2021 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 16 Feb 2021 11:44:07 -0800 Subject: [ARIN-consult] [arin-announce] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: <01DB0D61-73DA-42C3-BD8D-9991DF63AA62@gmail.com> No, it would apply on login, not just password change. The proposal says it would apply when ?A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online.? Note the ?or User Login? clause. I support option 3. I?m not sure if there is any good way to build a local DB of all compromised passwords: IIUIC, HIBP has a number of non-public databases they check as well as the more widely known ones. Based on that, I support checking against HIBP. Scott > On Feb 16, 2021, at 9:33 AM, Chris Woodfield wrote: > > ?Hi John, ARIN staff - > > To be clear, is this an operation that would be executed only upon a password change? While I definitely support that flow, I?d be curious if we?re also checking the existing account base against known password leaks. > > If this is being checked upon password change, I believe that Option #3 is the best way to go, as this 1. provides immediate protection of the account and 2. Helps educate users as to the hazards of password re-use. > > If there?s any planned or existing checks of existing passwords against haveibeenpwned, I?d react to a match with a required password change (with an explanation of the reason why) at next login, or a way to disable the login if the account isn?t logged into within a specific period of time (say, 30 days); this would need to generate a custom message when the user does try to log in that leads to the ?forgotten password? flow. > > LMK if this helps. > > Thanks, > > -C > >> On Feb 16, 2021, at 8:11 AM, ARIN wrote: >> >> Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. >> >> Password Check Proposal >> >> To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. >> >> How would it work? >> >> 1. A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online. >> 2. ARIN encrypts the password and sends part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) and returns all possible matches in their database. (Your actual password is never sent or used in any query.) >> 3. We compare the full encrypted password to the results sent by HIBP to see if there is a match. >> 4. If there is a match we will notify the customer. >> >> Optional Outcomes >> >> We are interested in the community?s thoughts on the possible outcomes when we identify a password that has been exposed in a data breach according to the HIBP service. There are three options: >> >> 1. Issue a caution message but allow the password. >> 2. Issue a warning message and notify the customer that they need to change their password within a defined time period, but not at the current point of login. >> 3. Issue warning message that requires the customer to select and set a different password immediately. >> >> The feedback you provide during this consultation will help inform how we move forward to increase security of ARIN Online for all customers. Thank you for your participation in the ARIN Consultation and Suggestion Process. >> >> Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: >> >> http://lists.arin.net/mailman/listinfo/arin-consult >> >> This consultation will remain open through 5:00 PM ET on 16 March 2021. >> >> Regards, >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) >> >> >> _______________________________________________ >> ARIN-Announce >> You are receiving this message because you are subscribed to >> the ARIN Announce Mailing List (ARIN-announce at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-announce >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue Feb 16 14:44:21 2021 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 16 Feb 2021 11:44:21 -0800 Subject: [ARIN-consult] [arin-announce] Consultation on Password Security for ARIN Online Accounts Message-ID: ?No, it would apply on login, not just password change. The proposal says it would apply when ?A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online.? Note the ?or User Login? clause. I support option 3. I?m not sure if there is any good way to build a local DB of all compromised passwords: IIUIC, HIBP has a number of non-public databases they check as well as the more widely known ones. Based on that, I support checking against HIBP. Scott > On Feb 16, 2021, at 9:33 AM, Chris Woodfield wrote: > ?Hi John, ARIN staff - > > To be clear, is this an operation that would be executed only upon a password change? While I definitely support that flow, I?d be curious if we?re also checking the existing account base against known password leaks. > > If this is being checked upon password change, I believe that Option #3 is the best way to go, as this 1. provides immediate protection of the account and 2. Helps educate users as to the hazards of password re-use. > > If there?s any planned or existing checks of existing passwords against haveibeenpwned, I?d react to a match with a required password change (with an explanation of the reason why) at next login, or a way to disable the login if the account isn?t logged into within a specific period of time (say, 30 days); this would need to generate a custom message when the user does try to log in that leads to the ?forgotten password? flow. > > LMK if this helps. > > Thanks, > > -C > >> On Feb 16, 2021, at 8:11 AM, ARIN wrote: >> >> Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. >> >> Password Check Proposal >> >> To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. >> >> How would it work? >> >> 1. A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online. >> 2. ARIN encrypts the password and sends part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) and returns all possible matches in their database. (Your actual password is never sent or used in any query.) >> 3. We compare the full encrypted password to the results sent by HIBP to see if there is a match. >> 4. If there is a match we will notify the customer. >> >> Optional Outcomes >> >> We are interested in the community?s thoughts on the possible outcomes when we identify a password that has been exposed in a data breach according to the HIBP service. There are three options: >> >> 1. Issue a caution message but allow the password. >> 2. Issue a warning message and notify the customer that they need to change their password within a defined time period, but not at the current point of login. >> 3. Issue warning message that requires the customer to select and set a different password immediately. >> >> The feedback you provide during this consultation will help inform how we move forward to increase security of ARIN Online for all customers. Thank you for your participation in the ARIN Consultation and Suggestion Process. >> >> Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: >> >> http://lists.arin.net/mailman/listinfo/arin-consult >> >> This consultation will remain open through 5:00 PM ET on 16 March 2021. >> >> Regards, >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) >> >> >> _______________________________________________ >> ARIN-Announce >> You are receiving this message because you are subscribed to >> the ARIN Announce Mailing List (ARIN-announce at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-announce >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Tue Feb 16 14:54:19 2021 From: matt at netfire.net (Matt Harris) Date: Tue, 16 Feb 2021 13:54:19 -0600 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: Matt Harris|Infrastructure Lead Engineer 816-256-5446|Direct Looking for something? Helpdesk Portal|Email Support|Billing Portal We build and deliver end-to-end IT solutions. On Tue, Feb 16, 2021 at 11:25 AM William Herrin wrote: > On Tue, Feb 16, 2021 at 8:11 AM ARIN wrote: > > Since October 2020, the ARIN Online system has been subject to a series > of dictionary-based password guessing attacks. Because of the protective > measures currently in place, some customer accounts were locked during > these attacks. ARIN staff has been heavily engaged in mitigating these > attacks, and we are seeking community feedback on potential steps ARIN can > take to reduce the risk of future attacks and to help customers ensure they > are using strong passwords. Password dictionary guessing attacks continue > to be a problem in the industry, and this effort should help reduce the > extent of previously exposed passwords for our ARIN Online user base. > > > > Password Check Proposal > > > > To help ARIN customers make sure they aren?t using a password that has > been exposed and shared publicly online, when someone updates their > password or creates a user account in ARIN Online, it is proposed that ARIN > should check the database "haveibeenpwned (https://haveibeenpwned.com)" > to see if they are trying to use a password that has been compromised. ARIN > will not send the password, but rather we encrypt the password and send > part of the encrypted password to the Have I been Pwned (HIBP) Service ( > https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a > compromised password. Actual passwords are never sent or used in any > query, nor is your user ID or email shared as part of this check. > > > NIST Special Publication 800-63 revision 3 explains how to manage > memorized secrets like passwords in a secure manner. This includes > checking a database of known compromised passwords (not an external > per-password service) and disallowing the use of passwords which > appear in that database. I strongly recommend implementing it rather > than trying to devise your own criteria. When 800-63 is properly > implemented, external password-guessing attacks are effectively > useless. > I strongly agree here. No sense in re-inventing the wheel as far as password security. That said, I would also go further and say that serious consideration should be given to requiring 2fa for any account that has direct control of resources such as IPv4, IPv6, and ASN resources. What would the primary barriers be to enforcing such a policy? Many other organizations and businesses already have done so for user accounts where the ultimate value (and danger) of account compromise is in many cases even much lower than the value and potential danger associated with the compromise of an ARIN account which holds control of resources. Multi-factor authentication is the way the world is headed, and I suspect that ARIN will be considering such a policy in the number 5 years regardless, given the current security climate. So why not get the jump on it and start talking/thinking about this now? - Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Feb 16 15:14:14 2021 From: bill at herrin.us (William Herrin) Date: Tue, 16 Feb 2021 12:14:14 -0800 Subject: [ARIN-consult] [arin-announce] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <01DB0D61-73DA-42C3-BD8D-9991DF63AA62@gmail.com> References: <01DB0D61-73DA-42C3-BD8D-9991DF63AA62@gmail.com> Message-ID: On Tue, Feb 16, 2021 at 11:44 AM Scott Leibrand wrote: > I?m not sure if there is any good way to build a local DB of all compromised passwords: IIUIC, HIBP has a number of non-public databases they check as well as the more widely known ones. Based on that, I support checking against HIBP. Hi Scott, Public sources like https://github.com/danielmiessler/SecLists/tree/master/Passwords are generally good enough. The overlap between the delta vs. private dictionaries and passwords actually in your database is likely to be too small to yield a match given reasonable rate limiting on attempts. Pre-apply common morphs (iI1!, aA@, etc), remove passwords shorter than the 8-char minimum length and add to a common hash-based database like Berkley DB and you end up with a file that's under a gigabyte in size. Easily kept on your auth server and performantly consulted. I've done this. I've gotten a DoD system accredited based on doing this. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From has at google.com Tue Feb 16 16:30:12 2021 From: has at google.com (Heather Schiller) Date: Tue, 16 Feb 2021 16:30:12 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: 2FA like this? https://www.arin.net/reference/materials/security/twofactor/ On Tue, Feb 16, 2021 at 2:54 PM Matt Harris wrote: > Matt Harris? > | Infrastructure Lead Engineer > 816?256?5446 <(816)%20256-5446> > | Direct > Looking for something? > *Helpdesk Portal* > | *Email Support* > | *Billing Portal* > We build and deliver end?to?end IT solutions. > On Tue, Feb 16, 2021 at 11:25 AM William Herrin wrote: > >> On Tue, Feb 16, 2021 at 8:11 AM ARIN wrote: >> > Since October 2020, the ARIN Online system has been subject to a series >> of dictionary-based password guessing attacks. Because of the protective >> measures currently in place, some customer accounts were locked during >> these attacks. ARIN staff has been heavily engaged in mitigating these >> attacks, and we are seeking community feedback on potential steps ARIN can >> take to reduce the risk of future attacks and to help customers ensure they >> are using strong passwords. Password dictionary guessing attacks continue >> to be a problem in the industry, and this effort should help reduce the >> extent of previously exposed passwords for our ARIN Online user base. >> > >> > Password Check Proposal >> > >> > To help ARIN customers make sure they aren?t using a password that has >> been exposed and shared publicly online, when someone updates their >> password or creates a user account in ARIN Online, it is proposed that ARIN >> should check the database "haveibeenpwned (https://haveibeenpwned.com)" >> to see if they are trying to use a password that has been compromised. ARIN >> will not send the password, but rather we encrypt the password and send >> part of the encrypted password to the Have I been Pwned (HIBP) Service ( >> https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a >> compromised password. Actual passwords are never sent or used in any >> query, nor is your user ID or email shared as part of this check. >> >> >> NIST Special Publication 800-63 revision 3 explains how to manage >> memorized secrets like passwords in a secure manner. This includes >> checking a database of known compromised passwords (not an external >> per-password service) and disallowing the use of passwords which >> appear in that database. I strongly recommend implementing it rather >> than trying to devise your own criteria. When 800-63 is properly >> implemented, external password-guessing attacks are effectively >> useless. >> > > I strongly agree here. No sense in re-inventing the wheel as far as > password security. > > That said, I would also go further and say that serious consideration > should be given to requiring 2fa for any account that has direct control of > resources such as IPv4, IPv6, and ASN resources. > > What would the primary barriers be to enforcing such a policy? Many other > organizations and businesses already have done so for user accounts where > the ultimate value (and danger) of account compromise is in many cases even > much lower than the value and potential danger associated with the > compromise of an ARIN account which holds control of resources. > > Multi-factor authentication is the way the world is headed, and I suspect > that ARIN will be considering such a policy in the number 5 years > regardless, given the current security climate. So why not get the jump on > it and start talking/thinking about this now? > > - Matt > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Tue Feb 16 16:57:52 2021 From: matt at netfire.net (Matt Harris) Date: Tue, 16 Feb 2021 15:57:52 -0600 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: Hey Heather, Yepp, as you can see, the system for supporting it already exists and some (perhaps many?) of us are already taking advantage of it. So the next step would be to push it as a requirement for accounts which control resources such as IPv4, IPv6, and AS numbers in order to entirely prevent the brute-force attacks which were the original onus for this discussion. - Matt Matt Harris|Infrastructure Lead Engineer 816-256-5446|Direct Looking for something? Helpdesk Portal|Email Support|Billing Portal We build and deliver end-to-end IT solutions. On Tue, Feb 16, 2021 at 3:30 PM Heather Schiller wrote: > > 2FA like this? > https://www.arin.net/reference/materials/security/twofactor/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at conundrum.com Tue Feb 16 16:58:39 2021 From: matt at conundrum.com (Matthew Pounsett) Date: Tue, 16 Feb 2021 16:58:39 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <24620.7550.896767.281056@gro.dd.org> References: <000001d70488$1402a520$3c07ef60$@iname.com> <24620.7550.896767.281056@gro.dd.org> Message-ID: On Tue, 16 Feb 2021 at 14:31, Dave Lawrence wrote: > Matthew Pounsett writes: > > On Tue, 16 Feb 2021 at 12:20, Frank Bulk wrote: > > > Does ARIN also allow customers to restrict the IP address space that > they > > > can login in from? Perhaps an option to allow logins to only occur > from a > > > customer's RIR-registered IP address space? > > > > There are people that manage address space they don't personally > > occupy, particularly right now while so few people are reporting to > > offices. I would not be in favour of this addition to the plan. > > Even as an opt-in option? I could see that it might occasionally be a > nuisance getting the customer to flip the setting off if needed, but > in general it seems fair enough to have as a possibility. As opt-in that would be fine, I think. I probably trimmed my reply badly... I was specifically reacting to the suggestion that ARIN require people to be logged in from their own RIR-managed space. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Feb 16 17:16:39 2021 From: farmer at umn.edu (David Farmer) Date: Tue, 16 Feb 2021 16:16:39 -0600 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: I personally use ARIN 2FA and the other persons with ARIN online accounts for our organization also use 2FA. However, there is no way, at least that I know of, to require accounts associated with our Organization to have 2FA enabled. So, even if ARIN were to not require all accounts to use 2FA, it would be great to be able to require it at an Organization level. Further, I support implementing 800-63 controls as well. Thanks. On Tue, Feb 16, 2021 at 3:58 PM Matt Harris wrote: > Hey Heather, > Yepp, as you can see, the system for supporting it already exists and some > (perhaps many?) of us are already taking advantage of it. So the next step > would be to push it as a requirement for accounts which control resources > such as IPv4, IPv6, and AS numbers in order to entirely prevent > the brute-force attacks which were the original onus for this discussion. > > - Matt > > Matt Harris? > | Infrastructure Lead Engineer > 816?256?5446 > | Direct > Looking for something? > *Helpdesk Portal* > | *Email Support* > | *Billing Portal* > We build and deliver end?to?end IT solutions. > On Tue, Feb 16, 2021 at 3:30 PM Heather Schiller wrote: > >> >> 2FA like this? >> https://www.arin.net/reference/materials/security/twofactor/ >> > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the > ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Feb 16 17:28:18 2021 From: bill at herrin.us (William Herrin) Date: Tue, 16 Feb 2021 14:28:18 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: On Tue, Feb 16, 2021 at 1:58 PM Matt Harris wrote: > Yepp, as you can see, the system for supporting it already exists and some (perhaps many?) of us are already taking advantage of it. So the next step would be to push it as a requirement for accounts which control resources such as IPv4, IPv6, and AS numbers in order to entirely prevent the brute-force attacks which were the original onus for this discussion. Hi Matt, I don't know the current state of ARIN's account recovery process but unless ARIN first gets religion for it, there's not much point in forcing 2FA in the primary authentication path. "Click this email link to reset your password" is single-factor and not even strong single-factor. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From chris at semihuman.com Tue Feb 16 17:38:23 2021 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 16 Feb 2021 14:38:23 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: That?s true *if* the email link password reset flow also disables an already-registered second factor - which would be an extraordinarily bad idea. In my experience, disabling the second factor (in my case, due to a hardware failure on the phone running my 2FA app) is not something companies are willing do without extreme vetting - AWS, for example, required a notarized, snail-mailed form to consider it. Some companies won?t do it at all, which is why I now have two different Github accounts :/ If it *is* the case that email-based password reset for ARIN Online bypasses a registered 2FA on the account, please fix ASAP. Thanks, -Chris > On Feb 16, 2021, at 2:28 PM, William Herrin wrote: > > On Tue, Feb 16, 2021 at 1:58 PM Matt Harris wrote: >> Yepp, as you can see, the system for supporting it already exists and some (perhaps many?) of us are already taking advantage of it. So the next step would be to push it as a requirement for accounts which control resources such as IPv4, IPv6, and AS numbers in order to entirely prevent the brute-force attacks which were the original onus for this discussion. > > > Hi Matt, > > I don't know the current state of ARIN's account recovery process but > unless ARIN first gets religion for it, there's not much point in > forcing 2FA in the primary authentication path. "Click this email link > to reset your password" is single-factor and not even strong > single-factor. > > Regards, > Bill Herrin > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From rs at seastrom.com Tue Feb 16 17:56:05 2021 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 16 Feb 2021 17:56:05 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: TOTP is "OK but not ascendant". The RFC is 10 years old; the technology has roots that are much older (HOTP). There are better things now. It is still way way way better than "no 2FA", but if we are going to go from optional to required, we might want to consider a recalibration. Job submitted this through the ACSP process less than a month ago: https://www.arin.net/participate/community/acsp/suggestions/2021/2021-2/ -r > On Feb 16, 2021, at 4:30 PM, Heather Schiller via ARIN-consult wrote: > > 2FA like this? https://www.arin.net/reference/materials/security/twofactor/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rs at seastrom.com Tue Feb 16 17:59:15 2021 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 16 Feb 2021 17:59:15 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: <1F59D65F-DF04-4767-BA5F-866E8E1269F3@seastrom.com> Message-ID: <6F0ACFFA-ADE6-417A-823D-0D3573139BF4@seastrom.com> > On Feb 16, 2021, at 1:41 PM, William Herrin wrote: > > On Tue, Feb 16, 2021 at 10:03 AM Rob Seastrom wrote: >> None of this will address system load associated with dictionary-based password guessing attacks; in fact, applying the more relaxed locking guidelines of 800-63 might make it worse. > > Hi Rob, > > It has been a while since I read it but IIRC you don't lock accounts > in 800-63. Instead, you rate-limit attempts. You do both. 800-63b 5.2.2 Rate Limiting (Throttling) says: Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100. And yes, there's an ACSP suggestion in on this: https://www.arin.net/participate/community/acsp/suggestions/2020/2020-16/ -r From bill at herrin.us Tue Feb 16 18:02:31 2021 From: bill at herrin.us (William Herrin) Date: Tue, 16 Feb 2021 15:02:31 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: On Tue, Feb 16, 2021 at 2:38 PM Chris Woodfield wrote: > That?s true *if* the email link password reset flow also disables an already-registered second factor - which would be an extraordinarily bad idea. In my experience, disabling the second factor (in my case, due to a hardware failure on the phone running my 2FA app) is not something companies are willing do without extreme vetting - AWS, for example, required a notarized, snail-mailed form to consider it. Some companies won?t do it at all, which is why I now have two different Github accounts :/ > > If it *is* the case that email-based password reset for ARIN Online bypasses a registered 2FA on the account, please fix ASAP. Hi Chris, An interesting aside here - Resetting the 2FA using an email (when you have the password) can be legitimate. Why? They're the same factor: something you have. Resetting the password using an email (when you have the 2FA) is probably not legitimate. Why? Because that reduces your authentication to a single factor: things you have. Two factor authentication means you supply something from at least two of three categories: what you know, what you have, what you are. You -know- a password but you -have- a cell phone or email account. But a notarized letter might work... Why? The notary attests to your identity -- a what-you-are factor. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From matt at netfire.net Tue Feb 16 18:19:16 2021 From: matt at netfire.net (Matt Harris) Date: Tue, 16 Feb 2021 17:19:16 -0600 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: Matt Harris|Infrastructure Lead Engineer 816-256-5446|Direct Looking for something? Helpdesk Portal|Email Support|Billing Portal We build and deliver end-to-end IT solutions. On Tue, Feb 16, 2021 at 4:56 PM Rob Seastrom wrote: > > TOTP is "OK but not ascendant". The RFC is 10 years old; the technology > has roots that are much older (HOTP). There are better things now. > > It is still way way way better than "no 2FA", but if we are going to go > from optional to required, we might want to consider a recalibration. Job > submitted this through the ACSP process less than a month ago: > https://www.arin.net/participate/community/acsp/suggestions/2021/2021-2/ > > -r > I'd strongly support adding support for additional methods as well. I use both a TOTP app and a Yubikey on a daily basis, and the learning curve for the end-user to implement either is extremely small. That said, the requirements for implementing additional 2fa methods in terms of writing the code to make the support happen in the various web (and other?) applications is a much larger hurdle than simply forcing users with control over resources to enable the existing 2fa support on those accounts. I see these are two independent steps forward, and supporting additional methods need not block the implementation of such a requirement. - Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rs at seastrom.com Wed Feb 17 10:55:14 2021 From: rs at seastrom.com (Rob Seastrom) Date: Wed, 17 Feb 2021 10:55:14 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: <2E94B2D4-8D84-4672-ABD3-41C5B8E948EA@seastrom.com> > On Feb 16, 2021, at 6:19 PM, Matt Harris wrote: > > That said, the requirements for implementing additional 2fa methods in terms of writing the code to make the support happen in the various web (and other?) applications is a much larger hurdle than simply forcing users with control over resources to enable the existing 2fa support on those accounts. I see these are two independent steps forward, and supporting additional methods need not block the implementation of such a requirement. There's a larger discussion to be had surrounding moving the authentication out of the applications themselves and moving to SAML/OAUTH which allows the centralization of the authentication mechanisms. I wouldn't expect a community discussion to be prescriptive about implementation details, but evaluating a pivot to more modern IAM frameworks seems like a good thing for staff to consider before making a move as there may be an opportunity to retire tech debt while gaining capabilities. I have no specific information on the state of affairs on ARIN's various systems (which might have this sort of thing partially or completely implemented already). Moreover, bringing up federatable protocols is in no way a suggestion that ARIN move towards federated IAM (which at first blush seems like a poor fit for the ARIN Online model), -r -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Feb 17 11:03:41 2021 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Feb 2021 08:03:41 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: <39FEE230-3ECF-45FF-A3A5-6B66F6FBE760@delong.com> Wouldn?t a 2FA system built on OAUTH2 alllwing users to use google auth, ubikey, or a variety of other one-time or cryptographically secure authentication methods afford greater protection with less risk? Owen > On Feb 16, 2021, at 09:25, William Herrin wrote: > > ?On Tue, Feb 16, 2021 at 8:11 AM ARIN wrote: >> Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. >> >> Password Check Proposal >> >> To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. > > > NIST Special Publication 800-63 revision 3 explains how to manage > memorized secrets like passwords in a secure manner. This includes > checking a database of known compromised passwords (not an external > per-password service) and disallowing the use of passwords which > appear in that database. I strongly recommend implementing it rather > than trying to devise your own criteria. When 800-63 is properly > implemented, external password-guessing attacks are effectively > useless. > > Regards, > Bill Herrin > > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. From michael.hare at wisc.edu Wed Feb 17 20:02:52 2021 From: michael.hare at wisc.edu (Michael Hare) Date: Thu, 18 Feb 2021 01:02:52 +0000 Subject: =?Windows-1252?Q?re:_Consultation_Now_Open_on_the_Future_of_ARIN=92s_IRR?= Message-ID: Hi, Joined to ask about " Consultation Now Open on the Future of ARIN?s IRR ". As I don't have John's original email since I just joined, I presume about the only thing I can do is start a new thread. Sorry about that. Just for the sake of understanding, I'm going to toss what is probably a softball question. Sorry for the long intro/background. I am a primary network engineer of AS3128. We are a regional educational network aggregator in Wisconsin and downstreams are 100% in the ARIN region. In 2014 when AS3128 came to be [long Wisconsin legal story I will omit], "mnt-by: MNT-BRUWS" proxy registered many route/route6 to origin AS3128, and a few downstream aut-num as well, tied to downstream ARIN OrgIDs that I don't have access to. A vast majority of those objects are now in 'source: ARIN-NON-AUTH' and are likely not under RSA. Not playing tiny violin or stating any opinion on that matter, just facts. When I log into https://account.arin.net/public/secure/irr/routes I see 2600:1d00::/28, AS-UWSYSNET, AS3128, as I might expect since they are correctly under 'source: ARIN'. My immediate interest is making sure that upstreams of AS3128 can continue to build prefix lists for BGP peering as they currently do. Today I do this by sharing ARIN-IRR as-set: AS-UWSYSNET which is listed under 'source: ARIN' and 'mnt-by: MNT-BRUWS'. Finally, my question: Since I see no obvious way to migrate data 'mnt-by: BRUWS' currently in ARIN-NON-AUTH, am I correct that under the proposal all of our downstream OrgIDs each independently need to 'true up' with ARIN to avoid route/route6 deletion from the ARIN IRR? If true, definitely not excited about moving IRR due to lack of action of our downstreams, but if this goes forward on the proposed timeline we mostly certainly will, otherwise AS3128 will experience a large financial impact caused by reduced prefixes showing up in peering filters of settlement free partners being built based on ARIN:AS-UWSYSNET. Thanks, -Michael From mcr at sandelman.ca Thu Feb 18 12:05:16 2021 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 18 Feb 2021 12:05:16 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: <8094.1613667916@localhost> > Password Check Proposal > To help ARIN customers make sure they aren?t using a password that has been > exposed and shared publicly online, when someone updates their password or > creates a user account in ARIN Online, it is proposed that ARIN should > check the database "haveibeenpwned (https://haveibeenpwned.com)" to see if > they are trying to use a password that has been compromised. ARIN will not > send the password, but rather we encrypt the password and send part of the > encrypted password to the Have I been Pwned (HIBP) Service > (https://haveibeenpwned.com/API/v3#PwnedPasswords) to see if it matches a > compromised password. Actual passwords are never sent or used in any > query, nor is your user ID or email shared as part of this check. I don't really understand this "encrypt" the password. I think that this means to hash it, and then send the hash. I think that we can all understand that. Encrypt implies that it can be decrypted. > 3. Issue warning message that requires the customer to select and set a > different password immediately. This seems like the best situation, but there are issues when this is a password shared among a few operators. In particular, what we don't want is for one person to be forced to change the password under duress of getting their work done, and then picking another password which they then email to their colleagues. I personally miss the days of sending PGP signed emails to update objects. It seems that the entire movement to the web interface has resulted in less security rather than more. Of course, very few actually used PGP. The alternative today should be TLS Client side certificates. There are many operational complexicities in maintaining them, but given that we web properties that have varieties of: 1) 2FA 2) ACL for this IP address only 3) password complexity rules such that I need to use the same browser that really, Client side certificates seem almost trivial now. Can we have this option please? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mcr at sandelman.ca Thu Feb 18 12:05:59 2021 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 18 Feb 2021 12:05:59 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: Message-ID: <8284.1613667959@localhost> William Herrin wrote: > On Tue, Feb 16, 2021 at 1:58 PM Matt Harris wrote: >> Yepp, as you can see, the system for supporting it already exists and >> some (perhaps many?) of us are already taking advantage of it. So the >> next step would be to push it as a requirement for accounts which >> control resources such as IPv4, IPv6, and AS numbers in order to >> entirely prevent the brute-force attacks which were the original onus >> for this discussion. > Hi Matt, > I don't know the current state of ARIN's account recovery process but > unless ARIN first gets religion for it, there's not much point in > forcing 2FA in the primary authentication path. "Click this email link > to reset your password" is single-factor and not even strong > single-factor. ARIN requires a phone call. From bill at herrin.us Thu Feb 18 12:18:12 2021 From: bill at herrin.us (William Herrin) Date: Thu, 18 Feb 2021 09:18:12 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <8094.1613667916@localhost> References: <8094.1613667916@localhost> Message-ID: On Thu, Feb 18, 2021 at 9:05 AM Michael Richardson wrote: > > 3. Issue warning message that requires the customer to select and set a > > different password immediately. > > This seems like the best situation, but there are issues when this is a > password shared among a few operators. In particular, what we don't want is > for one person to be forced to change the password under duress of getting > their work done, and then picking another password which they then email to > their colleagues. Hi Michael, That's frankly an issue with the operator. Group authentication (password sharing) is forbidden by essentially every security standard in existence. Each individual is supposed to have their own account (authentication) which is then granted shared access (group access) to the organization's ARIN resources. > The alternative today should be TLS Client side certificates. > There are many operational complexicities in maintaining them, but given that > we web properties that have varieties of: > 1) 2FA Client certificates are a form of 2FA. They're a "what you have" factor, same as a totp token or an email confirmation. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From bill at herrin.us Thu Feb 18 12:19:35 2021 From: bill at herrin.us (William Herrin) Date: Thu, 18 Feb 2021 09:19:35 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <8284.1613667959@localhost> References: <8284.1613667959@localhost> Message-ID: On Thu, Feb 18, 2021 at 9:06 AM Michael Richardson wrote: > William Herrin wrote: > > I don't know the current state of ARIN's account recovery process but > > unless ARIN first gets religion for it, there's not much point in > > forcing 2FA in the primary authentication path. "Click this email link > > to reset your password" is single-factor and not even strong > > single-factor. > > ARIN requires a phone call. Hi Michael, That's single-factor: control of a phone number. AT&T defended itself from a lawsuit a year or two ago where someone lost millions of dollars of bitcoin because a hacker was able to get AT&T to activate a new phone with their phone number and then use that to reset the brokerage password. AT&T's position, which the court accepted, was that cell phone service was not advertised as or secured to a standard appropriate for authentication thus anyone who relied on it for such did so at their own risk. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ From mcr at sandelman.ca Thu Feb 18 14:18:06 2021 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 18 Feb 2021 14:18:06 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: <8094.1613667916@localhost> Message-ID: <30300.1613675886@localhost> William Herrin wrote: >> > 3. Issue warning message that requires the customer to select and >> set a > different password immediately. >> >> This seems like the best situation, but there are issues when this is >> a password shared among a few operators. In particular, what we don't >> want is for one person to be forced to change the password under >> duress of getting their work done, and then picking another password >> which they then email to their colleagues. > Hi Michael, > That's frankly an issue with the operator. Group authentication > (password sharing) is forbidden by essentially every security standard > in existence. Each individual is supposed to have their own account > (authentication) which is then granted shared access (group access) to > the organization's ARIN resources. Right, so then certificates should not a problem, and this shouldn't be an excuse, should it? >> The alternative today should be TLS Client side certificates. There >> are many operational complexicities in maintaining them, but given >> that we web properties that have varieties of: 1) 2FA > Client certificates are a form of 2FA. They're a "what you have" > factor, same as a totp token or an email confirmation. Yes, so why do support static passwords at all? Why not just the token, or the TLS Client side certificate at ~2^128 for 2048-bit RSA? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mcr at sandelman.ca Thu Feb 18 14:20:50 2021 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 18 Feb 2021 14:20:50 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: <8284.1613667959@localhost> Message-ID: <31213.1613676050@localhost> William Herrin wrote: >> William Herrin wrote: > I don't know the current >> state of ARIN's account recovery process but > unless ARIN first gets >> religion for it, there's not much point in > forcing 2FA in the >> primary authentication path. "Click this email link > to reset your >> password" is single-factor and not even strong > single-factor. >> >> ARIN requires a phone call. > Hi Michael, > That's single-factor: control of a phone number. No, you have to phone ARIN. Not them phoning you. You then go through a process with their operator. > AT&T defended itself from a lawsuit a year or two ago where someone Yes, SIM swapping is a serious issue, and as you say, the phone companies' really aren't prepared to do proper authorization for possession of a phone-number. > lost millions of dollars of bitcoin because a hacker was able to get > AT&T to activate a new phone with their phone number and then use that > to reset the brokerage password. AT&T's position, which the court > accepted, was that cell phone service was not advertised as or secured > to a standard appropriate for authentication thus anyone who relied on > it for such did so at their own risk. Too bad the banks don't seem to understand this. Mine has arrived at SMS as 2FA with huge enthusiasm, a decade late. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From Joey.White at bcbsks.com Thu Feb 18 16:31:14 2021 From: Joey.White at bcbsks.com (Joey White) Date: Thu, 18 Feb 2021 21:31:14 +0000 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts haveibeenpwned [dot] com/Passwords In-Reply-To: References: Message-ID: I support option 3. Troy Hunt did a great job creating a reliable public service available as a RESTful API to easily call. However, I recommend ARIN considers the scenario of what occurs if HIBP is not responding. I would not recommend a reply to this email, because the details in the response could disclose an attack avenue. A failover path could exist with Troy's downloadable password list - haveibeenpwned [dot] com/Passwords It would require coding to parse the file and return the result back to the auth process, so additional overhead :-( Thank you, [cid:5184eb3a-bd2a-4cf6-b5f9-2eeac8be9b72] Joey White Security Architect Blue Cross and Blue Shield of Kansas p: 785-291-6471 | w: bcbsks.com ________________________________ From: ARIN-consult on behalf of ARIN Sent: Tuesday, February 16, 2021 10:11 AM To: arin-consult at arin.net Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts Since October 2020, the ARIN Online system has been subject to a series of dictionary-based password guessing attacks. Because of the protective measures currently in place, some customer accounts were locked during these attacks. ARIN staff has been heavily engaged in mitigating these attacks, and we are seeking community feedback on potential steps ARIN can take to reduce the risk of future attacks and to help customers ensure they are using strong passwords. Password dictionary guessing attacks continue to be a problem in the industry, and this effort should help reduce the extent of previously exposed passwords for our ARIN Online user base. Password Check Proposal To help ARIN customers make sure they aren?t using a password that has been exposed and shared publicly online, when someone updates their password or creates a user account in ARIN Online, it is proposed that ARIN should check the database "haveibeenpwned (https://urldefense.proofpoint.com/v2/url?u=https-3A__haveibeenpwned.com&d=DwIGaQ&c=2xyLtJK-6wL-B01m9dqMd9CDbkL-hoZ5ifChpoVJRBA&r=RY5ZOoNF6CKUE-zbyE5VeisOFsxu2hSC5wQeuEurgH8&m=PU2-W-p9904eTkfY3ACK5_ghxyOjFaNw8mbBw2gV5ag&s=go6yhOEK4Eq6c6QNbL5HOl7CGYqHaCvL_QnHqB1U2W0&e= )" to see if they are trying to use a password that has been compromised. ARIN will not send the password, but rather we encrypt the password and send part of the encrypted password to the Have I been Pwned (HIBP) Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__haveibeenpwned.com_API_v3-23PwnedPasswords&d=DwIGaQ&c=2xyLtJK-6wL-B01m9dqMd9CDbkL-hoZ5ifChpoVJRBA&r=RY5ZOoNF6CKUE-zbyE5VeisOFsxu2hSC5wQeuEurgH8&m=PU2-W-p9904eTkfY3ACK5_ghxyOjFaNw8mbBw2gV5ag&s=dRts4JOWywHFUg2cbHvdUQYniNfopXH1NHinbg1Y7vQ&e= ) to see if it matches a compromised password. Actual passwords are never sent or used in any query, nor is your user ID or email shared as part of this check. How would it work? 1. A user enters a password during Account Setup, Password Change, Password Reset or User Login in ARIN Online. 2. ARIN encrypts the password and sends part of the encrypted password to the Have I been Pwned (HIBP) Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__haveibeenpwned.com_API_v3-23PwnedPasswords&d=DwIGaQ&c=2xyLtJK-6wL-B01m9dqMd9CDbkL-hoZ5ifChpoVJRBA&r=RY5ZOoNF6CKUE-zbyE5VeisOFsxu2hSC5wQeuEurgH8&m=PU2-W-p9904eTkfY3ACK5_ghxyOjFaNw8mbBw2gV5ag&s=dRts4JOWywHFUg2cbHvdUQYniNfopXH1NHinbg1Y7vQ&e= ) and returns all possible matches in their database. (Your actual password is never sent or used in any query.) 3. We compare the full encrypted password to the results sent by HIBP to see if there is a match. 4. If there is a match we will notify the customer. Optional Outcomes We are interested in the community?s thoughts on the possible outcomes when we identify a password that has been exposed in a data breach according to the HIBP service. There are three options: 1. Issue a caution message but allow the password. 2. Issue a warning message and notify the customer that they need to change their password within a defined time period, but not at the current point of login. 3. Issue warning message that requires the customer to select and set a different password immediately. The feedback you provide during this consultation will help inform how we move forward to increase security of ARIN Online for all customers. Thank you for your participation in the ARIN Consultation and Suggestion Process. Please provide comments to arin-consult at arin.net. You can subscribe to this mailing list at: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.arin.net_mailman_listinfo_arin-2Dconsult&d=DwIGaQ&c=2xyLtJK-6wL-B01m9dqMd9CDbkL-hoZ5ifChpoVJRBA&r=RY5ZOoNF6CKUE-zbyE5VeisOFsxu2hSC5wQeuEurgH8&m=PU2-W-p9904eTkfY3ACK5_ghxyOjFaNw8mbBw2gV5ag&s=b8QQ_dNrVsqb7_Grw4eHzqIVBNuFjmHagOR7cO2haE4&e= This consultation will remain open through 5:00 PM ET on 16 March 2021. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ CONFIDENTIALITY NOTICE: This email message and any attachments are for the sole use of the intended recipient(s) and may contain proprietary, confidential, trade secret or privileged information. Any unauthorized review use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please contact the sender by reply email and destroy all copies of the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Outlook-x0qlbxng.png Type: image/png Size: 7479 bytes Desc: Outlook-x0qlbxng.png URL: From owen at delong.com Fri Feb 19 07:21:43 2021 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Feb 2021 04:21:43 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: <8284.1613667959@localhost> Message-ID: > On Feb 18, 2021, at 9:19 AM, William Herrin wrote: > > On Thu, Feb 18, 2021 at 9:06 AM Michael Richardson wrote: >> William Herrin wrote: >>> I don't know the current state of ARIN's account recovery process but >>> unless ARIN first gets religion for it, there's not much point in >>> forcing 2FA in the primary authentication path. "Click this email link >>> to reset your password" is single-factor and not even strong >>> single-factor. >> >> ARIN requires a phone call. > > Hi Michael, > > That's single-factor: control of a phone number. Control of the phone number is ?something you have?. Doesn?t that depend on what they ask for over the phone? I.e. if they validate that the phone number matches the POC record _AND_ confirm some other private piece of information (e.g. SSN, answers to security questions, etc. (something you know). > AT&T defended itself from a lawsuit a year or two ago where someone > lost millions of dollars of bitcoin because a hacker was able to get > AT&T to activate a new phone with their phone number and then use that > to reset the brokerage password. AT&T's position, which the court > accepted, was that cell phone service was not advertised as or secured > to a standard appropriate for authentication thus anyone who relied on > it for such did so at their own risk. As a single-factor token, sure, but as one of multiple factors, I think it can be valid. Owen From mike at iptrading.com Fri Feb 19 11:00:43 2021 From: mike at iptrading.com (Mike Burns) Date: Fri, 19 Feb 2021 11:00:43 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: References: <8284.1613667959@localhost> Message-ID: <022101d706d8$609ccb70$21d66250$@iptrading.com> Does anybody know why ARIN and RIPE are being attacked in this way? Is the purpose merely credential discovery or would access be used in a nefarious way? In ARIN these credentials would not allow for the sale of an address block. But they could allow for rDNS entries that would enable mailing on a hijacked block. And I suppose they could facilitate the leasing out of the block through ROA generation. Any thoughts on the reason behind these recent attacks on two RIRs? Are the attacked usernames targeted in any way, like associated with blocks that aren't currently in use? Maybe if the purpose of the attackers was clear, the security solution would be easier to consider. Regards, Mike Burns IPTrading.com -----Original Message----- From: ARIN-consult On Behalf Of William Herrin Sent: Thursday, February 18, 2021 12:20 PM To: Michael Richardson Cc: Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts On Thu, Feb 18, 2021 at 9:06 AM Michael Richardson wrote: > William Herrin wrote: > > I don't know the current state of ARIN's account recovery process but > > unless ARIN first gets religion for it, there's not much point in > > forcing 2FA in the primary authentication path. "Click this email link > > to reset your password" is single-factor and not even strong > > single-factor. > > ARIN requires a phone call. Hi Michael, That's single-factor: control of a phone number. AT&T defended itself from a lawsuit a year or two ago where someone lost millions of dollars of bitcoin because a hacker was able to get AT&T to activate a new phone with their phone number and then use that to reset the brokerage password. AT&T's position, which the court accepted, was that cell phone service was not advertised as or secured to a standard appropriate for authentication thus anyone who relied on it for such did so at their own risk. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From jsweeting at arin.net Fri Feb 19 14:13:57 2021 From: jsweeting at arin.net (John Sweeting) Date: Fri, 19 Feb 2021 19:13:57 +0000 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <022101d706d8$609ccb70$21d66250$@iptrading.com> References: <8284.1613667959@localhost> <022101d706d8$609ccb70$21d66250$@iptrading.com> Message-ID: <464059D4-A97B-4E58-BADD-E7F41057B0E7@arin.net> Mike, while we are not entirely sure of the motives, you have definitely outlined a few that we are looking at. See Inline: ?On 2/19/21, 11:00 AM, "ARIN-consult on behalf of Mike Burns" wrote: Does anybody know why ARIN and RIPE are being attacked in this way? Is the purpose merely credential discovery or would access be used in a nefarious way? (JS) ARIN believes that the purpose of credential stuffing is for the purpose of using the resources associated with the account in nefarious ways. In ARIN these credentials would not allow for the sale of an address block. (JS) that is correct, the rigorous process and procedure for completing a transfer would not allow for someone that merely has access to an account resources to transfer them. But they could allow for rDNS entries that would enable mailing on a hijacked block. (JS) that is correct as well and yes, we have seen instances of this in the past. We have learned that several "market places" for leasing of resources require proof of control of the IP resources in order to list them. This is one of the "prove you control these blocks" methods. And I suppose they could facilitate the leasing out of the block through ROA generation. (JS) Again correct, we have also confirmed that this is another "proof of control" that is used. Any thoughts on the reason behind these recent attacks on two RIRs? (JS) ARIN continues to capture forensics and will absolutely cooperate with law enforcement agencies when deemed the correct course of action. ARIN is meticulously gathering and logging all forensics associated with these attacks. The numbers are somewhat staggering as noted here in a recent attack: Login Harvesting Attack Metrics Invalid Password: 9,711 Invalid Captcha: 249,205 Invalid Username: 10,999,044 As you can see the attacks are extremely onerous and the amount of data associated with each attack makes it a challenge to identify the true aspirations of the people behind the attacks. We have developed much of the captured data and are currently in the process of analyzing it in order to develop and deploy deterrents to stop this. While we cannot go into specifics there is a significant amount of information captured in order to aid law enforcement agencies to become involved. Are the attacked usernames targeted in any way, like associated with blocks that aren't currently in use? (JS) Still unable to get to that level of detail but it does appear to be true. Maybe if the purpose of the attackers was clear, the security solution would be easier to consider. (JS) ARIN has taken several measures to make these attempts less effective and we are currently coding additional safeguards such as the topic of this consultation. Rest assured that this is of the highest priority to ARIN. Regards, Mike Burns IPTrading.com -----Original Message----- From: ARIN-consult On Behalf Of William Herrin Sent: Thursday, February 18, 2021 12:20 PM To: Michael Richardson Cc: Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts On Thu, Feb 18, 2021 at 9:06 AM Michael Richardson wrote: > William Herrin wrote: > > I don't know the current state of ARIN's account recovery process but > > unless ARIN first gets religion for it, there's not much point in > > forcing 2FA in the primary authentication path. "Click this email link > > to reset your password" is single-factor and not even strong > > single-factor. > > ARIN requires a phone call. Hi Michael, That's single-factor: control of a phone number. AT&T defended itself from a lawsuit a year or two ago where someone lost millions of dollars of bitcoin because a hacker was able to get AT&T to activate a new phone with their phone number and then use that to reset the brokerage password. AT&T's position, which the court accepted, was that cell phone service was not advertised as or secured to a standard appropriate for authentication thus anyone who relied on it for such did so at their own risk. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From mike at iptrading.com Fri Feb 19 14:47:16 2021 From: mike at iptrading.com (Mike Burns) Date: Fri, 19 Feb 2021 14:47:16 -0500 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <464059D4-A97B-4E58-BADD-E7F41057B0E7@arin.net> References: <8284.1613667959@localhost> <022101d706d8$609ccb70$21d66250$@iptrading.com> <464059D4-A97B-4E58-BADD-E7F41057B0E7@arin.net> Message-ID: <028001d706f8$07043010$150c9030$@iptrading.com> Thanks John. For what it's worth, I would guess that the miscreants would not be expecting a long-term access to any blocks brought under control in this manner, and for this reason would want to realize the most revenue possible in a short time. And this probably means spamming. For which rdns has great value. I would put another padlock on rdns changes, is it possible to have staff review changes in rdns delegation in anything like real-time? Regards, Mike -----Original Message----- From: John Sweeting Sent: Friday, February 19, 2021 2:14 PM To: Mike Burns ; 'William Herrin' ; 'Michael Richardson' Cc: arin-consult at arin.net Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts Mike, while we are not entirely sure of the motives, you have definitely outlined a few that we are looking at. See Inline: ?On 2/19/21, 11:00 AM, "ARIN-consult on behalf of Mike Burns" wrote: Does anybody know why ARIN and RIPE are being attacked in this way? Is the purpose merely credential discovery or would access be used in a nefarious way? (JS) ARIN believes that the purpose of credential stuffing is for the purpose of using the resources associated with the account in nefarious ways. In ARIN these credentials would not allow for the sale of an address block. (JS) that is correct, the rigorous process and procedure for completing a transfer would not allow for someone that merely has access to an account resources to transfer them. But they could allow for rDNS entries that would enable mailing on a hijacked block. (JS) that is correct as well and yes, we have seen instances of this in the past. We have learned that several "market places" for leasing of resources require proof of control of the IP resources in order to list them. This is one of the "prove you control these blocks" methods. And I suppose they could facilitate the leasing out of the block through ROA generation. (JS) Again correct, we have also confirmed that this is another "proof of control" that is used. Any thoughts on the reason behind these recent attacks on two RIRs? (JS) ARIN continues to capture forensics and will absolutely cooperate with law enforcement agencies when deemed the correct course of action. ARIN is meticulously gathering and logging all forensics associated with these attacks. The numbers are somewhat staggering as noted here in a recent attack: Login Harvesting Attack Metrics Invalid Password: 9,711 Invalid Captcha: 249,205 Invalid Username: 10,999,044 As you can see the attacks are extremely onerous and the amount of data associated with each attack makes it a challenge to identify the true aspirations of the people behind the attacks. We have developed much of the captured data and are currently in the process of analyzing it in order to develop and deploy deterrents to stop this. While we cannot go into specifics there is a significant amount of information captured in order to aid law enforcement agencies to become involved. Are the attacked usernames targeted in any way, like associated with blocks that aren't currently in use? (JS) Still unable to get to that level of detail but it does appear to be true. Maybe if the purpose of the attackers was clear, the security solution would be easier to consider. (JS) ARIN has taken several measures to make these attempts less effective and we are currently coding additional safeguards such as the topic of this consultation. Rest assured that this is of the highest priority to ARIN. Regards, Mike Burns IPTrading.com -----Original Message----- From: ARIN-consult On Behalf Of William Herrin Sent: Thursday, February 18, 2021 12:20 PM To: Michael Richardson Cc: Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts On Thu, Feb 18, 2021 at 9:06 AM Michael Richardson wrote: > William Herrin wrote: > > I don't know the current state of ARIN's account recovery process but > > unless ARIN first gets religion for it, there's not much point in > > forcing 2FA in the primary authentication path. "Click this email link > > to reset your password" is single-factor and not even strong > > single-factor. > > ARIN requires a phone call. Hi Michael, That's single-factor: control of a phone number. AT&T defended itself from a lawsuit a year or two ago where someone lost millions of dollars of bitcoin because a hacker was able to get AT&T to activate a new phone with their phone number and then use that to reset the brokerage password. AT&T's position, which the court accepted, was that cell phone service was not advertised as or secured to a standard appropriate for authentication thus anyone who relied on it for such did so at their own risk. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From jsweeting at arin.net Fri Feb 19 16:13:58 2021 From: jsweeting at arin.net (John Sweeting) Date: Fri, 19 Feb 2021 21:13:58 +0000 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <028001d706f8$07043010$150c9030$@iptrading.com> References: <8284.1613667959@localhost> <022101d706d8$609ccb70$21d66250$@iptrading.com> <464059D4-A97B-4E58-BADD-E7F41057B0E7@arin.net>, <028001d706f8$07043010$150c9030$@iptrading.com> Message-ID: <469BB89B-6136-4E09-920C-0DB5482A3986@arin.net> All things are in play, to include looking at rDNS management. Sent from my iPhone > On Feb 19, 2021, at 2:47 PM, Mike Burns wrote: > > ?Thanks John. For what it's worth, I would guess that the miscreants would not be expecting a long-term access to any blocks brought under control in this manner, and for this reason would want to realize the most revenue possible in a short time. And this probably means spamming. For which rdns has great value. > > I would put another padlock on rdns changes, is it possible to have staff review changes in rdns delegation in anything like real-time? > > Regards, > Mike > > > -----Original Message----- > From: John Sweeting > Sent: Friday, February 19, 2021 2:14 PM > To: Mike Burns ; 'William Herrin' ; 'Michael Richardson' > Cc: arin-consult at arin.net > Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts > > Mike, while we are not entirely sure of the motives, you have definitely outlined a few that we are looking at. See Inline: > > ?On 2/19/21, 11:00 AM, "ARIN-consult on behalf of Mike Burns" wrote: > > Does anybody know why ARIN and RIPE are being attacked in this way? > Is the purpose merely credential discovery or would access be used in a > nefarious way? > > (JS) ARIN believes that the purpose of credential stuffing is for the purpose of using the resources associated with the account in nefarious ways. > > In ARIN these credentials would not allow for the sale of an address block. > > (JS) that is correct, the rigorous process and procedure for completing a transfer would not allow for someone that merely has access to an account resources to transfer them. > > But they could allow for rDNS entries that would enable mailing on a > hijacked block. > > (JS) that is correct as well and yes, we have seen instances of this in the past. We have learned that several "market places" for leasing of resources require proof of control of the IP resources in order to list them. This is one of the "prove you control these blocks" methods. > > And I suppose they could facilitate the leasing out of the block through ROA > generation. > > (JS) Again correct, we have also confirmed that this is another "proof of control" that is used. > > Any thoughts on the reason behind these recent attacks on two RIRs? > > (JS) ARIN continues to capture forensics and will absolutely cooperate with law enforcement agencies when deemed the correct course of action. ARIN is meticulously gathering and logging all forensics associated with these attacks. The numbers are somewhat staggering as noted here in a recent attack: > > Login Harvesting Attack Metrics > Invalid Password: 9,711 > Invalid Captcha: 249,205 > Invalid Username: 10,999,044 > > As you can see the attacks are extremely onerous and the amount of data associated with each attack makes it a challenge to identify the true aspirations of the people behind the attacks. We have developed much of the captured data and are currently in the process of analyzing it in order to develop and deploy deterrents to stop this. While we cannot go into specifics there is a significant amount of information captured in order to aid law enforcement agencies to become involved. > > Are the attacked usernames targeted in any way, like associated with blocks > that aren't currently in use? > > (JS) Still unable to get to that level of detail but it does appear to be true. > > Maybe if the purpose of the attackers was clear, the security solution would > be easier to consider. > > (JS) ARIN has taken several measures to make these attempts less effective and we are currently coding additional safeguards such as the topic of this consultation. Rest assured that this is of the highest priority to ARIN. > > Regards, > Mike Burns > IPTrading.com > > > -----Original Message----- > From: ARIN-consult On Behalf Of William > Herrin > Sent: Thursday, February 18, 2021 12:20 PM > To: Michael Richardson > Cc: > Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN > Online Accounts > >> On Thu, Feb 18, 2021 at 9:06 AM Michael Richardson wrote: >> William Herrin wrote: >>> I don't know the current state of ARIN's account recovery process > but >>> unless ARIN first gets religion for it, there's not much point in >>> forcing 2FA in the primary authentication path. "Click this email > link >>> to reset your password" is single-factor and not even strong >>> single-factor. >> >> ARIN requires a phone call. > > Hi Michael, > > That's single-factor: control of a phone number. > > AT&T defended itself from a lawsuit a year or two ago where someone lost > millions of dollars of bitcoin because a hacker was able to get AT&T to > activate a new phone with their phone number and then use that to reset the > brokerage password. AT&T's position, which the court accepted, was that cell > phone service was not advertised as or secured to a standard appropriate for > authentication thus anyone who relied on it for such did so at their own > risk. > > Regards, > Bill Herrin > > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN > Member Services Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > From jsweeting at arin.net Fri Feb 19 20:09:20 2021 From: jsweeting at arin.net (John Sweeting) Date: Sat, 20 Feb 2021 01:09:20 +0000 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <469BB89B-6136-4E09-920C-0DB5482A3986@arin.net> References: <8284.1613667959@localhost> <022101d706d8$609ccb70$21d66250$@iptrading.com> <464059D4-A97B-4E58-BADD-E7F41057B0E7@arin.net> <028001d706f8$07043010$150c9030$@iptrading.com> <469BB89B-6136-4E09-920C-0DB5482A3986@arin.net> Message-ID: We also wanted to bring the following article to the attention of the ARIN community as Mike referenced in his first reply: https://www.infosecurity-magazine.com/news/internet-registry-ripe-ncc-warns/ ?On 2/19/21, 4:14 PM, "ARIN-consult on behalf of John Sweeting" wrote: All things are in play, to include looking at rDNS management. Sent from my iPhone > On Feb 19, 2021, at 2:47 PM, Mike Burns wrote: > > Thanks John. For what it's worth, I would guess that the miscreants would not be expecting a long-term access to any blocks brought under control in this manner, and for this reason would want to realize the most revenue possible in a short time. And this probably means spamming. For which rdns has great value. > > I would put another padlock on rdns changes, is it possible to have staff review changes in rdns delegation in anything like real-time? > > Regards, > Mike > > > -----Original Message----- > From: John Sweeting > Sent: Friday, February 19, 2021 2:14 PM > To: Mike Burns ; 'William Herrin' ; 'Michael Richardson' > Cc: arin-consult at arin.net > Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts > > Mike, while we are not entirely sure of the motives, you have definitely outlined a few that we are looking at. See Inline: > > On 2/19/21, 11:00 AM, "ARIN-consult on behalf of Mike Burns" wrote: > > Does anybody know why ARIN and RIPE are being attacked in this way? > Is the purpose merely credential discovery or would access be used in a > nefarious way? > > (JS) ARIN believes that the purpose of credential stuffing is for the purpose of using the resources associated with the account in nefarious ways. > > In ARIN these credentials would not allow for the sale of an address block. > > (JS) that is correct, the rigorous process and procedure for completing a transfer would not allow for someone that merely has access to an account resources to transfer them. > > But they could allow for rDNS entries that would enable mailing on a > hijacked block. > > (JS) that is correct as well and yes, we have seen instances of this in the past. We have learned that several "market places" for leasing of resources require proof of control of the IP resources in order to list them. This is one of the "prove you control these blocks" methods. > > And I suppose they could facilitate the leasing out of the block through ROA > generation. > > (JS) Again correct, we have also confirmed that this is another "proof of control" that is used. > > Any thoughts on the reason behind these recent attacks on two RIRs? > > (JS) ARIN continues to capture forensics and will absolutely cooperate with law enforcement agencies when deemed the correct course of action. ARIN is meticulously gathering and logging all forensics associated with these attacks. The numbers are somewhat staggering as noted here in a recent attack: > > Login Harvesting Attack Metrics > Invalid Password: 9,711 > Invalid Captcha: 249,205 > Invalid Username: 10,999,044 > > As you can see the attacks are extremely onerous and the amount of data associated with each attack makes it a challenge to identify the true aspirations of the people behind the attacks. We have developed much of the captured data and are currently in the process of analyzing it in order to develop and deploy deterrents to stop this. While we cannot go into specifics there is a significant amount of information captured in order to aid law enforcement agencies to become involved. > > Are the attacked usernames targeted in any way, like associated with blocks > that aren't currently in use? > > (JS) Still unable to get to that level of detail but it does appear to be true. > > Maybe if the purpose of the attackers was clear, the security solution would > be easier to consider. > > (JS) ARIN has taken several measures to make these attempts less effective and we are currently coding additional safeguards such as the topic of this consultation. Rest assured that this is of the highest priority to ARIN. > > Regards, > Mike Burns > IPTrading.com > > > -----Original Message----- > From: ARIN-consult On Behalf Of William > Herrin > Sent: Thursday, February 18, 2021 12:20 PM > To: Michael Richardson > Cc: > Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN > Online Accounts > >> On Thu, Feb 18, 2021 at 9:06 AM Michael Richardson wrote: >> William Herrin wrote: >>> I don't know the current state of ARIN's account recovery process > but >>> unless ARIN first gets religion for it, there's not much point in >>> forcing 2FA in the primary authentication path. "Click this email > link >>> to reset your password" is single-factor and not even strong >>> single-factor. >> >> ARIN requires a phone call. > > Hi Michael, > > That's single-factor: control of a phone number. > > AT&T defended itself from a lawsuit a year or two ago where someone lost > millions of dollars of bitcoin because a hacker was able to get AT&T to > activate a new phone with their phone number and then use that to reset the > brokerage password. AT&T's position, which the court accepted, was that cell > phone service was not advertised as or secured to a standard appropriate for > authentication thus anyone who relied on it for such did so at their own > risk. > > Regards, > Bill Herrin > > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN > Member Services Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From owen at delong.com Fri Feb 26 14:50:08 2021 From: owen at delong.com (Owen DeLong) Date: Fri, 26 Feb 2021 11:50:08 -0800 Subject: [ARIN-consult] Consultation on Password Security for ARIN Online Accounts In-Reply-To: <464059D4-A97B-4E58-BADD-E7F41057B0E7@arin.net> References: <8284.1613667959@localhost> <022101d706d8$609ccb70$21d66250$@iptrading.com> <464059D4-A97B-4E58-BADD-E7F41057B0E7@arin.net> Message-ID: Has ARIN considered exponential time locking access from IPs generating excessive authentication failures? (e.g. if an IP address sources 10 authentication errors in an hour, block that IP address from further attempts for 5 minutes on the first occurrence, 10 minutes if it happens again, 20 minutes for a third incident, etc.). Any successful authentication should reduce the repeat count by one. It?s very unlikely anyone legitimate is going to source 10 failed authentications in an hour, and even if they do, a 5 minute lockout isn?t going to be all that painful. Owen > On Feb 19, 2021, at 11:13 , John Sweeting wrote: > > Mike, while we are not entirely sure of the motives, you have definitely outlined a few that we are looking at. See Inline: > > ?On 2/19/21, 11:00 AM, "ARIN-consult on behalf of Mike Burns" on behalf of mike at iptrading.com > wrote: > > Does anybody know why ARIN and RIPE are being attacked in this way? > Is the purpose merely credential discovery or would access be used in a > nefarious way? > > (JS) ARIN believes that the purpose of credential stuffing is for the purpose of using the resources associated with the account in nefarious ways. > > In ARIN these credentials would not allow for the sale of an address block. > > (JS) that is correct, the rigorous process and procedure for completing a transfer would not allow for someone that merely has access to an account resources to transfer them. > > But they could allow for rDNS entries that would enable mailing on a > hijacked block. > > (JS) that is correct as well and yes, we have seen instances of this in the past. We have learned that several "market places" for leasing of resources require proof of control of the IP resources in order to list them. This is one of the "prove you control these blocks" methods. > > And I suppose they could facilitate the leasing out of the block through ROA > generation. > > (JS) Again correct, we have also confirmed that this is another "proof of control" that is used. > > Any thoughts on the reason behind these recent attacks on two RIRs? > > (JS) ARIN continues to capture forensics and will absolutely cooperate with law enforcement agencies when deemed the correct course of action. ARIN is meticulously gathering and logging all forensics associated with these attacks. The numbers are somewhat staggering as noted here in a recent attack: > > Login Harvesting Attack Metrics > Invalid Password: 9,711 > Invalid Captcha: 249,205 > Invalid Username: 10,999,044 > > As you can see the attacks are extremely onerous and the amount of data associated with each attack makes it a challenge to identify the true aspirations of the people behind the attacks. We have developed much of the captured data and are currently in the process of analyzing it in order to develop and deploy deterrents to stop this. While we cannot go into specifics there is a significant amount of information captured in order to aid law enforcement agencies to become involved. > > Are the attacked usernames targeted in any way, like associated with blocks > that aren't currently in use? > > (JS) Still unable to get to that level of detail but it does appear to be true. > > Maybe if the purpose of the attackers was clear, the security solution would > be easier to consider. > > (JS) ARIN has taken several measures to make these attempts less effective and we are currently coding additional safeguards such as the topic of this consultation. Rest assured that this is of the highest priority to ARIN. > > Regards, > Mike Burns > IPTrading.com > > > -----Original Message----- > From: ARIN-consult On Behalf Of William > Herrin > Sent: Thursday, February 18, 2021 12:20 PM > To: Michael Richardson > Cc: > Subject: Re: [ARIN-consult] Consultation on Password Security for ARIN > Online Accounts > > On Thu, Feb 18, 2021 at 9:06 AM Michael Richardson wrote: >> William Herrin wrote: >>> I don't know the current state of ARIN's account recovery process > but >>> unless ARIN first gets religion for it, there's not much point in >>> forcing 2FA in the primary authentication path. "Click this email > link >>> to reset your password" is single-factor and not even strong >>> single-factor. >> >> ARIN requires a phone call. > > Hi Michael, > > That's single-factor: control of a phone number. > > AT&T defended itself from a lawsuit a year or two ago where someone lost > millions of dollars of bitcoin because a hacker was able to get AT&T to > activate a new phone with their phone number and then use that to reset the > brokerage password. AT&T's position, which the court accepted, was that cell > phone service was not advertised as or secured to a standard appropriate for > authentication thus anyone who relied on it for such did so at their own > risk. > > Regards, > Bill Herrin > > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN > Consult Mailing List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN > Member Services Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the ARIN Consult Mailing > List (ARIN-consult at arin.net ). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: