[members-discuss] two-factor authentication mandatory

I really like the idea of having good support for "Two Factor" Auth!

That said, with this setup it depends a lot on personal preference. I am 
also really against "forcing" change, encouraging is the much better way.
We should allow "choice" in type of mechanism, and only offering options 
that can be supported in the long term. Preferably most options should 
be "vendor neutral".

So even tho its slightly less secure at times (like email 2fa)

I'd like to suggest the following:

- RipeNCC Access Account Creation: Change the dialouge to have 2FA 
avalible in a way where users have to "opt-out" of it instead of "opt-in".
(We could potentially make email-2fa the default option. From wich users 
can either "opt-out" completely or upgrade to a more secure type of 2FA).

- LIR/Member: When a LIR/Member is created we could look into including 
one Hardware Token in the welcome package. This could be part of the 
one-time cost of becoming a LIR. (The use of the token should be 
suggested, but not mandatory).

regards



On 1/11/24 16:58, Ben Cartwright-Cox via members-discuss wrote:
> It's worth pointing out that 2FA methods is not a "winner takes all",
> Some people have FIDO keys deployed in production and are happy with
> it, others use TOTP with or without mobile phone apps, There is even
> room for email TOTP.
>
> All of these methods improve the status quo dramatically and will help
> LIRs not repeat the same incident that happened to Orange Spain.
>
> Let's not have perfect be in the way of good.
>
> On Thu, Jan 11, 2024 at 3:29 PM Jochen Bern <ripe at binect.de> wrote:
>> On 11.01.24 14:35, Mike B wrote:
>>> I would like to hear other views on this request to the RIPE NCC.
>> First and foremost, my views depend *a lot* on whether we're talking
>> about *additional* methods, or a set(?) of methods things may be cut
>> back to in the long run.
>>
>>> However the current state of RIPE NCC MFA is not suitable to be made
>>> mandatory. Namely the TOTP requires a phone (sms) or TOTP App. I would
>>> like to see support for FIDO2 keys, if this is not possible OTP via
>>> email would be a compromise.
>> A FIDO key is a bit of hard- or software, just like TOTP tokens or apps
>> are, and a MUA is as well; it's pretty much implied by all of those
>> filling the slot of "something you have" in the 2FA concept.
>>
>> E-mail has the advantage of it being very, *very* unlikely that someone
>> trying to log into the RIPE SSO does not have it available already, but
>> on the flip side, both e-mail- and SMS-based 2FA have proven to be
>> rather circumventable lately. (FWIW, according to what I've read, FIDO
>> seems to be the most resilient one in that regard.)
>>
>> On 11.01.24 14:48, Mark Janssen via members-discuss wrote:
>>> TOTP can be done without phones or phone apps... it just needs the
>>> shared secret and a HMAC fucntion
>> (... and a sufficiently well-synchronized clock for an input.)
>>
>> On 11.01.24 14:53, Ben Cartwright-Cox via members-discuss wrote:
>>> I agree that FIDO support would be extremely appreciated, Lots of orgs
>>> already have such keys issued to employees
>> We distributed TOTP tokens¹ to most of our staff a little while ago -
>> which we can now scrap because everyone wants us to do TOTP the
>> "authenticator" way² these days. If you want to try and convince our
>> management of setting up another 2FA hardware budget, be my guest. :-/
>>
>> ¹ Single secret burnt into token by manufacturer, to be uploaded to
>>      service and associated with account by sysadmin
>> ² Individual secrets created on demand by server, to be downloaded
>>      into "token" (under a new "account"/"config"/... to be created
>>      along with it)
>>
>> On 11.01.24 14:55, Oleksij Samorukov via members-discuss wrote:
>>> But +1 for FIDO2 implementation, is a very popular standard with
>>> many implementations on the market. And it should be easy to
>>> implement on the backend/frondent side, implementation is very
>>> straightforward with many examples all-around.
>> ... *hope* you're right there. Last time I tried (with a USB-based
>> OnlyKey token and my Linux work machine), things looked rather similar
>> to this:
>>
>> https://learn.microsoft.com/en-us/entra/identity/authentication/fido2-compatibility#linux
>>
>> Kind regards,
>> --
>> Jochen Bern
>> Systemingenieur
>>
>> Binect GmbH
>>
>> --
>> Jochen Bern
>> Systemingenieur
>>
>> T  +49 6151 9067-231
>> E  jochen.bern at binect.de
>>
>>
>> Binect GmbH
>> Brunnenweg 17
>> 64331 Weiterstadt
>> www.binect.de
>>
>> Folgen Sie uns:
>> https://www.linkedin.com/company/18314056/admin/
>> https://www.xing.com/pages/binectgmbh
>> https://www.facebook.com/binect/
>> https://www.youtube.com/channel/UC-vhGKk6YU1qPbeh0Nx768g
>>
>> Geschäftsführung: Dr. Frank Wermeyer, Michael Imiolczyk
>> Unternehmenssitz: Weiterstadt
>> Register: Amtsgericht Darmstadt, HRB 94685
>> Umsatzsteuer-ID: DE 221 302 264
>>
>> _______________________________________________
>> members-discuss mailing list
>> members-discuss at ripe.net
>> https://mailman.ripe.net/
>> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripencc%40benjojo.co.uk
> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://mailman.ripe.net/
> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-members%40sebastian-graf.at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xCB3F9792B5ACD96C.asc
Type: application/pgp-keys
Size: 3935 bytes
Desc: OpenPGP public key
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20240111/3d0d9389/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20240111/3d0d9389/attachment.sig>