[ARIN-consult] ACSP Consultation: Advanced Security Features for ARIN Online

[Michael Richardson]

ARIN <info at arin.net> wrote:
    > These suggestions include:

    >    * 2017.1: Two-factor functionality improvement:
    > https://www.arin.net/participate/community/acsp/suggestions/2017-1/

I would find remember this browser for 30 useful.
I would like to know which browsers have this enabled, and be able to clear it.

    >    * 2018.22: Align ARIN password policy with current NIST SP800-63
    > recommendations:
    > https://www.arin.net/participate/community/acsp/suggestions/2018-22/

YES, YES, YES! PLEASE.

    >     * 2019.14: Implement FIDO2 (WebAuthn) for ARIN Online:
    > https://www.arin.net/participate/community/acsp/suggestions/2019-14/

This is a very good idea.  Please go in this direction.

    > Based on this community input as well as suggestions received through
    > other channels, we are opening a consultation to solicit feedback on a
    > number of potential security improvements that are under consideration.
    > We are specifically interested in your thoughts on a number of specific
    > suggestions, listed below:

    >    * ARIN uses challenge questions to verify users who are seeking to
    > restore access to their ARIN Online user account and to complete other
    > actions. It has been suggested that we eliminate the use of challenge
    > questions for customer account verification in favor of other security
    > measures.

I'm unclear what the other security measures would be.

    >    * Utilizing a personal passcode and/or SMS push codes to a mobile
    > device for password resets and other account actions

I'm unclear if this is intended to be one of them?
I'm unclear if a personal passcode is something that would be in cleartext in
the database, like the idiots at the banks do.

    >    * Requiring the use of Two-factor Authentication (2FA) on all
    > accounts, or allowing Admin Points of Contact (POCs) to control
    > permissions on access to their Organization Records to only allow access
    > from associated POCs who have 2FA on their user accounts

I think start with "allowing", even "encouraging"
Maybe even "encouraging" by eventually charging a premium if you don't have it.
Also, it would be good to mark PoCs that do not have it in a public way, so
that one can know that the POC might not be compromised more easily.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20200416/a63a2881/attachment.sig>