Password reuse and credential stuffing | Hacker News Reader

Password reuse and credential stuffing

troyhunt.com

163 pointsdeverton42 comments

We see credential stuffing quite a lot, with attacks varying from the blatantly obvious (1000s of requests in a minute, to the login page, from the same IP, with a scripting UserAgent like python-requests) to highly distributed attacks across 100s of IPs with a random but current useragent. While some malicious folk do this all manually and write their own scripts, tools like those mentioned in Troy's post are pretty common. One mentioned that I'd like to call out is SentryMBA - this tool is easily adapted to any business via a shareable config, written by anyway. Want to know if your service is probably affected or targeted? Google "Sentry MBA" + your businesses name. There are trading forums for these configs, and they range from banks and big businesses, to CRMs and utility services.

SentryMBA also has the ability to scare certain information on a successful login, helping to identify those key accounts that'll earn you more on the black market, such as recent successful orders on Amazon, or a high number of points on Starbucks accounts.

If you've got a business with an online login page, it's well worth checking the logs these types of attacks, to see if any of your users or even employees need to have their passwords reset after being successfully popped from a credential stuffing attack.

> We see credential stuffing quite a lot

Thanks for sharing. Super interested to know what line of work you are in?

I don't know what his day job is, but is side project, Breach Canary, has just been bookmarked for use in my own side project!

Edit:

"Incredibly unique canaries personalised for your business. Should they ever be reached or discovered on the Internet, you will be the first to find out, allowing you to be proactive in protecting your real customers – the ones which matter."

I work in the UK for a large telecoms provider, who I'd like to think are pretty good when it comes to security and monitoring. Take a look through the Sentry MBA configs and I'm sure you'll see a tonne of names you recognise, including my employer.

In regards to my side project, as mentioned below, it's something which should hopefully helps businesses spot when their user data has been leaked, so that they can be proactive in their investigations and alerting customers to take a look at their passwords. Hope to get a first draft out soon!

Shouldn't we just stop using email/password or username/password entirely? It's already relying on the single point of failure being the users email account, because that is where you send your password reset emails. Just add a simple requirement to passwords: 1) user can't choose them and 2) they are single use. Now you don't need to store them in a database.

If an attacker controls my email account then they basically control all my other accounts too.

So how many here tend to not even try to remember passwords, and instead just always hit "forgot password" to log into a site?

Why isn't that the default? I.e. why aren't all passwords single use? I just enter my email, the site generates a secret and sends it to my email account and that's it. It might sound like a hassle - but personally I think it's less of a hassle than using a password manager (I use LastPass and their browser integration is more cumbersome than a copy & paste from inbox!)

That was the thought behind Mozilla's BrowserID/Persona. It worked very well, but the true problem has always been adoption by vendors.

Medium did this and it is horrible. Your suggestion solves nothing as you already considered, email bring a single point of failure. So why would anyone sign into a completely different service (for most people that being signed into Google which has its own baggage) just to use an app?

1. Sending emails is not very secure

2. Delegating your authentication to a 3rd party is probably not a very good idea

3. You still need to use a password somewhere e.g. accessing your emails, it can't be mitigated all the way down

4. Increasing the importance of social media accounts / email and allowing walled gardens to act as gatekeepers to services is annoying at best and very harmful at worst if you are concerned about your data

Isn't Oauth delegating your authentication to a third party, and which is generally regarded as a good idea?

It's all about trust. If you trust the 3rd party more then it's good. That could be because the authentication provider has more resources to devote to things like intrusion detection. A separate service also isolates your credentials from the various services.

Downsides include telling that 3rd party every time you sign in and putting all your access rights in one place.

Oauth is an authorization protocol, not an authentication protocol

> 1. Sending emails is not very secure

Agreed. This is a stopgap measure until there is some agreed-upon standard for 2FA that doesn't involve email or text messages.

> 2. Delegating your authentication to a 3rd party is probably not a very good idea

Again, agree. This is of course assuming that everyone has an email provider of the gmail kind that they are both comfortable with trusting with everything and that it will always be available. That's a pretty bold assumption - but I think it's a pretty common one.

> 3. You still need to use a password somewhere e.g. accessing your emails, it can't be mitigated all the way down

It delegates the problem to a place you can trust, where you use a 2FA app or even a physical key, or at worst, a huge password of the kind you can remember ONE of, but not one per service.

> 4. Increasing the importance of social media accounts / email and allowing walled gardens to act as gatekeepers to services is annoying at best and very harmful at worst if you are concerned about your data

Yes, I realize the irony in trading the security of my data in 100 sites for storing it at google. It's a tradeoff I'm willing to do however, lacking some better solution (such as sites actually switching to using some standardized authentication method with physical tokens or similar).

Your points are all invalidated by the mere fact that everyone already uses email for authentication. What do you think the "forgot my password" link does? The GP's flow just makes it more explicit.

How is it invalidated that you need the password mechanism to access your emails? Why would you put resources into annoying your users to sign into their email accounts too every time they want to use your service? It is a very bad design imo.

Yes, password reset can be abused, but doing it all the time I would consider a security hole.

I guess the bullet points aren't the ones that are invalidated, it's the argument that sending a secret key over email to sign in is worse for security than having a password.

It's not worse, it's strictly better, as right now everyone implements both ways and an attacker only needs to break the weakest one.

Do not quite agree. Clearly having more attack surface is worse, but pushing large amounts of sensitive information through mail servers is increasing that surface as well.

How so? Any attacker can trivially push the information they're interested in right now anyway.

If many were to change to email based auth the chances of any leaked (accidentally sent, tricked into forwarding etc) email containing sensitive info would go up significantly. E.g. any mail from medium.com has a very high probability of containing login info.

Second, increased roi makes mail servers more of a target.

Interesting idea. To take it a step further, for sites/accounts you want to reduce the chances of someone gaining access to from a single compromised device you can split the one-time password into two (or more) different parts:

    1. First half of the new one-time key goes to a pre-designated email address
    2. Second half of the key goes to a pre-designated mobile device over SMS

Both need to be entered into the sign in form before you'll be able to access the site/account. The scheme is extensible to include deeper levels of security, too, for situations where your user community is really concerned with access:

    * Email_key + SMS_key + n-digit_PIN
    * Email_key + SMS_key + Pre-paired-hardware_key
    * Email_key + SMS_key + XKCD-style-passphrase

The idea seems straight-forward enough to me that I'd be surprised if someone hasn't already written an authentication library that does something similar. It would be extra steps and a hassle, but like you, I feel that it's already a hassle to use a password manager.

Passwordless.net is a NodeJS library for just this concept. It does make a lot of sense for a large majority of websites that don't need to and shouldn't track passwords long term.

I use a password manager, have done over the past 6 or so years, but definitely had poor password habits before that.

There are probably a number of websites I used between 2000-2010 that I no longer access, so that's somewhat worrying.

This is a really interesting article though, I think Troy is doing the world a service with the work he's doing.

Why is it worrying? If you have good password habits now, nobody will be able to get into your current sites using the old password, and you presumably don't care about the old sites any more.

There are possible reputational effects if they're linked to your current identity somehow.

If they are still linked to your current identity than change the passwords now (or better yet, yesterday) or delete the accounts altogether.

> treat it as a reminder that your data is out there circulating around and that you need to go and get yourself a password manager and create strong, unique passwords.

I think that the real solution to the problem is not to tell people to use password managers, but to make it easy for people to do so.

Unless they've been pwned, the person you're trying to convince probably doesn't prioritize password security during account creation. They just want to make an account. Telling them to do so with no other reason than "don't endanger yourself like everyone else!!" might not have the best success.

Meanwhile, when Google Smart Lock (Google's password manager) was built into Chrome, Now suddenly people who would never think about installing a password manager is using a password manager. It became the default option.

But the security of password managers comes from secure password generators, and Chrome does not provide this by default; it exists under `chrome://flags`. And no one I know uses this. Even the effort of changing a single flag is too much to ask people to do!

There is a similar story for Safari -- one needs to enable iCloud Keychain Support to generate passwords. (*EDIT: this is false, it is enabled by default!!) And while Firefox can store passwords, it has no built-in password generator. There are many great Firefox add-ons, but then we are back to our original problem of convincing others to actually install and use them.

Now, consider that, just like password storage, password generation was default. I'd argue that if password generation was also default, /people will use it/.

Instead, rather than go the path of default built-in password generators, browsers -- recklessly blind to the discussed issue of password reuse -- recommend 'secure' passwords like "#Hihas4ei:YtB"[1] and "sPo0kyh@ll0w3En"[2].

Security shouldn't be a question of convincing others. It should be a default option.

[1](https://support.mozilla.org/en-US/kb/create-secure-passwords...) [2](https://support.google.com/accounts/answer/32040?hl=en)

> There is a similar story for Safari -- one needs to enable iCloud Keychain Support to generate passwords. And while Firefox can store passwords, it has no built-in password generator. There are many great Firefox add-ons, but then we are back to our original problem of convincing others to actually install and use them.

Wait, is that true? I don't use iCloud on my machine (macOS 10.10.5 with Safari 10.0.3) and it does password management automatically, generating and storing passwords. I forget what update it was, but just out of the blue Safari started recognizing password creation fields and offering generated passwords.

Just tried it myself and you are right!

That's good news, perhaps I should go back to Safari.

Interesting to see that some companies do proactive audits by running a list of their current user emails against HIBP. I guess that was bound to become a thing sooner rather than later.

However, I also note that if such a company detects that an email address used by one of their users has been compromised on another site, that this fact is communicated carefully. Specifically I can see the confusion with the Digital Ocean case in the OP - it could sound like their email address in DO itself was compromised, when all DO did was check it against HIBP and discovered it was pwned previously probably from another web app...

I would love Apple to start rejecting apps that didn't integrate with Password Managers. Or at least failing those which disable paste in password fields.

Troy does great work running HIBP.

It's an incredibly useful service - I highly recommend sending over a few dollars to help with infrastructure costs if you feel inclined to do so: https://haveibeenpwned.com/Donate

is rate limiting a defense against this? I get that these attacks could come from a botnet, but it at least increases the necessary size of the botnet.

Is there a service for correlating failed login attempts across sites?

It's only a deterrence, not a defense. The attacked can always wait it out, or attack multiple sites at once to slow things down.

You also have to watch out for rate limiting becoming a way for attackers to DDoS your legitimate users.

I imagine a better alternative would be, having identified an attack (via rate or otherwise), to let the attacker try their list, and for each successful password match deny access (indistinguishably from an incorrect password), silently invalidate the password, and email the legitimate user.

Also don't forget HIBP has a Domain search functionality which is great if you want to find out which employee accounts have been breached. The service lets you download a spreadsheet. Troy is doing the lord's work. https://haveibeenpwned.com/DomainSearch

If I use a password manager, I'm trusting some random company with all of my credentials. What company deserves that level of trust?

Don't use an online password manager then.

https://www.keepassx.org/

KeepassX hasn't been updated in a while. https://keepassxc.org/ is the maintained and updated version.

There is also KeeWeb (https://keeweb.info) which you can install as an electron app or self host.

>KeepassX hasn't been updated in a while.

Is it broken somehow?

"broken" is highly subjective, but here's a list of the issues that originally motivated the fork:

https://github.com/keepassx/keepassx/pulls

Discussion for context: https://github.com/keepassxreboot/keepassxc/issues/43

It's not broken; to be fair, I would definitely call keepassxc better/more up-to-date but it hasn't been as battle-tested as keepassx (even though it's the same codebase).

They're both just as appropriate to use, which is why I recommend keepassx. I do use keepassxc myself however.

In my case, I trust Google with everything (except my Google passwords). If someone has access to my Google account, they have access to almost all of my passwords.

However, this us only because I chose to trust smart lock. I'm not sure how your do syncing but there are solutions to create and store pseudo random passwords locally like the many variants of kee pass.

Perhaps the same company that you're already trusting to not have backdoors in the browser and OS?

Reply on news.ycombinator.com