[dspillett]

If you find a reused password, how do you let the user know though? If I got a "your account is vulnerable" message I'd ignore it as junk like all the other ones I get pretty much daily. You could force a change next time the user logs to your interactive interface, but many users won't do that for some time.

The best approach is probably to disable the account completely until an interactive login is made and a password reset can be forced but some would be up in arms about the inconvenience caused: you can't just allow a simple reset as the login could be coming from an attacker not the original user, an extra channel will need to be used to verify the identity. You might just have to leave the account locked forever and expect the user to create a new one - but now you have the old account and its content which may be used as a dependency of many projects which now break, unnecessarily if there hasn't been a login by a nefarious type.

[yebyen]

You could send that notification, invalidate any client tokens, and also disable the compromised password forcing the user to re-authenticate through their email address, a-la password reset, and I guess also verify they aren't using the same password again.

You wouldn't lock the account forever, the point is to establish that the person whose password was compromised knows, that the password is not the only factor which is used to regain access to the account, and to ensure that your service (rubygems) and its downstream users are not compromised as well as a result of the breach.

Any groaning about the inconvenience caused by disabling account access until the password is changed, can be simply shrugged away in favor of security concerns, with a link to this story about rest-client.

By the time you have learned the user's plaintext password, their account may already have been compromised. There's a case to make that you disable all downloads of any gems that might be compromised from the account until you've verified they aren't. That might be over the top, especially for popular projects as now we are talking serious inconvenience affecting potentially thousands or more of downstreams.

It's a sticky situation, since you don't really know how long that password has been in the open for hackers to use and abuse once you've discovered it in a password dump.

[josephwegner]

Heroku did this about a year ago. They have a list of known pwned passwords (probably haveibeenpwned, but honestly I'm not sure), and disallow accounts to use those passwords. When that change was implemented, any account using a pwned password had that password expired.

https://status.heroku.com/incidents/1625

(source: I work for Heroku Support)

[marcus_holmes]

If a gem maintainer is re-using a known-compromised password they have absolutely zero right to be annoyed at the "inconvenience" of having to reset their password to something that isn't compromised.

RubyGems has a responsibility to its users and community here. It (like npm) needs to take this stuff seriously.

[ecnahc515]

In other sites I know that actually implement this, they simply lock your account/force a reset so you can't login with the existing credentials.

[eli]

Presumably you'd use whatever procedure you use for a lost password?

But simply forcing a password change at the next login after detecting an insecure password would not unduly burden anyone and would be better than doing nothing.

[tinus_hn]

> but some would be up in arms about the inconvenience caused

Sometimes you have to have your priorities straight. If you found the password, someone else can find it.

[llamataboot]

Glassdoor emailed me this week with such an email. We found that your password was leaked, we have disabled your account and signed you out of all devices, you need to create a new password to login.