Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect and disable weak or compromised passwords #725

Open
danielcompton opened this issue Aug 21, 2019 · 1 comment
Open

Detect and disable weak or compromised passwords #725

danielcompton opened this issue Aug 21, 2019 · 1 comment
Labels

Comments

@danielcompton
Copy link
Member

danielcompton commented Aug 21, 2019

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 #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.

@danielcompton
Copy link
Member Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant