Better define MFA support

[omerlh]

Take NPM as an example - there is an option to configure MFA, and you can enforce it per package (see the docs). But once MFA is enabled, you cannot use a CI to publish your packages - publish is done automatically. I think this should be reflected somehow, WDYT?

[evilpacket]

I was thinking the same thing for defining strong authentication or package signing. npm does package signing internally but we don't currently do author package signing. What constitutes strong authentication? NIST definition?

With regarding to not being able to publish from CI should we take into account usability as a factor in this or is it purely about security? It certainly matters in the grand scheme of things but it doesn't necessarily if it's a pure security play as the initial draft of the project suggests.

[omerlh]

Pure security is meaningless, if the user must choose between usability and security, they will favor usability. I faced the same decision, and I chose security - but this is a very high downside. Now, each time I need to publish a new package to NPM I need to do it manually - and this is an error-prone process.

Also, package signing is another aspect of usability. Dockerhub support signing via notary. Good luck with setting this up :) It's so complex, I got a headache just from reading the docs...

[mkonda]

Haha. You are both awesome for jumping in.

My thinking on MFA was to make it so that guessing a password would not be such an easy way to get into the supply chain. If adding MFA makes CI/CD hard, maybe that needs a separate item - like an integration key / secret.

I agree about usability being crucial.

For Strong authentication I was assuming password complexity. It makes sense to add notifications around pushes as well.

My goal here is not to get everyone to do everything possible, but to try to hone in on some basic best practices and see if we can nudge some of the package managers to implement them. Maybe we can even help...

[omerlh]

Yep, I'm so willing to help because we will be able to change the industry only if we get enough awareness of this project.

[stevespringett]

Do we want to define MFA, or do we want to define ownership? MFA is easy, ownership is much harder.

Sonatype does a few interesting things if you want to publish a package.

• They require a group id (not optional) for every package
• The use DNS for group id proof of ownership
• They require GPG for package signing and will reject unsigned or unvalidated signatures
• MFA is not a requirement for publishing

These simple things, although not foolproof nor comprehensive, provide some assurance that you do not get with any other ecosystem.

[omerlh]

IMO MFA is a bit easier to manage compared to GPG. GPG requires you to securely store the private key while MFA requires having Google authenticator. I'm not expecting from everyone to sign packages. I expect almost everyone to have MFA.

[stevespringett]

I actually expect both with a preference for code signing. There are regulatory requirements in place in many industries globally that have this requirement. Some orgs choose to compile from source directly and sign it themselves to get around the repositories deficiencies in this area. As more supply chain people move into the software space (and see SCA and are appalled), they will expect a certain level of assurance via authenticity verification. MFA cannot provide that once something is published, but can help guard the account info (from takeover, etc).

[mkonda]

I see these as separate and complementary. MFA seems easy to do. Signing is harder but needed for certain scenarios as you point out.

[mkonda]

@omerlh how can we clarify this better? Any suggestions on language?

[omerlh]

I think there are 2 parts to MFA:

• Support (e.g. users can enable it for their profile)
• Enforcement (e.g. as an admin I can require that all users will enable it)

There is also the usability aspect, as with the NPM example - you can have both CI/CD and MFA...