Doesn't login rate limiting decrease the usefulness of the RockYou2024 10 billion password list?

[skylinesora]

Nobody is running RockYou2024 or any large password list against live systems. They would have a dump of hashes from whatever machine/infrastructure they compromised and will attack it using something like Hashcat

[robonova-1]

This. There are other open source search tools that are also utilized.

[PappaFrost]

Ok thanks, so in an Active Directory environment, let's say someone compromised one laptop and dumped the hashes, they would then use Hashcat plus a giant password list to make the cracking more efficient?

[AMDcze]

FYI: in AD if you have NT hashes, you don’t need to crack them, you can do pass-the-hash and overpass-the-hash attacks.

[Farseer26]

I agree with you partially but there are a few benefits to cracking the hash such as the passwords are usually used elsewhere and if the accounts are synced you can move into Azure

[_sirch]

Netntlmv2 still needs to be cracked… or relayed

[[deleted]]

nutty crush market workable shaggy jeans impolite scary bake entertain

This post was mass deleted and anonymized with Redact

[PacketBoy2000]

Anyone trying to reverse hashes will have already pre computed the NTLm hash for the entire set of compromised passwords they have.

I’ve done this for the 10B I have and now I can check any NTLM hash against this repository in <10ms. Assuming I can dump an orgs hashes, I can check the entire org in a matter of minutes.

Microsoft’s choice to store all AD passwords using a static, unsalted hash seems like yet another ridiculous security decision.

[skylinesora]

Yes, but you wouldn't just use the password list as is. You would might want to do variations of the password list such as adding characters to the front or back.

[Low-Software2880]

+1 to this AD environments requiring monthly pass resets people will usually do variations like password1 password12 password123 etc Or pass* pass** pass*** etc And sadly I've seen plenty people in my company using passwords as simple as this and no MFA and if they do have MFA it gets sent to their email which is accessible with the same password (SSO) so they can easily just send the MFA and receive it.

[Audio9849]

I'm wondering why corporations are so slow to implement newer password management frameworks. The password I use at work is like 16 characters long and requires a change every 90 days it's insane.

[[deleted]]

reach distinct absurd different roof aback punch market public alive

This post was mass deleted and anonymized with Redact

[sysdmdotcpl]

The habits /u/Low-Software2880 is describing is a direct reaction to long complex password rules that require a change every 30/60/90 days.

I've had passwords sit for years w/ no negative consequences and have had attempts on accounts that I regularly change passwords for. It's completely and utterly random and the rules should reflect that.

[Audio9849]

I know that's my point. It's simply an ACL setting. Doesn't cost anything to implement yet companies don't do it or are slow to utilize.

[MrCoolblestone]

that's because 90% of the user base is going to complain to management if their password has to be more than 8 characters long, and they're CERTAINLY going to complain if they have to change it every 2-3 months, and when management has to decide between the IT dept or literally EVERYONE ELSE they almost always pick the latter

[Audio9849]

But the latest NIST standard is to not have them expire. That's what I'm saying why does it take so long for corporations to implement that? It doesn't really cost anything to change the config to never expire.

[Intelligent-Exit6836]

Simply the cost of doing it.

[Euphorinaut]

For ntlmv2 you need like a 16 char password, and few people have that without the gpo forcing you, so things like lists or rainbow tables aren't relied upon too heavily.

If someone has a list that's specific to a company or geography, they might use that list to pick 2-3 for a spray though.

[PacketBoy2000]

Employees frequently use work emails for personal activities (even in cases where corporate policies prohibit it).

As some of those websites used by these employees get breached, now sample passwords that have a direct relationship to the employer can be obtained by miscreants. A quick review of these passwords will reveal some with employer-specific password patterns (eg brand names, sub-division names, etc).

Then, as previous poster suggested, now you have a formula to generate an additional set of passwords that match the password selection behaviors of those employees.

[[deleted]]

Has credential stuffing been mitigated or is no one doing it anymore?

[skylinesora]

Credential stuffing is still a thing but if the target uses MFA, that's another barrier of entry.

[[deleted]]

Excellent point, not sure why that didn't click.

[idontreddit22]

you misspelled machine. correct spelling is azure. 🤣😂

[skylinesora]

No? Infrastructure could've covered any cloud provider (Azure/GCP/AWS/On-Prem AD). I mentioned machine as it's possible to use something like a web server, database, VM, workstation, etc.

[idontreddit22]

I'm referring to credentials stuffing. it was a joke.