<div dir="auto">We are generally *always* reviewing and recommending our customers enable 2fa on everything they use, and look for alternatives (when possible) for things that don’t. The problem is so much broader than people think. They don’t necessarily need to take, or change your data…if you are a high value target, then they may be able to use the data in your account as an attack vector to gain access to their ultimate target. </div><div dir="auto"><br></div><div dir="auto">Anyone in control of high value resources should be taking additional steps to protect their accounts. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 25, 2022 at 12:39 PM William Herrin <<a href="mailto:bill@herrin.us">bill@herrin.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Wed, May 25, 2022 at 8:41 AM Ross Tajvar <<a href="mailto:ross@tajvar.io" target="_blank">ross@tajvar.io</a>> wrote:<br>
>> I remain unconvinced that inflicting 2FA on me solves a real problem that actually exists.<br>
><br>
> I'm not sure why you (and others) seem to think 2FA 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.<br>
<br>
It requires orgs which rarely interact with ARIN to keep track of THE<br>
cell phone which has the 2FA app. Oh, and the phone has to still be<br>
working. Otherwise, every interaction with ARIN for such orgs starts<br>
with a painful and likely insecure account recovery procedure.<br>
<br>
<br>
>> Perhaps requiring better (non-dictionary) passwords on accounts that don’t have 2FA would be a solution more targeted at the actual problem.<br>
><br>
> How would ARIN judge the complexity of a password? As far as I'm aware, checking if it uses dictionary words is non-trivial.<br>
<br>
The last time I worked on this problem I followed the NIST guidance:<br>
check the proposed password against a large list of known compromised<br>
passwords (e.g.<br>
<a href="https://github.com/danielmiessler/SecLists/tree/master/Passwords" rel="noreferrer" target="_blank">https://github.com/danielmiessler/SecLists/tree/master/Passwords</a>,<br>
<a href="https://drive.google.com/drive/folders/14xB93b5YveOzCY7EuDrcL5ElpN-HCNse" rel="noreferrer" target="_blank">https://drive.google.com/drive/folders/14xB93b5YveOzCY7EuDrcL5ElpN-HCNse</a>)<br>
and reject it if found there. It took me a couple of days to find a<br>
decent data source and write an app around it. It was rather trivial.<br>
<br>
Dictionary attacks are ineffective against a site which rejects the<br>
overwhelming majority of passwords in the attack dictionary.<br>
<br>
<br>
> 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.<br>
<br>
Among the reasons I'm against mandatory 2FA.<br>
<br>
Regards,<br>
Bill Herrin<br>
<br>
-- <br>
William Herrin<br>
<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a><br>
<a href="https://bill.herrin.us/" rel="noreferrer" target="_blank">https://bill.herrin.us/</a><br>
_______________________________________________<br>
ARIN-Consult<br>
You are receiving this message because you are subscribed to the ARIN Consult Mailing<br>
List (<a href="mailto:ARIN-consult@arin.net" target="_blank">ARIN-consult@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-consult" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-consult</a> Please contact the ARIN Member Services<br>
Help Desk at <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div>