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

[David Bass]

I completely agree with the multiple methods, or a backup method in case
the primary is not available.

“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.”

On Wed, May 25, 2022 at 5:33 PM Adam Thompson <athompson at merlin.mb.ca>
wrote:

> 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.
>
> <https://www.google.com/maps/search/100+-+135+Innovation+Drive+%0D%0A+Winnipeg,+MB+R3T+6A8?entry=gmail&source=g>
>
>
>
> -Adam
>
>
>
> *Adam Thompson*
>
> Consultant, Infrastructure Services
>
> [image: MERLIN]
>
> 100 - 135 Innovation Drive
> <https://www.google.com/maps/search/100+-+135+Innovation+Drive+%0D%0A+Winnipeg,+MB+R3T+6A8?entry=gmail&source=g>
>
> Winnipeg, MB R3T 6A8
> <https://www.google.com/maps/search/100+-+135+Innovation+Drive+%0D%0A+Winnipeg,+MB+R3T+6A8?entry=gmail&source=g>
>
> (204) 977-6824 or 1-800-430-6404 (MB only)
>
> https://www.merlin.mb.ca
>
> 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> wrote:
>
>
>
>
>
> On May 25, 2022, at 08:13 , Matt Harris <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 <help at netfire.net>*
>
>
> 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> 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).
> 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: <https://lists.arin.net/pipermail/arin-consult/attachments/20220527/01169001/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13827 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20220527/01169001/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 359 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20220527/01169001/attachment-0003.png>