danielcompton
commented
5 years ago @titanous points out that if we check on every login/deploy for a compromised password, then we don't need to do any batch scanning. Either an attacker or the user trying to login with that password would be forced to reset their password first by email, which hopefully only the user has access to.
Context
A common attack vector for compromising the development supply chain is checking if a breached password works on other services. For example, https://news.ycombinator.com/item?id=20747283.
Proposal
We should look at detecting passwords that have been found in breaches and disabling them, requiring users to set a new password. We can use Have I Been Pwned's API to check for this. For any new signups or password changes, we should look at increasing password length requirements from 8 to 10.
We could also proactively check the top 1,000/10,000 passwords for all Clojars users, reset any existing accounts with weak passwords, and email people if this happened. As passwords are hashed, we'd need to run the hash algorithm against every password we check which is (by design) slow. This would be a more aggressive move, but given what is happening in other package ecosystems, seems like it could be a good proactive move.
We get plaintext user passwords when people are deploying to Clojars, this would be another good opportunity to check if their passwords haven't been breached. If they have, I would suggest we reset the password, include an explanation in the response, and require them to choose a new password before allowing them to deploy.
Other thoughts
Something I'm less sure about is whether we should store if we have verified a password is not in the breached list, or whether we check the breached status every time we see a password? If we store password status
not-breached?, we would want to store the timestamp that we checked this. This would let us avoid making the check once we know a user's password is secure.There is some precedent for resetting user passwords, see https://github.com/clojars/clojars-web/issues/47 and https://groups.google.com/group/clojure/browse_thread/thread/5e0d48d2b82df39b for more details.
These and other Clojars security related patches may be eligible for Google's Patch Rewards or Mozilla's MOSS awards, though as Clojure is fairly niche this is not at all clear. In it's favour, many large companies with JVM codebases have Clojars setup in Nexus/Artifactory, so a compromise of Clojars could affect the wider JVM ecosystem, not just Clojure users.