I am a newbie to hashing, and I understand that MD5 (I know it's broken) and SHA-1 are all fixed hashing algorithms, but given that most passwords are dictionary words or other similar passwords, what's the point of storing it in a hash if an attacker can use Google to backtrack the original password?
I mean, isn't SHA-1 or SHA-2 or any of those algorithms rendered useless?
This is why you need to use a salt.
Adding a globally unique salt to each password ensures that even if every password is the same, they will still each generate unique hash values.
That said, a single iteration of SHA-1 or SHA-2 is still not a good way to hash passwords, because they are too fast. Even with a unique salt, modern hardware is capable of hashing billions of candidate passwords each second to find the inputs. A good slow algorithm such as bcrypt with an appropriate work factor should be used instead.
Password hashing is but one, very small use for a hash. Hashes can be very valuable for other uses by themselves, in constructs that pair hashes with keys, and in other constructs.
For password hashing in specific, as always, you should read Thomas Pornin's canonical answer to How to securely hash passwords.
For this answer, the summary is: In the event of a password database leak, sufficiently bad password storage (plaintext and/or reversible encryption where the key is known to the attacker) renders the best password worthless. Sufficiently bad passwords render the best password storage worthless. At this level, nothing is safe, because one or both parties failed to reach the minimum required bar for any kind of safety.
Then we get to "really horribly awful password storage" like unsalted single iterations of hashes. This is just like the below, but each try applies to every single password at once. At this level, only unique, insane passwords are safe, as two users with the same password are obvious - they have the same hash.
Then we get to "really awful password storage" like unique per-row salted single iterations of hashes. Of any hashes, though obviously slower (to the attacker) hashes have a smaller range of passwords that are worthless after a given amount of time spent trying guesses.
After this is using good, solid algorithms, i.e. PBKDF2, BCrypt, or SCrypt, with low iteration counts. This is where hashing is safe for reasonably complex passwords!
After this is using PBKDF2, BCrypt, or SCrypt with a sufficiently high number of iterations/work factor. At this level, hashing is safe for slightly less complex passwords, and/or for a slightly longer time.
Note that, amusingly, PBKDF2-HMAC-MD5 is, with a sufficiently high iteration count, actually not broken, though you'd either have to be an idiot to use it, or you'd have to be working with something like an FPGA with enough gates for MD5 but not for SHA-1 or SHA-2.
Note that attackers always gain more power... and that password leaks stay in the wild forever. All passwords that get found should never be considered safe again - the largest wordlist I've seen contains gigabytes of previously cracked or found in plaintext passwords, and some are horrifically complex... but they were stored badly, and are now in wordlists.
Rules based attacks using dictionaries are a topic for another question :).
SHA-1 etc. are not designed for passwords.
They are designed for signing documents (with known text) against modifications such as adding an extra 000 to your paycheck. When it is hard to find a random document that has the same hash, then it will be much more harder to find one that makes sense and achieves the desired effect!
One of the important properties of cryptographic hashes (as opposed to hashes used e.g. for data structures) is that a single bit changed in the input should generate an entirely different hash, in a way that you can't predict how to undo this.
For the purpose of encrypting passwords this would not be this necessary (you could use very long salts to hide too-similar passwords in the digests; but it is of course nice to have this property, so that say passw0rd and password generate totally different results)
Think outside the password box.
These hashes can be used for passwords if you add in a salt (always use salts) and do enough iterations to make brute force costly. But that is not what their design goal is. The design goal is an unpredictable mixing of the bits, so that every bit changes about 50% of the output.
It's NOT the hashing's fault, it's the users'
most passwords are dictionary words or other similar passwords
My password is
iL0v3$t4ckExch4n9everymuch<3 xoxoxox
Now use Google to find the hash for my password under MD5 or SHA-1, I highly doubt that it's pre-calculated in any rainbow table. In fact I was a member of a website that got hacked and the hacker has posted the unsalted MD5 hash of my password online. Till today it's available and I used the same password and email on an other website deliberately to see if someone will ever bother to create a rainbow table that reveals my 26-letters password.
You have to differ two things:
A) The hash function as a function to transform a given set of information input to a well defined set of output. If you look at this aspect of a hashing function, it has to solve two problems:
1) It should be designed to avoid collisions - it would be a mess, if you have a high collision rate because it would be easier to "guess" the password. Think of a function which sums up every ASCII-Position of every char input: the outcome for »ab« is the same as for »ba«. So this would be really a very bad choice.
2) It should be deterministic so that you could reproduce the result. Hashes are used for comparison. So it should be clear, that a function, which has no deterministic output is useless.
B) The use of a hashing-algorithm in the context of storing passwords in a database.
How is hashing safe if a given string always generates the same hash?
From (A) it is clear, that, since the output is deterministic a possible attack vector would be to use premade/-calculated hashes aka Rainbow-Tables.
simple example:
Say, your password is "hello world". The MD5-Sum is: 6f5902ac237024bdd0c176cb93063dc4. Googling (our »Rainbow table« for the sake of the example) for that checksum leads you to this location, where you find a file, whose content is "hello world". So simply hashing isn't enough. A way to improve security is to use a salt (which could be stored alongside the hash). In our case, let's add 6f5902ac237024bdd0c176cb93063dc4 (the MD5-sum of the previous example) to the passphrase => »hello world6f5902ac237024bdd0c176cb93063dc4«. The new MD5 is f59c64e092edb4fbc2904a3b28ce88c5. If you google that, you have no results.
Beware: I am not(!) suggesting, using MD5 in this way is in any way "secure" - but I used it to exemplify how a salt affects the outcome of a hashing function. Although the hash is calculated deterministically, the output for one password and two different salts is different enough to make the "guessing"-part a bit harder.
