Send ARIN-consult mailing list submissions to
arin-consult@arin.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.arin.net/mailman/listinfo/arin-consult
or, via email, send a message with subject or body 'help' to
arin-consult-requ...@arin.net
You can reach the person managing the list at
arin-consult-ow...@arin.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-consult digest..."
Today's Topics:
1. Re: Consultation on Requiring Two-Factor Authentication (2FA)
for ARIN Online Accounts (Peter Beckman)
2. Re: Consultation on Requiring Two-Factor Authentication (2FA)
for ARIN Online Accounts (Peter Beckman)
3. Re: Consultation on Requiring Two-Factor Authentication (2FA)
for ARIN Online Accounts (Gary Buhrmaster)
4. Re: Consultation on Requiring Two-Factor Authentication (2FA)
for ARIN Online Accounts (Peter Beckman)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 May 2022 22:56:22 -0400
From: Peter Beckman <beck...@angryox.com>
To: Owen DeLong <o...@delong.com>
Cc: Gary Buhrmaster <gary.buhrmas...@gmail.com>,
"<arin-consult@arin.net>" <arin-consult@arin.net>
Subject: Re: [ARIN-consult] Consultation on Requiring Two-Factor
Authentication (2FA) for ARIN Online Accounts
Message-ID: <2cf0363c-374b-78a2-4a3-162f9230a...@angryox.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On Wed, 25 May 2022, Owen DeLong wrote:
> Well? ARIN can?t detect that until your next (successful) login, anyway.
Fair, agreed. This also requires ARIN to constantly be updating their
"disclosed password" list, which seems like that could also fall through
the cracks.
>> 2FA eliminates the risk of static data disclosure becoming a security
>> liability.
>
> Until the particular seed/algo/etc. for the 2FA is compromised (such as a
> Stolen hardware token, or the time when a batch of SecurID tokens were
> Compromised, or?
>
> Less frequent than password compromises? Sure. Sufficiently less frequent
> to be worth the inconvenience for securing something that isn?t a
> particularly attractive target? Not so sure.
What would it take to convince you?
Is there anything that would?
Is it just to inconvenient for you to accept that it will improve
security that you just want to keep throwing out arguments to not change
your own processes?
Password compromises: weekly
2FA compromises: none
Can you point to any 2FA disclosures or breaches that occurred because the
shared secret was also compromised? I could not find a single one. I
honestly wanted to, just for you, Owen! It is theoretically plausible but
either hasn't happened or has but has not been documented.
Here's what I could find:
- Coinbase 2FA Flaw using SMS contributed to breach (SMS not TOTP)
https://www.cpomagazine.com/cyber-security/coinbase-hack-attributed-to-a-multi-factor-authentication-flaw-that-allowed-scammers-to-steal-cryptocurrency-from-6000-accounts/
- How to hack 2FA
https://www.csoonline.com/article/3620223/how-to-hack-2fa.html
(none suggested stealing the secret as an easy way)
- Breaches 2FA could have prevented
https://www.tyntec.com/blog/breaches-multifactor-authentication-could-have-prevented
- Linode 2016 non-breach but 2FA implementation changed
https://www.linode.com/blog/linode/security-investigation-retrospective/
- RSA SecurID 2011 Breach (phishing and hack of RSA, not TOTP)
https://en.wikipedia.org/wiki/RSA_SecurID#March_2011_system_compromise
I could not find anything but theoretical "the shared secret would be
disclosed in a breach." And this is true, but ARIN would need to be
hacked, not another website.
ARIN could sufficiently protect accounts with 2FA by implementing a
microservice like Linode and store the 2FA shared secrets in a secure
enclave apart from other authentication and customer data, which would
require hackers to target all of ARIN and breach MULTIPLE systems, which
exponentially increases the difficulty of reaching a successful breach.
Much more likely for a flaw in coding to allow someone into an account
without 2FA.
Beckman
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beck...@angryox.com https://www.angryox.com/
---------------------------------------------------------------------------
------------------------------
Message: 2
Date: Fri, 27 May 2022 23:26:26 -0400
From: Peter Beckman <beck...@angryox.com>
To: Owen DeLong <o...@delong.com>
Cc: Ross Tajvar <r...@tajvar.io>, "<arin-consult@arin.net>"
<arin-consult@arin.net>
Subject: Re: [ARIN-consult] Consultation on Requiring Two-Factor
Authentication (2FA) for ARIN Online Accounts
Message-ID: <173ad94d-7611-98ee-b3e2-f1c91184f...@angryox.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Just to be explicit about a TOTP 2FA login flow:
1. Visit site
2. Enter Username & Password
3. Look at phone (or use app on computer you are using) to get or enter
6-digit code
4. Enter 6-digit code in text box
5. Press submit
The 6-digit code is generally valid for 30 seconds, servers generally
accept the previous, current, and next code to account for clock skew.
Clocks skewed further than that would prevent a valid code from being
generated.
On Wed, 25 May 2022, Owen DeLong wrote:
>> What exactly are you using then to log into ARIN?!?
>
> In many cases, Lynx on a busy-box based system.
Is this because of an accessibility reason that you use a text-based web
browser?
A raspberry pi-based computer in your pocket would be an ideal system to
carry on your person to avoid using untrusted computers.
Have you found a Password Manager for Lynx? If so, you should see if it
supports TOTP. If not, there are text-based TOTP code generators, I'd be
happy find them for you. I will compile and build them for you!
I'd be very curious why you use Lynx instead of a graphical-based browser.
Or a generally GUI OS.
> I?m not always logging in from my desktop. I?m not even always logging in
> from a machine I generally control.
Untrusted computers are called that because they cannot be trusted.
Entering ARIN credentials there risks your account being stolen. 2FA would
prevent your stolen creds from being used by an unauthorized 3rd party.
> What?s the support for TOTP from a shared system in, say a Library or a
> Maker Space? How am I supposed to secure that?
You should always have a trusted device with you. If not, you should never
log into your accounts on a shared or untrusted system, ever.
> I am hearing it, I?m just saying that one size doesn?t fit all and that
> mere OS support isn?t the only issue here.
Multiple sizes, operating systems, software, apps have been presented.
What size fits you, other than the status quo?
> I have yet to see a good solution for putting a TOTP capability on a
> machine I can?t generally trust.
Nobody said to do this, and you should not. You should always carry a
trusted device to generate the TOTP code. If you do not, you should not
log into your accounts when using a untrusted terminal.
> That?s kind of like installing your SSH private keys on servers at a
> client site if you?re a consultant? Not too bright.
You would never install the shared secret on an untrusted server. You
don't need to. You're just reading the 6-digit code, which could be
installed on multiple devices convenient for you, and entering it along
with your username and password.
> Someone who reuses passwords in this day and age probably deserves
> whatever happens to them.
It's not just the user who is harmed. In this case, ARIN is harmed. If the
user represents the company, the company is harmed. It will cost everyone
involved time and money.
Beckman
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beck...@angryox.com https://www.angryox.com/
---------------------------------------------------------------------------
------------------------------
Message: 3
Date: Sat, 28 May 2022 03:36:23 +0000
From: Gary Buhrmaster <gary.buhrmas...@gmail.com>
To: "<arin-consult@arin.net>" <arin-consult@arin.net>
Subject: Re: [ARIN-consult] Consultation on Requiring Two-Factor
Authentication (2FA) for ARIN Online Accounts
Message-ID:
<CAMfXtQz=pRzYjYJxgPjk8B-dz=49peTaYTYDt-7y=zntfzm...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Tue, May 24, 2022 at 4:46 PM ARIN <i...@arin.net> wrote:
>
> **Background**
>
First up, I am not a DMR, nor do I expect I will ever be
one at this point. So, technically, I have (in my opinion)
at best, "observer" status in ARIN. That said, since
ARIN asked for opinions, I have one (there is an old
adage, be careful what you ask for, for you may get it,
and as with many of my opinions, you may not like mine).
I look at this consultation as, in fact, two different issues
(2FA and SMS usage), and believe those issues should
be addressed separately (I will do so below).
Background
The NIST 800-63 suite of guidelines provide a useful
framework to come to some common understandings
and approaches, and provides advice for operating in
best (or at least good) practices. I recommend everyone
read the suite of guidelines.
While ARIN is not obliged to follow the NIST guidelines
well run organizations should be expected to document
their reasoning and needs to diverge from the NIST
guidance.
I will not strictly adhere to the NIST terms in my
comments below, but I believe the usage is aligned
with the intent.
Issue: SMS
While NIST acknowledges the wide prevalence of orgs
using SMS / PSTN for verification, the latest guidance
has finally (they initially proposed doing so five or so
years ago) moved to discourage SMS / PSTN factors,
calling SMS a "Restricted Authenticator". That means
that ideally new implementations should not use it, and
organizations should start to make plans to migrate
away from it (perhaps required to do so on very short
notice). In addition, it is expected that orgs that use
restricted authenticators must add in additional
notifications and safeguards (which are, themselves,
somewhat complicated to validate (I have no idea how
to check if the phone number entered is a real mobile
with MFA enabled, or a ITSP VoIP phone which
accepts SMS (or the number has been ported to a
ITSP VoIP phone after the number was entered, or
if the number is set to ring in multiple locations), for
example, although that might actually be a solved
problem and simply reflects my lack of knowledge
in that specific use case of knowing where a SMS
really ends up)).
At this point, it is my belief that ARIN should not
adopt SMS / PSTN for a new factor ("Just say NO
to SMS!") and if another factor type is desired to add
to the current list to complete the work they have already
agreed to do, which is implementing FIDO2. All the
leading tech companies have agreed that (and are
putting substantial efforts behind) FIDO2 as the way
towards a future passwordless world (and I, for one,
look forward to a day that I don't *need* to have various
password management processes for hundreds of
different site passwords, although I suspect my lifetime
will be shorter than the date of that being finally
accomplished, and there will always continue to be
valid use cases where simple pin/password identification
is acceptable due to the low value/risk of the information
retrieved).
Issue: 2FA
Generically, multifactor. NIST discusses both identity
assurance levels and risk evaluations.
It is an *org's* responsibility to determine *their* risk to
*their* resources. And those orgs should be able to
require identity verification to *their* level of required
assurance. Some orgs may be fine with a password,
some may choose to require a pin/password and (say)
a TOTP value, or even require a pin/password, and a
TOTP and biometric data. Their information, their
risk evaluation, their choice.
ARINs responsibility should be to make sure that
orgs are aware of their responsibility to make their
own choices, and to enable orgs to enforce those
choices for ARIN online accounts that access *their*
resources in ARIN's registry.
And the action requested may change the level
requirements in some organizations' thoughts. I
suspect many reading this comment (if anyone is
still reading at this point) have encountered sites
where doing something like changing your profile
requires one to up their level of identity assurance
(too many sites still use SMS) at the time of the
more impactful action.
I would be surprised to learn that ARIN has the
capability to allow an organization to differentiate
their identity assurance requirements for every
different action on ARIN online (using Owen's
example, looking at tickets might just require a
password, while modifying org data might need
the TOTP pin) which means at best an org might
be able to specify the level of assurance required
for an ARIN online account to access any of their
resources.
For those who have ARIN online accounts that can
access multiple orgs resources, I would guess the
easiest implementation will be to force the most
restrictive org's level of identity assurance for login,
and require one to have multiple ARIN online
accounts if one desires to only use a lower assurance
level for those orgs that have not required a higher
level if identity assurance, but some future
implementation should be considered where the
ARIN online account login allows one to login without
MFA, but a message of the form "Your view is currently
restricted because one/more orgs require an additional
level of identity assurance. Please login using MFA
to enable access to all your organizations data"). That
may not be a worthwhile investment in resources, but
at least it is out there as a possible future option.
Note that while organizations should be allowed
to specify their minimal level of identity assurance
for their resources, individuals should be able to
choose a higher level requirement for themselves
(there are individuals who, due to their specifics,
are, or may be, chosen targets, and who believe
they should always use MFA (I'll use as an example
a theoretical CEO of an Internet Registry, whose
account might be considered at greater risk of
being seen as a useful target if compromised and
would logically expect to be individually targeted
and should want to require MFA "for the good
in the innertubes" (FD: Google keeps telling me
my account should require MFA because of access
to various resources and commit access to various
repos, even though my account actually already
does require MFA (and I use it), but at least
Google is trying to do the right thing)).
So, I do not believe ARIN should *require* 2FA,
it should provide the infrastructure to allow orgs
to require it if *they* so choose, based on *their*
risk evaluation.
Now that I have mostly rejected most of the proposal,
I think it is only fair to offer a few top of the head (not
fully fleshed out) alternatives to consider:
If ARIN wants to encourage MFA adoption, implement
FIDO2 as agreed, and send out two FIDO2 keys to all
ARIN online account holders who control resources
under an RSA and who requests them (I'll bet most
orgs can afford the keys, and would even prefer they
do their own sourcing, but why give some orgs yet
another reason to not use MFA? Make it easy).
FD: I was an early adopter of U2F, and have more
FIDO2 keys than one can shake a stick at, and
whenever I can, I use the keys for the site(s) I have
access to.
Any change to an ARIN online account, or by an
ARIN online account, should allow both the online
account, and the impacted organization the ability
to be notified (both to the old and new contact
details). "The phone number associated with your
online account has been changed. If you did not
perform this action, contact ARIN immediately".
"The ARIN online account which has access to your
organizational data has been updated. If you do
not approve of this action, contact ARIN...".
While time based forced password changes are
also discouraged by NIST, require all ARIN online
accounts that do not have MFA enabled by a
certain date to change their password before next
use where ARIN will be able to (at least) ensure
that password is not (currently) in one of the
many lists of known compromised passwords
(one can brute force any password with enough
time, and the list of compromised passwords
is added to all the time but a fair number of the
brutes will use the various known password
dictionary sets). I suppose if you want to be
especially annoying, require a password change
every six months if the account does not use MFA
(although I do not really think that is a good thing).
If implementing proper MFA is currently considered
too hard, outsource the MFA support to companies
such as okta, duo, or others (review Gartner's
quadrants), which allows one to specific exactly
what level identify assurance is required for the
transaction being performed and authenticate
appropriately.
If not already done, add a captcha challenge to
multiple failed password attempts against an
account (if you fail nnn times, you are going to
get slowed down just a bit as you have to identify
the ships/trains/automobiles). Multiple different
IP sources should also trigger the challenge (yes,
I hate captcha as much as the next person, maybe
more, but they do have some benefit of training
a company's self driving AI to not drive into the
train (which is generally considered a bad thing)).
Gary
------------------------------
Message: 4
Date: Sat, 28 May 2022 00:12:22 -0400
From: Peter Beckman <beck...@angryox.com>
To: Gary Buhrmaster <gary.buhrmas...@gmail.com>
Cc: "<arin-consult@arin.net>" <arin-consult@arin.net>
Subject: Re: [ARIN-consult] Consultation on Requiring Two-Factor
Authentication (2FA) for ARIN Online Accounts
Message-ID: <3a5ee2c-1d0-42ee-7755-214a50f57...@angryox.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Excellently researched, well written, and yes I read it all, even past the
point where you wondered. :-) Thanks Gary!!j
I still disagree with your conclusion that ARIN should allow orgs to choose
whether or not to use 2FA.
ARIN "owns" the resources. Members are assigned portions of these
resources. The resources can be taken away.
Theft, modification, or general malfeasance of any member's account and
resources will ALWAYS require ARIN's resources, time, and money to correct
and repair.
I think of ARIN resources like someone else's car. The owner let you borrow
it, but if you crash or damage it, it is the owner of the car that is
inconvenienced the most, and now has a less valuable asset, and must invest
the time to fix it, cannot use it while it is being fixed, pays for a
rental during repair, etc. While the borrower maybe pays out the financial
cost (maybe) but loses no time nor value.
When ARIN requires 2FA to manage critical account resources, they are
protecting ARIN's assets that have been designated to you and allow you to
manage.
They are protecting ARIN from their weakest security link: humans.
ARIN requiring 2FA for all accounts reduces or eliminates ARIN's cost of
cleaning up the mess after a member's account is breached.
Can someone at ARIN weigh in with a story about the cost to ARIN of a
breached ARIN account? I assume it has happened, and thus this discussion.
Beckman
On Sat, 28 May 2022, Gary Buhrmaster wrote:
>
> So, I do not believe ARIN should *require* 2FA,
> it should provide the infrastructure to allow orgs
> to require it if *they* so choose, based on *their*
> risk evaluation.
>
>
>
>
> Now that I have mostly rejected most of the proposal,
> I think it is only fair to offer a few top of the head (not
> fully fleshed out) alternatives to consider:
>
> If ARIN wants to encourage MFA adoption, implement
> FIDO2 as agreed, and send out two FIDO2 keys to all
> ARIN online account holders who control resources
> under an RSA and who requests them (I'll bet most
> orgs can afford the keys, and would even prefer they
> do their own sourcing, but why give some orgs yet
> another reason to not use MFA? Make it easy).
> FD: I was an early adopter of U2F, and have more
> FIDO2 keys than one can shake a stick at, and
> whenever I can, I use the keys for the site(s) I have
> access to.
>
> Any change to an ARIN online account, or by an
> ARIN online account, should allow both the online
> account, and the impacted organization the ability
> to be notified (both to the old and new contact
> details). "The phone number associated with your
> online account has been changed. If you did not
> perform this action, contact ARIN immediately".
> "The ARIN online account which has access to your
> organizational data has been updated. If you do
> not approve of this action, contact ARIN...".
>
> While time based forced password changes are
> also discouraged by NIST, require all ARIN online
> accounts that do not have MFA enabled by a
> certain date to change their password before next
> use where ARIN will be able to (at least) ensure
> that password is not (currently) in one of the
> many lists of known compromised passwords
> (one can brute force any password with enough
> time, and the list of compromised passwords
> is added to all the time but a fair number of the
> brutes will use the various known password
> dictionary sets). I suppose if you want to be
> especially annoying, require a password change
> every six months if the account does not use MFA
> (although I do not really think that is a good thing).
>
> If implementing proper MFA is currently considered
> too hard, outsource the MFA support to companies
> such as okta, duo, or others (review Gartner's
> quadrants), which allows one to specific exactly
> what level identify assurance is required for the
> transaction being performed and authenticate
> appropriately.
>
> If not already done, add a captcha challenge to
> multiple failed password attempts against an
> account (if you fail nnn times, you are going to
> get slowed down just a bit as you have to identify
> the ships/trains/automobiles). Multiple different
> IP sources should also trigger the challenge (yes,
> I hate captcha as much as the next person, maybe
> more, but they do have some benefit of training
> a company's self driving AI to not drive into the
> train (which is generally considered a bad thing)).
>
>
>
> Gary
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN Consult
> Mailing
> List (ARIN-consult@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 i...@arin.net if you experience any issues.
>
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beck...@angryox.com https://www.angryox.com/
---------------------------------------------------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
ARIN-consult mailing list
ARIN-consult@arin.net
https://lists.arin.net/mailman/listinfo/arin-consult
------------------------------
End of ARIN-consult Digest, Vol 90, Issue 27
********************************************
