[ARIN-consult] Consultation on Requiring Two-Factor Authentication (2FA) for ARIN Online Accounts

Wed May 25 17:33:31 EDT 2022

The problem I have with MFA boils down to this:

  *   Everyone has a reasonably convenient “forgot my password” feature/link/process that takes minutes, not hours.
  *   Almost no-one has a reasonably convenient “lost my token” feature/link/process (…yet).  Those that do can take many hours or days.

I’ve seen arguments along the lines of “well, just don’t lose your authenticator/token/key/thingy”, but I’ve been locked out of MFA-secured accounts and had to go through onerous, time-consuming processes to regain access, I think 4 times? within my memory.  One of those times was not my fault in any way, created a very large problem with significant lasting consequences, and was utterly irresoluble until the token situation was manually resolved by someone else literally inventing a new process in real-time.

Hardware tokens fail: misplacing it, irretrievable loss (e.g. down a sewer grate, into a fire, etc.), physical damage (car tire, in one case), electrostatic damage, premature battery or component failure, clock skew, I’ve seen them all.
Software authenticators fail: uninstalling the app inadvertently (or deliberately), corrupting the app (usually inadvertent), new app update causes it to crash (but only for 2 or 3 people, making diagnosis impossible), forgetting the master password to the app, losing (or losing access to) the device containing the app, I’ve seen all of those, too.

Any MFA system that does not permit multiple simultaneous enrolled modes of authentication – which today seems to be the vast majority of them – causes more problems that it solves.

I do NOT dispute the need to move away from simple userid/password authentication, but please, please, please, at least let users protect themselves from themselves.  Allow enrolment of multiple keys, multiple TOTP authenticators, multiple phone#s or emails to receive one-time codes, multiple FIDO keys, etc.

I’m going to keep harping on this as long as I keep losing/damaging/destroying/corrupting MFA tokens, both hard and soft.  Right now, my employer applies MFA via a very-large-company’s-authenticator; to mitigate what I see as an enormous risk, I have the authenticator loaded on a backup phone that’s reasonably accessible so I’m never 100% dead in the water.  Relatively few authenticators let me do this, in my experience.  I can’t share TOTP keys between phones with this particular software, for some reason, using a corporate account.  I’ve already had to use that backup phone once, while responding to a customer-down event – not a time when I want to be locked out of my systems.

MFA/MFA mitigates one set of risks but introduces another.  If those new risks aren’t managed/addressed/mitigated, we’ll just exchange one set of problems for a different set of problems.  They’re not that difficult to mitigate, as long as it’s included in the design.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca<https://www.merlin.mb.ca/>
[cid:image002.png at 01D87051.47981240]Chat with me on Teams<https://teams.microsoft.com/l/chat/0/0?users=athompson@merlin.mb.ca>

From: ARIN-consult <arin-consult-bounces at arin.net> On Behalf Of Ross Tajvar
Sent: Wednesday, May 25, 2022 10:41 AM
To: Owen DeLong <owen at delong.com>
Cc: <arin-consult at arin.net> <arin-consult at arin.net>
Subject: Re: [ARIN-consult] Consultation on Requiring Two-Factor Authentication (MFA) for ARIN Online Accounts

I remain unconvinced that inflicting MFA on me solves a real problem that actually exists.
I'm not sure why you (and others) seem to think MFA is so incredibly inconvenient. In my experience, it only takes a few extra seconds, or a few extra clicks/taps depending on how it's set up. The added overhead really is very small.

Perhaps requiring better (non-dictionary) passwords on accounts that don’t have MFA would be a solution more targeted at the actual problem.
 How would ARIN judge the complexity of a password? As far as I'm aware, checking if it uses dictionary words is non-trivial. And even then, a sufficiently long passphrase using dictionary words is pretty secure (vs a short one) - I don't think it makes sense to penalize users for that.

On Wed, May 25, 2022 at 11:35 AM Owen DeLong via ARIN-consult <arin-consult at arin.net<mailto:arin-consult at arin.net>> wrote:

On May 25, 2022, at 08:13 , Matt Harris <matt at netfire.net<mailto:matt at netfire.net>> wrote:

<image541905.png>
Matt Harris
|
VP of Infrastructure
816‑256‑5446
|
Direct
Looking for help?
Helpdesk<https://help.netfire.net/>
|
Email Support<mailto:help at netfire.net>
[https://netfire.net/Flag-United-States-of-America.jpg]
We build customized end‑to‑end technology solutions powered by NetFire Cloud.
On Wed, May 25, 2022 at 2:13 AM Owen DeLong via ARIN-consult <arin-consult at arin.net<mailto:arin-consult at arin.net>> wrote:
I’m not in favor of requiring MFA. I agree that SMS MFA is pretty awful, but all forms of MFA come with a variety of inconveniences.

With an account that goes back to the beginnings of ARIN online, I’ve never had a security problem with my ARIN online account, so I think that MFA is a solution looking for a problem here.

I know that’s not a popular view among the more security conscious, but the reality is that security should be commensurate with what is being protected. Let users who think their account warrants such additional measures opt in. Let those of use who feel that our passwords are adequate continue in that manner.

Owen

Owen,
The problem is that compromised ARIN accounts can result in issues that don't just impact the owner of the account that held those resources. Compromised ARIN accounts with resources can potentially adversely impact us all in terms of upticks in spam and the resulting management burdens, at the very least, and potentially in other (perhaps even thus far unforeseen) ways as well.

I disagree… If my ARIN account is compromised, I’m going to get notified of any changes made. (So far, that hasn’t happened). I know exactly where to go to get those changes reverted quickly.

My account is associated with resources, but I remain unconvinced that inflicting MFA on me solves a real problem that actually exists.

I do agree with your statement "security should be commensurate with what is being protected." Thus, I would consider that we perhaps continue to allow accounts without control of any resources to continue without requiring MFA, only requiring it when resources are allocated. An ARIN account with control of nothing, or perhaps just contact records for SWIP'd space, etc, is not one that is a huge hazard to the community at large imho compared to one that controls ASNs or IPv4 and IPv6 resources.

Perhaps requiring better (non-dictionary) passwords on accounts that don’t have MFA would be a solution more targeted at the actual problem.

Owen

_______________________________________________
ARIN-Consult
You are receiving this message because you are subscribed to the ARIN Consult Mailing
List (ARIN-consult at arin.net<mailto: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<mailto:info at arin.net> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20220525/822c2579/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13827 bytes
Desc: image001.png
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20220525/822c2579/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 359 bytes
Desc: image002.png
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20220525/822c2579/attachment-0003.png>