[ARIN-consult] Consultation on Password Security for ARIN Online Accounts

[Matt Harris]

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 <bill at herrin.us> wrote:

> On Tue, Feb 16, 2021 at 8:11 AM ARIN <info at arin.net> 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: <https://lists.arin.net/pipermail/arin-consult/attachments/20210216/1dbb07de/attachment.htm>