Jump to content

How do hackers, be it white hat or black, obtain the hashes of passwords?

 Share

I know how to turn a password into a hash, and then use hashcat to crack that hash, but that defeats the purpose because i already have the password to begin with.

How do they get the hash of the password just from some empty password field? Do they just wait for the site to get hacked and hope that the password gets dumped on the net with or without it being hashed? Do they do the hacking themselves to obtain the hash? Sounds counter productive since most sites still dont bother with password hashing and just use plaintext, so in what situation are tools like hashcat even useful? How does one end up with a hashed password without knowing the password to begin with? 

Just having fun learning about things, in this case, fucking around with hashcat. For obvious reason i am not interested in real hashed passwords. Im not here to hack into accounts. Im just curious how the process works. If i wanted to get into someone's account hashcat is pretty low on the list, as brute force attacks go, even dictionary attacks are just sophisticated brute force IMO

“What you must remember, is that the only thing necessary for evil to triumph is for good men to do nothing.”

- Alucard

Link to comment
Share on other sites

Link to post
Share on other sites

A hash is irreversible, so the best you can do is to generate a ton of passwords and associated hashes (called a rainbow table). This will allow you to "reverse" a ton of common passwords, provided the database you got them from didn't follow modern security standards (salt+hash+many iterations)

 

If a password store is using proper security then a rainbow table is effectively useless, because each password is combined with something else before being hashed.

 

For example if you encounter the hash "c8fed00eb2e87f1cee8e90ebbe870c190ac3848c", then you know it's the SHA1 hash for "password", because any decent rainbow table will contain that. But if you salt "password" first (e.g. combining it with the account's uuid) then its hash won't appear in your rainbow table.

 

This will make it much more time consuming to "reverse" the password, because you'll have to combine every common password with the salt, then generate the hashes for this combination. Repeat for each and every database entry.

 

Modern algorithms will combine password + hash then run them through some algorithm tens of thousands of times. It doesn't really matter if your login process takes half a second to produce the hash, but if you want to hack that, you'll have to spend half a second per password for each hash you want to test against your list of common ppasswords. Then repeat that process for the every entry in your database.

Remember to either quote or @mention others, so they are notified of your reply

Link to comment
Share on other sites

Link to post
Share on other sites

1 hour ago, NastyFlytrap said:

Sounds counter productive since most sites still dont bother with password hashing and just use plaintext

[citation needed]

 

Nearly everyone at least hashes passwords nowadays, if they aren't hashing and salting. Using a library to add a login system (or building off a ready-made website template, like this forum does with Invision Community) that stores passwords right is easier than making a bespoke login system that stores plaintext passwords. This means that when websites are hacked and passwords are leaked, it's hashed (or hashed and salted) passwords that get leaked.

 

1 hour ago, NastyFlytrap said:

How does one end up with a hashed password without knowing the password to begin with? 

The hashes get leaked, but getting a password from a hash is harder. You can't reverse a hash, so you have to compute the hashes of a bunch of different passwords and check if the hash matches. Hashes for many common passwords can also be computed ahead of time and combined into something called a rainbow table. If the hash matches an entry in the rainbow table then that's the password, otherwise the only way is to brute force it.

¯\_(ツ)_/¯

 

 

Desktop:

Intel Core i7-11700K | Noctua NH-D15S chromax.black | ASUS ROG Strix Z590-E Gaming WiFi  | 32 GB G.SKILL TridentZ 3200 MHz | ASUS TUF Gaming RTX 3080 | 1TB Samsung 980 Pro M.2 PCIe 4.0 SSD | 2TB WD Blue M.2 SATA SSD | Seasonic Focus GX-850 Fractal Design Meshify C Windows 10 Pro

 

Laptop:

HP Omen 15 | AMD Ryzen 7 5800H | 16 GB 3200 MHz | Nvidia RTX 3060 | 1 TB WD Black PCIe 3.0 SSD | 512 GB Micron PCIe 3.0 SSD | Windows 11

Link to comment
Share on other sites

Link to post
Share on other sites

1 hour ago, NastyFlytrap said:

How do they get the hash of the password just from some empty password field? Do they just wait for the site to get hacked and hope that the password gets dumped on the net with or without it being hashed? Do they do the hacking themselves to obtain the hash? Sounds counter productive since most sites still dont bother with password hashing and just use plaintext, so in what situation are tools like hashcat even useful? How does one end up with a hashed password without knowing the password to begin with? 

Sometimes the hashed password is exposed on the front end (unencrypted config. files on IOT and SBC devices is a commonly occurring real example), sometimes you get access to a database of hashed passwords, maybe a shadow password file for example, sometimes they are collected in transit from a system you otherwise have no access to, like with wifi deauth-attacks (or more recently CANs for car attacks)... 

Reasons you'd want to use some sort of hash attack to guess at passwords (they aren't reversible by definition / are lossy, like Eigenvektor said, so you are just finding possible password matches) when you've already compromised whatever system are most often pivoting the attack to a different system - maybe you have access to the database but if you can match passwords to usernames, you can use them to try to gain access to other systems or get higher level access (eg., you have access to read the hashed password file but not root access to the system) or try the credentials with totally unrelated systems.

Also, hashes don't need to be passwords... sometimes you are trying to generate a collision for a hash-based validation etc.

Link to comment
Share on other sites

Link to post
Share on other sites

2 hours ago, Eigenvektor said:

A hash is irreversible

Yes, yes i know that, and while your comment was appreciated and informational, it doesnt quite answer my question of how a hashed password, or key gets acquired in the first place. Because to use hashcat you're comparing to an already existing hash, which i dont know how they acquire.

2 hours ago, BobVonBob said:

[citation needed]

 

This means that when websites are hacked and passwords are leaked, it's hashed (or hashed and salted) passwords that get leaked.

 

The hashes get leaked, but getting a password from a hash is harder. You can't reverse a hash, so you have to compute the hashes of a bunch of different passwords and check if the hash matches. Hashes for many common passwords can also be computed ahead of time and combined into something called a rainbow table. If the hash matches an entry in the rainbow table then that's the password, otherwise the only way is to brute force it.

Yea, this is kinda how i imagined it going too. Hashed password being leaked, i just thought that since we hear every few months that a site was hacked and they used plaintext passwords, i guess i was wrong on my guesstimations

 

“What you must remember, is that the only thing necessary for evil to triumph is for good men to do nothing.”

- Alucard

Link to comment
Share on other sites

Link to post
Share on other sites

6 hours ago, NastyFlytrap said:

Yes, yes i know that, and while your comment was appreciated and informational, it doesnt quite answer my question of how a hashed password, or key gets acquired in the first place. Because to use hashcat you're comparing to an already existing hash, which i dont know how they acquire.

Typically through some form of data breach.

 

Let's say a company doesn't properly secure one of their services, has an improperly configured S3, or some other mishap that exposes confidential information. That information is used to compromise additional services, which are used to obtain more confidential information. Rinse and repeat. Eventually hackers obtain enough information to be able to access the server containing the user database, which they copy.

 

Other times its social engineering, i.e. fool someone into thinking you're a legitimate employee. This person might give you access to stuff you shouldn't have and you work your way into the system from there. Or a phishing attack, where you fool someone into entering their password into a fake webpage that looks like a legitimate company owned one. Or you get someone to open an infected attachment that copies anything they have access to, which then serves as the starting point for additional intrusion.

 

There have even been cases were people posted a screenshot online, that screenshot showed a password, the password gave access to some internal system, that system contained enough data to be able to log into other systems and so on.

Remember to either quote or @mention others, so they are notified of your reply

Link to comment
Share on other sites

Link to post
Share on other sites

14 hours ago, Eigenvektor said:

Typically through some form of data breach.

 

Let's say a company doesn't properly secure one of their services, has an improperly configured S3, or some other mishap that exposes confidential information. That information is used to compromise additional services, which are used to obtain more confidential information. Rinse and repeat. Eventually hackers obtain enough information to be able to access the server containing the user database, which they copy.

 

Other times its social engineering, i.e. fool someone into thinking you're a legitimate employee. This person might give you access to stuff you shouldn't have and you work your way into the system from there. Or a phishing attack, where you fool someone into entering their password into a fake webpage that looks like a legitimate company owned one. Or you get someone to open an infected attachment that copies anything they have access to, which then serves as the starting point for additional intrusion.

 

There have even been cases were people posted a screenshot online, that screenshot showed a password, the password gave access to some internal system, that system contained enough data to be able to log into other systems and so on.

Ah, yea, i just figured there was some special way i didnt know about, thanks!

“What you must remember, is that the only thing necessary for evil to triumph is for good men to do nothing.”

- Alucard

Link to comment
Share on other sites

Link to post
Share on other sites

18 hours ago, NastyFlytrap said:

Ah, yea, i just figured there was some special way i didnt know about, thanks!

Something I just came across that seems interesting in this regard:

https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/your-pa-word-doesn-t-matter/ba-p/731984

Remember to either quote or @mention others, so they are notified of your reply

Link to comment
Share on other sites

Link to post
Share on other sites

5 hours ago, Eigenvektor said:

Thanks!

While this is a fun read, i severely dont understand with some of their points. For example, the password absolutely does matter for Credential stuffing, because it is beaten by not reusing the damn password. Therefore it is very important.
As for spray and brute force attacks, it matters yet again because 'spray' is just dictionary attacks, and brute force is exactly what it sounds like, and both are beaten by a combination of a strong password, and not being valuable.

Edit: Local discovery doesnt really happen without them targeting you (unless you're on a public wifi or something where they can cast a wide net....), so for that they'd have to want your ass, and specifically yours. 
Same with extortion. 
The only worrying problems for ordinary people, are phishing and software based keyloggers, since noone would invest time and money into hardware keyloggering you, or me for that matter.

Edited by NastyFlytrap
Added more things i had to say

“What you must remember, is that the only thing necessary for evil to triumph is for good men to do nothing.”

- Alucard

Link to comment
Share on other sites

Link to post
Share on other sites

9 hours ago, NastyFlytrap said:

For example, the password absolutely does matter for Credential stuffing, because it is beaten by not reusing the damn password. Therefore it is very important.


As for spray and brute force attacks, it matters yet again because 'spray' is just dictionary attacks, and brute force is exactly what it sounds like, and both are beaten by a combination of a strong password, and not being valuable.

Edit: Local discovery doesnt really happen without them targeting you (unless you're on a public wifi or something where they can cast a wide net....), so for that they'd have to want your ass, and specifically yours. Same with extortion. 


The only worrying problems for ordinary people, are phishing and software based keyloggers, since noone would invest time and money into hardware keyloggering you, or me for that matter.

The article approaches this from the viewpoint of password policies (see intro above the table). Their point is a policy doesn't make a difference in how hackable your account is, while 2FA does.

 

The quality of your password is irrelevant if it was part of a breach. In that case the attacker has the password and will be able to compromise your account. It doesn't matter if the password is "password" or something super complicated. I agree with what you said though. If your password is part of a breach and you didn't reuse it, at least it'll only affect that one account.

 

As for spraying, they're saying the quality of your password doesn't matter as long as it's not part of the top-10 passwords attackers try to use. You'll be safe from attack in any other case. It doesn't matter if your password policy is 1 or 20 special characters you'll be safe in either case, so long as your password is not "password123".

 

For brute force they do point out that you'll be safe if your password can't be brute forced by exceeding a certain length (lower down in the article) and/or by using a password manager that generates actual random passwords.

 

Not being valuable depends. A compromised "actual person" account is valuable because it can be sold to people looking into identity theft, which can then be used for other crimes.

 

For theft they do point out the frequency of this is low. I think of it more like breaking into some office complex, searching through all the offices, then finding your password on a post it. So it's not that you're being targeted and more like: We'll take whatever we can find.

 

As for extortion they do say "very low. cool for movies though". You have to approach this from their angle of: Does a (strict) password policy make a difference here? And it doesn't.

 

So basically their whole point is: If you want to be more secure, you don't need to implement a super strict password policy. It'll not make you more or less vulnerable in any of these cases. Instead, use 2FA or something else that actually improves security.

Remember to either quote or @mention others, so they are notified of your reply

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share


×