Force MFA on all users

[grizz]

Based on recent discussions at NANOG/MWPS and the more recent compromised user issues, I believe it is time to officially consider enforcing MFA for all users.

The main issue I see would be that users would need to update existing scripts to use API_KEYs instead of user/pass, which I think is acceptable.

For implementation, I think we give a grace period of 6 months to a year, let people know, and then enable it.

PeeringDB is an increasingly important part of the interconnection ecosystem, and we should protect it accordingly.

[job]

Sounds like a plan that’ll save us headaches in the future

[mcmanuss8]

+1

I agree it'll be painful. Should we consider doing it in phases where we attack web only users first then users who have made API calls? Or target users who have logged in recently first (since they'll be more likely to do it)?

[martinhannigan]

From a web user perspective, we could consider getting rid of email auth. It seems we are talking about the UI as well?

A slight nit then on topic. The attachment view/process seems non-intuitive. I'm sure there was a reason but ultimately it would be great to see it work with the following which ever made sense and made us most secure:

• Successfully authenticate with USERID and PASS
• Be presented with the MFA options -- text message -- phone call [ or auth app, or.. ]

Use email only for password reset.

I'm certain there are bigger challenges with eliminating email and moving to a high quality scheme or MFA, but I'm not sure how much more of a heavy lift it is or if there is a replacement option for phone call that combined with SMS would be just as strong. However, instead of doing this again later (hello RIR's) it could be worth doing it right and final (for as long as final is in Internet time).

Process wise, forcing the setup at a valid login for a period of N would seem similar to any improvements so perhaps not so terrible after all. Then cost.

$0.02

On Fri, Jun 21, 2024 at 2:34 PM mcmanuss8 @.***> wrote:

+1

I agree it'll be painful. Should we consider doing it in phases where we attack web only users first then users who have made API calls? Or target users who have logged in recently first (since they'll be more likely to do it)?

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1634#issuecomment-2183264532, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQVO54ZFPJGQXEUAANDZIRW4LAVCNFSM6AAAAABJWLIHLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBTGI3DINJTGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[netravnen]

The main issue I see would be that users would need to update existing scripts to use API_KEYs instead of user/pass, which I think is acceptable.

Stepped roll-out? (example)

1. Write a FAQ on docs.peeringdb.com about the change,
2. implement warnings user/pass in api is going away,
   • Warning emitted as http header for API calls / a warning as part of the returned result body,
   • Ensure 3rd party software developers of major pieces (IXP-Manager, Peering Manager, and similar) are aware and can assist with alerting users of their software this important change is happening at PDB,
   • collect metrics on which users still use user/pass,
     • send out targeted emails to the users mailbox about the upcoming change,
     • emit a warning upon affected users logging into www.peeringdb.com,
   • mail to pdb-announce,
3. implement #1584,
4. implement user notification (~heads-up) that MFA will be required in the future (for users with no enabled MFA method),
5. disable support for user/pass in the api, require the use of API_KEYs,
6. require MFA for ORG admins,
7. require MFA for ORG members,
8. require MFA for everybody (even accounts with no active affiliation).

[arnoldnipper]

+1