Take the 2-minute tour ×
Reverse Engineering Stack Exchange is a question and answer site for researchers and developers who explore the principles of a system through analysis of its structure, function, and operation. It's 100% free, no registration required.

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

share|improve this question
    
How long does it take to compute a hash? Is it too little to measure, or can you see a brief CPU spike? –  Gilles Aug 9 '13 at 11:55
    
Do you have at least the application binary? Are the symbols stripped? –  Gilles Aug 9 '13 at 11:56
add comment

migrated from security.stackexchange.com Aug 14 '13 at 21:50

This question came from our site for Information security professionals.

2 Answers

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.

share|improve this answer
add comment

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!

share|improve this answer
1  
The hashes are 24 bytes long, not 32 bytes. The remark about the salt is correct. It's probably 8 bytes of salt + 16 bytes of hash. The hash could be MD5, or it could be a truncated SHA-1 or SHA-2, possibly iterated. Or it could be something else altogether, but the mere fact that the hash is salted shows that the application is at least doing something right. Maybe even using a good hashing function like PBKDF2! –  Gilles Aug 9 '13 at 11:50
    
@Gilles The salt might be included in that value, or it might not. Or, for all we know, that is not a hash, but a symmetric encryption. Or something else. –  AviD Aug 9 '13 at 12:05
    
The hash can't be MD5 because MD5 hashes contain only hexadecimal characters. –  Steeve Aug 15 '13 at 9:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.