<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-CA" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I’ve recently (within the last year) had to deal with insurance companies changing the ground rules for an entire industry that I service. You’re partially but not entirely correct, vis-à-vis the
scenario I had here: having SOME additional security beyond userid and password is now required, but it doesn’t have to be what we’re calling 2FA in this discussion. (We
<i>should</i> be referring to “MFA” instead, but that battle is long-since lost.) Here the question is enforcing MFA on logins to ARIN. This is not a “typical corporate system” and lateral movement within the network is irrelevant. There’s also little to
no confidential information behind ARIN credentials. Some of the data must be protected against unwanted alteration or deletion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Specific technologies should not be the requirement – that’s how you get the US Congress passing laws mandating AES-128 encryption exclusively!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The requirement should be phrased as something like “User account IDs and passwords must not be, by themselves, sufficient to establish a newly-authenticated access to ARIN systems from an unknown
public IP address.” One obvious solution is “2FA” using SMS/email/TOTP/FIDO, but there other options exist.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The added factor does not need, necessarily, to be a device from which you can read a code. I
<i>loathe</i> systems that give you a printed grid with keywords where you locate and enter a word from the reference card, but that’s a non-device-based system that never runs out of battery or signal and satisfies any MFA requirement about as well as TOTP.
It’s more secure than SMS or email, doesn’t require anyone to master Yet Another Technology, but is very rarely deployed.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I use the Microsoft Authenticator to address my issues in the way you describe, as it’s easy to install on a backup phone. The backup phone no longer powers on. So I also have a Yubikey locked
away in the office where it *<b>hopefully</b>* can’t bit-rot, but I need to physically be in the office to reset/fix anything. I also have LastPass available to me for this purpose. The UIs are embarrassingly bad if you have more than one or two things tied
to them, and fall squarely into the “my grandmother would not be able to deal with this” category.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I <b>strongly</b> disagree with the idea that every ARIN account-holder is, or should be, a technologist, never mind that they should be at the forefront of security technology. I get paid to stay
moderately current on how to build networks using basic tools – spending time learning how to use TOTP is, very literally, something that will get me called on the carpet – that sort of thing has already happened to me within the last year! (Yes, I work for
government… hopefully private industry isn’t quite as inflexible.) If you want ARIN to drag all its customers along on a security journey, we need MASSIVELY better documentation covering MULTIPLE common systems/tools.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I can find several examples local to me where the receptionist is now the ARIN contact person. I know several where a line-of-business administrator is the ARIN contact. I know of multiple ARIN
resource holders who do not employ <i>anyone</i> technical (in the IT sense). Yes, those orgs rely on consultants, but now we’re effectively making business decisions for them, and I do not support that either.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">At this point, I feel like I’m shouting into the wind (or maybe I’m the old man shouting at clouds…) – as if everyone else has drunk the 2FA Kool-Aid™ and can’t see anything wrong with it. There
are things wrong with computers and networks, why can’t there be something wrong with MFA, too? I’m perfectly OK with enabling SMS and Email for MFA because
<i>it’s better than what we have now</i>. No, it’s not perfect. But if you’re arguing that SMS and Email are “too insecure”, you’ve clearly never heard the saying “the perfect is the enemy of the good”. BABY STEPS. Get SMS and Email 2FA today, for the luddites
or laggards in the crowd, and deprecate them about 2 years from now.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Otherwise, give me decent documentation that shows me, screen by screen, step by step, how to enable TOTP with LastPass,
<b>and</b> MS Authenticator, <b>and</b> whatever Google’s thing is called, <b>and</b> some other free product; then
<b>ALSO</b> let me register a decent number of TOTP systems (yes, I admit 10 should be more than adequate for any realistic scenario I can imagine) and we’re probably good. But the documentation is sorely lacking today. And you’re expecting people who don’t
know what TOTP even <b>is</b> to be on-board with this? Nope.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">-Adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Richard Laager <rlaager@wiktel.com>
<br>
<b>Sent:</b> Tuesday, January 24, 2023 5:00 PM<br>
<b>To:</b> Adam Thompson <athompso@athompso.net><br>
<b>Cc:</b> arin-consult@arin.net<br>
<b>Subject:</b> Re: [ARIN-consult] [ARIN-Consult] Consultation on Expanding 2FA Options for ARIN Online<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 1/24/23 15:40, Adam Thompson wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</blockquote>
<p>2FA is a business objective these days. If you don't use 2FA for email, VPN, and Domain Admin access, you are basically uninsurable for cyber risk right now (and have been for a year or more). I can't speak to exactly what underwriters would require of ARIN
for ARIN's own services, so maybe this isn't a hard requirement today, but it's not unreasonable to think that it might be now or in the near future.<o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Just enforcing password length > 20 would have increased security without needing 2FA. (Obviously not increased *<b>enough</b>* to satisfy everyone, but my statement stands.)<o:p></o:p></p>
</div>
</blockquote>
<p>A (the?) major goal of 2FA is to make it so that if your password is compromised, the attacker still cannot authenticate as you. No amount of password length or complexity helps with that.<o:p></o:p></p>
<p>In the typical corporate example... If I get your corporate password, without 2FA, I can login as you to every server / network device / whatever. With 2FA required, I can't login to anything (without also compromising your second factor). In other words,
2FA contains the initial breach, rather than letting the attacker run wild through the whole infrastructure. Requiring a unique password for every single device would accomplish the same thing without 2FA, but 1) that's not practical to enforce, and 2) that's
worse for usability. So 2FA it is.<o:p></o:p></p>
<p><o:p> </o:p></p>
<p>As to your particular troubles with breaking/losing authenticators... Get something like 1Password, set it up on multiple devices (which you're surely going to do anyway: phone, computer, etc.), and store your ARIN TOTP 2FA in there. You'll improve both
security and convenience.<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Richard<o:p></o:p></pre>
</div>
</body>
</html>