The way that we hash passwords and the strength of password is important because if someone gets access to the hashed passwords, it's possible to try lots and lots of passwords in a surprisingly short amount of time and crack anything that is weak.

The question I have is how is it that the attacker get access to the hashed passwords in the first place. If they have access to the /etc/shadow file, for example, isn't it already game over? Is it simply bad permissions settings? Backups? Other mistakes? Is it that once one system is compromised, the password from there are used to attempt to get into other systems?

I guess ultimately my query boils down to the implication I get from reading about this subject that it's inevitable that the attacker will get access to the hashes. How does that happen in practice?

  • 28
    You'll also notice that most often, it's not OS passwords (/etc/shadow) that are leaked, but passwords for a Web-based app/service. These are normally stored in a database, and thus vulnerable to database breaches. Commented Aug 23, 2016 at 15:15
  • 6
    Some protocols (e.g. NTLM, WPA2-PSK) send password hashes over the network
    – paj28
    Commented Aug 23, 2016 at 16:03
  • 1
    @paj28 w/ regard to NTLM, this is the same thing that allows for pass-the-hash right?
    – JimmyJames
    Commented Aug 23, 2016 at 16:59
  • 18
    It's not inevitable, but that doesn't matter. Good security design assumes that every other defense has fallen, and aims to find ways to still save the protected resource. So why do we wish hashing algorithms to be resistant to attack? Because by assumption, that algorithm is the last man standing in the defense of the protected resource. Commented Aug 23, 2016 at 17:35
  • 5
    One important thing to remember that even though many of the issues that reveal password hashes might mean "game over" for the server that got hacked, that's not necessarily where the value lies. The server that got hacked might be nearly worthless to the hacker, but if those hashes can be cracked (or if they were plaintext, etc), then password reuse means that the hacker might have access to email accounts, bank accounts, etc.
    – Kat
    Commented Aug 23, 2016 at 19:27

5 Answers 5


There are any number of ways:

  • SQL injection
  • Leaked backups
  • Disgruntled employees leaking them
  • Any kind of breach of the server that allows code execution.

As you can see there are many, many ways this could happened - as phihag mention in comments, more than half of the OWASP top 10 could lead to leaked hashes - so they can not be easily tabulated in a post.

This does not mean that it is inevitable that hackers gets the hashes, but you should still use a good hashing algorithm to protect yourself and your users just in case. Since a backup may be lost or your server hacked without you ever noticing, having properly hashed passwords should be the only thing that allows you to sleep at night. This strategy is known as "defence in depth", or just simply "plan for the worst".

  • 1
    I don't mean to suggest not important, it just seems sometimes like there's this fatalistic attitude around this. I find lots of information about cracking passwords but not that much about how to prevent leaking the hashes.
    – JimmyJames
    Commented Aug 23, 2016 at 14:46
  • 18
    @JimmyJames The reason you don't find any specific information about preventing leaking passwords is that virtually every server-side vulnerability allows that. Out of the OWASP Top 10 vulnerability classes, classes 1, 2, 4, 5, 6, and 9 could leak password hashes. In other words, more than half of all security efforts counter password hash disclosure in one way or another.
    – phihag
    Commented Aug 23, 2016 at 16:42
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Aug 25, 2016 at 23:01

There are many methods. Here are some I can think of off the top of my head. Now I might be a little wrong with the syntax as I haven't bothered to test it out right now, but in general, these are things you'd do in order to get that data.

Note that, with the below exploits, I am not necessarily providing examples which steal hashes (with the exception of SQLi), but examples of how the exploits can work. The attacker would use exploits below to further compromise a system.

  1. SQL injection

    a OR 1=1'; exec sp_msforeachtable "SELECT * FROM ?";--

    You could also use sp_msforeachdb, like so:

    a'; exec sp_msforeachdb 'USE ?;exec sp_msforeachTable "SELECT * FROM !","!"';--

    The -- is there to comment out parts of the SQL statement that may interfere with your injection. These are just very basic examples. It really depends on the format of the query.

  2. OS Injection. ; cat /etc/passwd; rm -rf /*
  3. LDAP Injection. *, (cn = *)(|(password =*))
  4. Insecure Direct Object Reference leading to Local / Remote File Inclusion vulnerability.

    /etc/passwd%00 (note: passwords, of course, aren't stored here; finding valid usernames when people reuse passwords is the key here, or using the usernames to aid in escalation of privileges)

    %00 is a "null terminator" used to avoid anything coming after it, so you don't try to include something that doesn't exist, e.g.: /etc/passwd.txt. This could also be \000, \x00, \z, \u0000, \0, or \00 depending on the language you're using.

  5. Hacking a developer / user with access to the databases.
  6. Exploiting the database server, or web server through some other means.
  • So in a nutshell, one or more vulnerabilities is used to get access indirectly. OK kind of seems obvious now that you put it like that.
    – JimmyJames
    Commented Aug 23, 2016 at 14:51
  • Pretty much. All are relatively easy to exploit anyway. Commented Aug 23, 2016 at 15:20
  • 4
    I'm not sure I follow you. The password won't be stored in plain text if it's done right, even if everything else is wrong. It's a major concern because people reuse passwords, and it may allow them to access other websites using the same username/password combo. Commented Aug 23, 2016 at 19:50
  • 2
    @binnyb, getting a user's email address and password doesn't just compromise the one system. Due to password reuse, it can compromise many systems. For more info: krebsonsecurity.com/2013/06/the-value-of-a-hacked-email-account
    – MikeP
    Commented Aug 24, 2016 at 15:40
  • 1
    @MikeP I should've clarified: /etc/passwd allows you to find usernames, which can then be used to log in or escalate privileges. It's a small part of the process, but a fundamental one. When users reuse passwords across multiple systems, you may just need to find a valid username if you have valid passwords. LFI/RFI can also be used to gain code execution, which could provide DB credentials, AWS creds, etc. Commented Apr 4, 2019 at 1:51

One addition to Mark Buffalo:
7. Man-in-the-Middle attack. Watching unencrypted traffic can often reveal a password hash. In a pass-the-hash scenario, systems will trust the hash and the password and let an attacker simply copy the hash without cracking it.

  • Which connection are you intercepting here?
    – Bergi
    Commented Aug 23, 2016 at 19:25
  • OP is only asking for cases where the attacker gains access to lots of hashes.
    – Bergi
    Commented Aug 23, 2016 at 19:26
  • @Bergi This answer is also relevant.
    – JimmyJames
    Commented Aug 23, 2016 at 19:30
  • @Bergi, OP doesn't state "lots". However, If someone has access to a way of MitM attacking, then they can get "lots".
    – MikeP
    Commented Aug 24, 2016 at 15:40
  • Yes, if you can listen to the unencrypted traffic between the database and the application server that might reveal some hashes, that's what I wanted you to clarify. But I think a pass-the-hash scenario where you can control the hashes by being a mitm is not relevant for the question.
    – Bergi
    Commented Aug 24, 2016 at 15:44

The only truly secure computer is one that is isolated from the internet, turned off, unplugged, buried in a bunker 100ft under ground, with armed guards at the only entrance. Even then, I'd check in on it every once in a while.

Hashing the passwords is part of what is known as "security in depth." You are correct that, in an ideal world, you would not make any mistakes which would give attackers access to that data, so in theory it would not matter if they were plaintext passwords or hashes. In a real world, intrusions do occur, and it remarkably hard to predict how and where they will occur. The idea behind security in depth is to make it so that, in theory, even if an attacker compromises your system in some way, you have taken efforts to mitigate the damage.

In the real world, there is a natural need to access hashes on a regular basis. Every time a user logs in, you need the ability to access them. Accordingly, they are almost always accessible to whatever application is doing the authentication. If someone compromises your application, they may be able to read data that they weren't supposed to be able to read.

The ways these attacks occur are endless. You can have SQL injection attacks if you failed to sanitize your inputs. You could have a buffer overrun, giving the attacker the ability to run their own code. You could have a permissions error, accidentally making a file readable by people when you shouldn't have. The attacker may get their hands on one of your backup tapes due to mishandling by your backup service!

All of these attacks give an attacker a foothold on your computer, but they don't always result in a complete break. You may have chrooted your SQL server, so that the SQL server process literally cannot see the entire rest of the computer. However, in such situations, the login information users need must be within the SQL server's reach, or its of no value. Thus, login information is typically compromised before other more nefarious compromises occur.

By hashing the passwords, you decrease their value. A hash isn't useful for login purposes. They need to have the password which hashes to that value. They may or may not be able to afford the cost of breaking the hash. In the best of all worlds, you never needed to worry about this in the first place, but if you subscribe to the security in depth approach, you make sure that even a successful intrusion doesn't compromise all of your data.

  • 1
    You'll also salt the hash, so that 2 same passwords won't end up with the same hash. That way hackers can't just create a huge database of hash for passords.
    – user276648
    Commented Aug 24, 2016 at 8:42
  • 2
    "I'd check in on it every once in a while" -- and that's probably your downfall. Whatever procedures you put in place to let yourself in to check on it, there's your opportunity to screw something up and allow an attacker in. Commented Aug 24, 2016 at 9:55
  • @SteveJessop True, the best way to secure a computer has always been to run it through a woodchipper, and then set fire to the remains =)
    – Cort Ammon
    Commented Aug 24, 2016 at 13:31
  • 1
    @CortAmmon While I don't disagree with the point that you paranoia is important in securing systems, I think this line of reasoning is often misused as an excuse for not trying. I perceive a popular delusion that breaking into a system is like breaking into a safe. Given enough time, effort & equipment you can break in. The reality is that most vulnerabilities are built into systems due to laziness and ignorance. When people fail by writing vulnerable code or failing to use good practices, we often hear about the 'impossibility' of securing systems.
    – JimmyJames
    Commented Aug 24, 2016 at 14:55
  • 2
    @CortAmmon Good points. If I could coin a phrase around this I'd make it something like "assume you have vulnerabilities and continually strive to eliminate all of them."
    – JimmyJames
    Commented Aug 24, 2016 at 19:54

Some old-school networked un*x/linux installations will still use the NIS/YP service for centrally managed authentication. NIS effectively publishes the hashed passwords on the network for every workstation to authenticate users against.

  • And, in days of old, the salted passwords were kept in world-readable /etc/password.
    – waltinator
    Commented Aug 24, 2016 at 22:59
  • Which is still an option available at install time with some modern linux distributions. Commented Aug 25, 2016 at 10:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .