The following are the steps to create a strong hash:

In the following screenshot is the code in Java that allows us to create a SHA-1 Hash. It's exactly the same as the MD5 hash, except that we will get a MessageDigest instance using the SHA-1 algorithm:

Notice that we only changed MD5 for SHA-1, and this produces a stronger hash but the java.security.MessageDigest class supports even stronger algorithms. We can use the same code as shown in the preceding screenshot, changing only the algorithm's name for any of the following algorithms (listed from weakest to strongest):

If we create one function for every algorithm, we can compare the resulting hashes and see how different they are:

In this case, SHA-512 is the stronger plain hash and it's pretty easy to see why.

The Secure Hash Algorithm (SHA) is a family of cryptographic hash algorithms implemented by vendors, designed by the United States National Security Agency (NSA), and is also used as a standard.

Basically, it works the same way as any other hash function; for variable length data, it generates a unique static length code that we call hash. However, these hashes are not always unique; this means that for two different inputs, we could have equal resulting hashes. When this happens, it's called a collision.

It's important to note that with a stronger hash, we get lower collision chances. But it's not something to be worried about, at least not too much, because the SHA-256 or higher generates really strong hashes with a very low collision probability, it's highly unlikely to produce a collision.

Still, it's theoretically possible to break a hash and by "breaking a hash," I mean to guess the original word that generates that hash. Actually, it's time to acknowledge that there isn't such a thing as a fully secure hash, because it's always possible to perform a brute-force attack.

A brute-force attack is performed by generating words with the help of a computer, creating a hash for that word, and then comparing it with the stored hash in order to guess the password. However, the idea is to make this kind of attack as expensive, in terms of data processing, as possible. The attacker doesn't want a password 20 years from now; he wants it as soon as possible.

The SHA family is far stronger than the MD5 hash function and really expensive to break, at least for now. However, we should never forget what we want to achieve, which is to store our users' passwords in a secure way. But, we are missing something here. We need to ask ourselves, "What kind of passwords do users choose"? Well, the common user chooses easy passwords because they are easier to remember. This is bad for us because an attacker does not even need to perform a brute-force attack; with a simple dictionary-attack he could get hundreds of passwords in minutes!

So remember, even if you decide to use a strong hash function, it's a good idea to require passwords that contain lower and upper case characters as well as numbers and symbols and, of course, a minimum length—long passwords are harder to guess!

Now, if we are storing password hashes generated with a strong algorithm, such as SHA-256 or higher, and a minimum password length combining numbers, symbols, and upper and lower case characters, we can say that our users' passwords are pretty secure. If, somehow, an attacker gains access to those passwords, it will be really hard for him to guess the original password.

However, breaking those passwords is not impossible. Even with good passwords, strong hashes, and all the precautions we have taken, an attacker could still guess the password. It won't be easy for him, but we don't want a "not easy to break". We want to make it almost impossible to break, and in order to do that, we need more than a hashing algorithm and good password: we need to work with our users' data to improve our hash strength—this technique is called salting.