Always when hashing a sensitive information like password, you should use a strong algorithm and a thing called a salt. When a server makes a hash from your password it uses a certain method to do so depending on the algorithm in use. No matter how strong the algorithm is, when unsalted, it will always produce the same result with the same string.
So, the solution here is that you need to use a salt with your algorithm. It's best if you could use a method built by professional people that generates an hash with a salt.
Also, you could just plant an one if sentence that says:
if user is this and the salt is this then login.
Then you are sure that only this user with this username is logging in.
But, if you really want the hash to be random, you need a salt.
So, What is a salt?
Well, Wikipedia explains it in a good way:
In cryptography, a salt is random data that is used as an additional
input to a one-way function that "hashes" a password or passphrase.
Salts are closely related to the concept of nonce. The primary
function of salts is to defend against dictionary attacks or against
its hashed equivalent, a pre-computed rainbow table attack. Salts
are used to safeguard passwords in storage. Historically a password
was stored in plaintext on a system, but over time additional
safeguards developed to protect a user's password against being read
from the system. A salt is one of those methods. A new salt is
randomly generated for each password. In a typical setting, the salt
and the password (or its version after Key stretching) are
concatenated and processed with a cryptographic hash function, and the
resulting output (but not the original password) is stored with the
salt in a database. Hashing allows for later authentication without
keeping and therefore risking the plaintext password in the event that
the authentication data store is compromised. Since salts do not have
to be memorized by humans they can make the size of the rainbow table
required for a successful attack prohibitively large without placing a
burden on the users. Since salts are different in each case, they also
protect commonly used passwords, or those who use the same password on
several sites, by making all salted hash instances for the same
password different from each other. Cryptographic salts are broadly
used in many modern computer systems, from Unix system credentials to
Internet security. - Wikipedia https://en.wikipedia.org/wiki/Salt_(cryptography)
So when we use a salt we prevent so called rainbow attacks and dictonary attacks and we do not get the same hashed string.
How are we going to add a salt?
There are at least two ways to add a salt.
1. Add the salt to the string before it's hashed that is, string + salt
2.Use built-in methods or good methods designed by professional people
Okay, first of all, an salt needs to be really,really random for every single password. That's a high risk if you have a salt that is always the same because when it will be exposed (Yes, when, because everyone will be hacked at somepoint), it's a lot easier for the hacker to break all the passwords in the database. So with that in mind, we continue.
The first method, adding a salt directly to the string is not bad, but then the question is, where to store the salt? And how are you going to make it as random as possible? Well, it's recommended that if you are going to store salts that they are stored sperately from the passwords, even in another database because maybe someone hacks the password table or the database that the passwords are in and not the salts so then he does not know the salt and therefore not the passwords. Then we need to think about the randomnes of our salt, what method is the best to generate the most random thing that you can get? It depends on the language of course and you did not mention any language there in your question so I'am afraid I can't help you with that.
The second one is to use in-built functions that are designed to hash a password with a salt. These are often better than just adding the salt and hash it, because you can be sure that you get the most random salt as possible and different on each password. The headache with where to store the salt and how I'am going to let it be random and each password and what to use so it gets very, very random dissappears. One line and you are good. This is also often maintained and there are some methods there that provides the strongest algorithm that the language can offer + salt. So, that's even more secure, because you don't have to worry about what algorithm is best to use or when the algorithm you are using breaks, you don't need to go over the whole code and change. But, not all languages support these kind of methods so the first one is then better than nothing.
The second method is pretty good I think, because you don't even have to store your salt at all, at least not in your database and then it's impossible to know what password belongs to each salt so it's pretty secure. Also, I recommend when hashing, if possible, that you use a method that always uses the strongest algorithm avilable and a very random salt. Because, then it happens automatically and you don't have to worry.
So, I think the second method is better because it's a less overhead and, possible more secure because you are using an in-built functions. But, not all programming languages have these functions built-in so the first method is better than no salt. But, if that is not possible, use the first one.
There, you have it, the short answer is basicly put some salt on your password, then the hash will not be the same for each password.
I hope this information helps you and some others.