I have 5 test users and they have the same password. I am testing an application which stores the password in the database in an encrypted format. I want learn which hash algorithm has been used on this program? So my question is what is your advice to solve this problem?
Are there any standard steps that can be followed?
User Password: test123
encrypt format for different user's same password:
h9ttr35YmriZmKpo/9sasilzawjUbKYZ
M321NBD2wWLfltj46O/EuVmadsaHn8o0
213/zAYdB+Bi14ZayHPygNpklhjDijka
The normal process in that case, by which I mean what attackers do, is to reverse-engineer the application code, i.e. disassembly and similar tools, to find the actual code. This will give definite answers.
If you do not reverse-engineer the code, then you will be reduced to guesswork, which can be tedious because there will be no clue as to whether you are "close" to the solution or not. Contrary to what is often shown in Hollywood movies, when the key or algorithm is not right, you do not get a slightly blurred picture. The real-world cryptography is a world of all-or-nothing; you either have the right system all along, down to the last bit, or you get seemingly random noise. (Except if the algorithm is prodigiously poor, which unfortunately happens quite often when people feel that they can do crypto like they do Web pages, by hastily slapping together examples scavenged from blog sites.)
As for guesses, we can say the following:
The output looks like Base64. Base64 is an encoding format which transforms every three input bytes into four printable characters; these characters are letters (uppercase and lowercase), digits, "+" and "/" (and there may be some "=" signs at the end for padding). 32 characters in Base64 thus encode 24 bytes. We are looking for a process which yields 24 bytes.
The same password for different users yields different outputs. Therefore, the hashing process will use a "user identifier" (name, email address, UUID, database table primary key...) and/or some random value. To check for randomization, try resetting the password for a given user, choosing the same password. If for the same user you get a different output even though you reset the password to the same value, then the process is randomized and there must be some random salt somewhere.
If the process is not randomized, then we are looking for a hash function which yields a 192-bit output. There are not many of them; most used is Tiger (but it still is quite infrequent). Bcrypt also yields 192 bits, but bcrypt is inherently randomized (you would need to torture existing implementation quite a lot to remove the random salt).
If the process is randomized, then there is a random salt, which is probably part of the output. We are then looking, probably, for a hash function with a 128-bit output (MD5 comes to mind) along with a 64-bit salt, or a hash function with a 160-bit output (SHA-1, or maybe RIPEMD-160) along with a 32-bit salt. The salt would probably consist in the first or last bytes of the output.
Then comes the unknown part about how the hash was used. When assembling a salt and a password with a hash function, a large variety of methods can be observed. There are some good ways to do password hashing with a salt and a hash function (e.g. PBKDF2 or the recent Unix crypt() variants); and then there are a lot of bad ways, with one or two hash invocations with creative nesting. At that point it mostly is a matter of luck: you have to try the exact same way that was used by the application developer.
The resulting cipher is 32 characters so you're probably looking at an MD5 hash. If it was SHA256 it would be 64 characters long.
As the resulting cipher is different in each case, then the application is likely using a salt with the hash to increase the security and remove the threat of using rainbow tables for hash comparison.
Access to the application source code or database stored procedures would be useful!
