[ARIN-consult] [ARIN-Consult] Consultation on Expanding 2FA Options for ARIN Online

Adam Thompson athompso at athompso.net
Tue Jan 24 16:40:21 EST 2023


I don’t know myself whether there are any users with disabilities that would preclude the use of TOTP; my guess is there aren’t, whether because those people don’t exist or whether TOTP isn’t a problem – dunno.

I meant only exactly what I said, that I hope someone has put more than a few seconds’ thought about that into this.  Legal ramifications COULD occur, albeit with low likelihood.

The main reason to allow SMS 2FA, despite its known weaknesses, is simply that the entire world is very much not ready for FIDO/TOTP yet.  As Chris said, requiring only FIDO/TOTP is an excellent way to alienate people, especially the US and Canada, where non-SMS-based 2FA is still uncommon.  I have precisely one system that requires non-SMS, non-email 2FA, and that was forced upon my org by external requirements.  I really do not want to add more.  Even the email-based 2FA systems have a high chance of causing a catch-22 situation.
IMO, the least-bad 2FA system is one that lets me authenticate via whatever system I can right at the moment.  If my AS has been hijacked, will I be able to receive email?  SMS would probably still work, as would TOTP.  If my phone is broken, what options do I have for logging in?

A perfectly secure system is a perfectly unusable system.  The balance between security and usability has been axiomatic in computing since before I was born.  It’s not really up for debate right now.

I DO NOT WANT SECURITY that presents any significant chance of denying me access to my own accounts and resources.  SMS or email-based 2FA schemes are a giant PITA, but both are fairly easily recoverable when (not if) I lose access to them.  Are they good 2FA?  No.  Absolutely not.  Are they better than nothing?  Yes.

This entire discussion feels like https://xkcd.com/538/ to me.  If someone wants access to my ARIN resources, one of the easier ways in would be to physically threaten me or my family, and the best 2FA implementations in the world do nothing (AFAIK) to protect against that.  The specific technique or technology involved won’t make any difference.

The people who insist that SMS shouldn’t be allowed, that email shouldn’t be allowed, that there should be a maximum of 3 TOTPs or keys registered – you are alienating me, a user of ARIN resources.  You are driving me away from the community.  And when the pain of logging in to ARIN exceeds the pain of not having up-to-date SWIPs or contact info, guess what’ll happen?  The database is already riddled with garbage/obsolete information, adding more security is going to make that situation worse, not better.

The goal should be to add the minimum increment of security that satisfies the business objective.  Unfortunately, the business objective here seems to have been “add 2FA” which is a technical objective, not a business objective.

Someone with the technical skills of your grandmother is probably the ARIN contact of record for some resource or other – and it’s likely a job they inherited and have no idea what to do with.  Can you imagine getting your grandparents to deal with 2FA?

Unhappy about the whole process from start to finish, as it’s very clearly (to me) the tail wagging the dog.  A solution in search of a problem, if you prefer that wording.  Just enforcing password length > 20 would have increased security without needing 2FA.  (Obviously not increased *enough* to satisfy everyone, but my statement stands.)

BTW: having been the technical architect for a cellular telephone company in Canada, yes, I know exactly how easy it is and isn’t to divert SMS at the network/carrier level.  It’s a non-zero risk, but it’s *still better than nothing*.
-Adam


From: Ross Tajvar <ross at tajvar.io>
Sent: Tuesday, January 24, 2023 2:51 PM
To: Adam Thompson <athompso at athompso.net>
Cc: Richard Laager <rlaager at wiktel.com>; arin-consult at arin.net
Subject: Re: [ARIN-consult] [ARIN-Consult] Consultation on Expanding 2FA Options for ARIN Online

On the topic of hypothetical compromise - my ARIN account hasn't been compromised, but other accounts protected with SMS 2FA have been. I have had money stolen via that vector. So it's a real concern for me. Maybe my ARIN account isn't valuable enough to hack, but my employer's is.

I don't think we should disregard real attack vectors that definitely do happen in the real world just because they're uncommon and the mitigations are inconvenient to some people. I also acknowledge the importance of disability accommodation; however, I doubt that disallowing email (or SMS) 2FA would be an issue there (though I welcome a correction if I'm wrong).

On Tue, Jan 24, 2023 at 3:36 PM Adam Thompson <athompso at athompso.net<mailto:athompso at athompso.net>> wrote:
Since I have a nearly magical ability to damage every authentication device I've ever been issued (including my phone - this one has lasted over a year, which I think is av record), I'm highly doubtful of any scheme that *assumes* any authenticator is durable.  I would like a *minimum* of 3 active - one in my pocket, one in a locked drawer at work, one in a secure spot at home or in my car or somewhere else.

Double + 1 that number to account for rollover, and I'll already want to have up to 7 registered at times, for any account that's super-critical.

Yes, that's about how many copies of physical keys for locks that I like to get made, because I lose those, too.

Could I live with a limit of 10? Yeah, probably.

Which is more important: keeping bad actors out, or letting authorized users in?

All I'm hearing during this discussion is protecting accounts against hypothetical compromise (with IIRC no evidence this has ever happened, or any negative outcome has occurred previously) with no consideration of people who have unusual needs.

(Some of those needs, definitely not all, are referred to in American law as "disabilities", btw.  I hope someone at ARIN has thought about how the proposed 2FA scheme complies with the ADA?)

-Adam

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: ARIN-consult <arin-consult-bounces at arin.net<mailto:arin-consult-bounces at arin.net>> on behalf of Richard Laager <rlaager at wiktel.com<mailto:rlaager at wiktel.com>>
Sent: Tuesday, January 24, 2023 2:22:43 PM
To: arin-consult at arin.net<mailto:arin-consult at arin.net> <arin-consult at arin.net<mailto:arin-consult at arin.net>>
Subject: Re: [ARIN-consult] [ARIN-Consult] Consultation on Expanding 2FA Options for ARIN Online

On 1/24/23 12:56, Adam Thompson wrote:

Why on earth would you set a hard-coded limit?  It's not like an additional database table is expensive.
While, in general, I understand this sentiment (real world cardinality is usually: 1, 2, or many), I do see two counterpoints. Even speaking in general, it is sometimes useful to define a limit for testing purposes. If you say, "We support 5", then you are hopefully actually testing 5.

In this particular situation, I think the following argument is even more relevant:

On 1/24/23 14:02, Tim Lyons via ARIN-consult wrote:
In terms of allowing the registration of multiple hardware security keys, I suggest allowing a maximum of 3 keys to be registered. This provides backup options in case a user loses or misplaces their primary key but encourages users to be cognizant of deleting old keys that have been lots or become non-functional.

--

Richard
_______________________________________________
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/20230124/0fc4c123/attachment-0001.htm>


More information about the ARIN-consult mailing list