Hacker News new | ask | show | jobs
by yellowstuff 1637 days ago
"Credential theft occurs when attackers breach a system and steal users' access credentials -- usually ID and password. The ID is most commonly the user's email address. Credential spilling is when those credentials are made available to other criminals. Credential stuffing is the large scale use of automated means to test stolen passwords against other unrelated websites."

https://www.securityweek.com/credential-stuffing-successful-...

The term "credential stuffing" is a bit counterintuitive for me as well, but I guess it fits the pattern of credential attacks. "Password reuse" has other meanings, so would be less precise as a technical term.

1 comments

The use of obscure and unintuitive terms would seem to hurt the objectives of security proponents to explain how systems have been compromised. If you tell me my credentials were "stuffed", I'm going to assume it was some technically sophisticated attack using some exploit or system vulnerability. If you tell me my password was simply stolen and posted on a website, and they're just brute force trying the password on all the systems, I'm going to know that my password has been compromised and some cybercriminals are out there using bots to try them everywhere.

In the first, case, I'd feel less empowered to do something about it. In the second case I'd be more aware of all the databases with old passwords in it and never reuse a password twice. (if that's what's happening).

I agree that the security industry has a problem with inventing new terms when they don't contribute to understanding. I do think there is some nuance here though to "credential stuffing" vs "password reuse" - credential stuffing is a description of the exploit while password reuse is the vulnerability. In other words, password reuse is a user behavior that doesn't directly cause unauthorized access. "Credential stuffing" is described from the perspective of the service provider, which sees an attacker "stuffing" many thousands (often hundreds of thousands over time) of credentials into their product to see if any of them work. Of course only a tiny fraction do, but that's enough to create a big problem. It's usually not clear where the stuffed credentials came from, it may be a check to see if compromised passwords from other websites were reused, but more often credential stuffers just try a "top 100" password list against every user they can enumerate---so password reuse per se or a compromised credential list may not even be involved, just use of common passwords.

Researchers will sometimes modify services to log password attempts in plaintext in order to try to determine where stuffed credentials are coming from, but for obvious reasons it's not advisable to do this on a "real" service, so it's usually hard to know exactly what's going on---although the set of attempted usernames can sometimes give you a good hint, for example it's not at all unusual to see credential stuffing attacks where the attacker hasn't even enumerated users and is just trying common usernames. Some of these common username lists are kind of eccentric and you can recognize which one an attacker is using by some of the odder entries on it. I've had instances where googling a particularly weird username out of authentication logs just turned up exactly the perl script the attacker was using, uploaded to some compromised webserver where Google got wind of it somehow. I assume the username list it was using was originally from some real system but had been copypastad until it no longer had any relation to the original source. A lot of common password lists are like this as well.

The term "credential stuffing" should be viewed as a term of art and not used in communications to the public, but I do think it's useful because it describes a phenomenon which is different from, and may or may not involve, password reuse by users.

As a semi-related but amusing anecdote, there was for a time a fairly large-scale SSH credential stuffing effort by a botnet whose operator had made a mistake and mixed up the "username" and "password" fields in their credential list. Many SSH servers saw thousands of attempts with various usernames like "letmein123" and password "root" or "admin". I suspect the actual root of the problem was that they'd concatenated credential lists, not realizing they were in different formats. They may have even gotten the credential list that way, these things get passed around in really haphazard ways.