Their system looks similar to how publishing of plugins works in the Jenkins project:

  • Accounts are protected by passwords chosen by users.

  • Individual contributors have permission to release the components they maintain.

  • The components they release are used by millions of developers around the world to deliver their software.

In other words, weak passwords are a problem for us just as much as for NPM, and what happened to them could happen to us.

To address this problem, the Jenkins security and infra teams have recently collaborated on a password audit. The audit covered all accounts with permissions to upload plugins and components, and on accounts with other levels of privileged infrastructure access. We ran brute force tools on salted password hashes of those accounts looking for "weak" passwords — passwords present in a set of publicly available password lists we chose for this audit.

We checked the password of every qualifying account for every unsafe password rather than trying to match them to any previous password leaks' email/password pairs. Users with weak account passwords were notified via email a few weeks ago and were asked to change their password to something stronger.

We performed the same checks over the previous weekend, but this time we only checked the passwords of accounts whose passwords were deemed weak during our first check. We then invalidated the password of any account whose password was still not considered "strong" (i.e. their password was unchanged or had been changed to another weak password). Users of those accounts will need to request a password reset before signing in again.

We plan to implement further safeguards, including improving the account management app at to reject weak passwords. If you’re interested in helping the security team make Jenkins more secure, let us know on the jenkinsci-dev mailing list, or request to join the security team.

About the Author
Daniel Beck

This author has no biography defined. See social media links referenced below.