If I know original text "12345" which encodes to "Tut0nlFFZ9sLVhPE5x81lQ==", how I can identify hashing algorithm?

5 Answers 5


On observation this looks like base64 encoding (note this isn't a hash, it's an encoded string). I can tell this as I know that in base64, one pads the end of the string with = as necessary to give the base64 string a predictable length. Other tell-tale signs can be from the usage of certain characters in the string. These you will learn by simply exposing yourself to existing examples and reading about the various encoding algorithms out there.

The base64 encoded string of 12345 is actually MTIzNDU=, not what you provided. Decoding your supplied string yields: NëtžQEgÛVÄç5•. The high entropy here indicates this is probably the result of some encryption algorithm. Since the point of a good encryption algorithm is the inability to determine it from random data, it is not often simple to discover which algorithm was used and you would normally have to resort to brute-force efforts.

Assuming this is some kind of exercise where you are certain your input resolves to this and you've been asked to determine the password used to encrypt it, you can brute-force using a method which after trying a password checks to see if the output is indeed 12345. This way you can actually verify you have guessed the right password. Good luck!

  • Is it possible that the high entropy is due to compression rather than encryption? Is there any way to determine this?
    – Matt
    Commented Feb 22, 2013 at 13:55
  • 1
    It's possible but I would say unlikely, as many compression algorithms will introduce a level of overhead which would produce an output larger than this, in addition to including a plain-text header which states what compression was used (unless this has been omitted on purpose as part of an exercise - context matters here).
    – deed02392
    Commented Feb 22, 2013 at 16:39

The "encrypted value" is Base64: this is an encoding for arbitrary bytes into printable characters. In Base64, every three input bytes become four characters; the possible characters are letters (uppercase and lowercase), digits, '+' and '/'. Also, there may be one or two final '=' signs so that the total length is a multiple of 4. These '=' signs are a dead giveaway of Base64.

In your case, the "encrypted value" is Base64 encoding of a sequence of 16 bytes. These 16 bytes, in hexadecimal, would be 4eeb749e514567db0b5613c4e71f3595. In the context of hash functions, 16 bytes usually mean MD4 or MD5. But there are many possible variants. For instance, if that "encrypted value" appears in a "database of users" (e.g. a hashed password), then it is quite possible that the input is somehow "salted" with some other user-specific fields. To check for that, try to give the same password to two distinct users; if they get distinct hashes, then salting is applied (possibly with the user name, or some other field).

Such values do not appear alone; they are in a context: you found it in a file or database, linked with some application or server software. Clues about the type of encryption of hash function are to be found in that context.


You are using hashing and encoding and encrypting at the same time for the same thing, while they are completely different things. Simply put:

  • hashing => One way irreversible
  • encrypting => reversible but securely protected
  • protected encoding => reversible without protection

Your best way to find out is take all different algorithms and hash/encode your plain text and see which of the output matches. I have a strong feeling that the encoding is BASE64. Now it might be that what they did is: BASE64(hash(x)), so your best bet is to decode the BASE64, take the binary representation and compare it to different hashing results of your plain text string.


First of all, let me point out that Tut0nlFFZ9sLVhPE5x81lQ== is a base64 encoding of the string "NtQEg V5" and not a value resulting from a hashing function.
Secondly, since your question suggests that the difference between encryption and hashing is not clear, I'd suggest you take a look at these two SO questions before exploring further on the matter (one and two).

Back to the question, in order to detect which hashing function has been used you can take a look at the hash value as hashing algorithms usually have a fixed-length output. For example, MD5 produces a 128-bit value (32 hexadecimal characters), while SHA1 produces a 160-bit value (40 hexadecimal characters). Let's see it in action:

  • The MD5 hash of "12345" is 827ccb0eea8a706c4c34a16891f84e7b and the SHA1 hash is 8cb2237d0679ca88db6464eac60da96345513964
  • The MD5 hash of "1234567890" is e807f1fcf82d132f9bb018ca6738a19fand the SHA1 hash is 01b307acba4f54f55aafc33bb06bbbf6ca803e9a.

As you can see, the hashes have the same length as the ones calculated on the shorter string.

Even if you have access to both the clear text and its hashed value, finding the algorithm used may not be as straightforward as it seems.

If the implementation uses a single hashing algorithm (which is common practice), detecting the right one is trivial and can be done with freely available applications (e.g. MD5Decrypter). Keep in mind that some applications may implement it differently:

  • encode the hashes before saving them (e.g. base64(md5($text))) - decoding common schemes can be achieved with on of the many freely available tools
    • e.g. the MD5 hash of "12345" encoded in Base64 is gnzLDuqKcGxMNKFokfhOew==
  • multiple hashing algorithms (e.g. sha1(md5($text))) - find out one at a time until the last one is detected
  • a salt can be used to strengthen the hashes against attacks - it's still possible to detect the hashing algorithm used, but simply hashing the clear text won't return the same value
  • while against best practices, an application can sport a custom algorithm used to store information - the difficulty in determining how the clear text string is manipulated it entirely depends on the custom implementation

It's also possible to find out which algorithm is being used by knowing the underlying technology: Windows passwords can be LM or NTLM hashes, credentials found in a MySQL database may be (uncommon) hashed with MySQL's PASSWORD() function, etc.

  • You have decoded the string incorrectly from Base64. Commented Feb 22, 2013 at 21:06
  • Well not completely incorrectly; he just dropped the bytes that that aren't printable ASCII (roughly half of them). base64.decodestring('Tut0nlFFZ9sLVhPE5x81lQ==') gives me 'N\xebt\x9eQEg\xdb\x0bV\x13\xc4\xe7\x1f5\x95' or '4e eb 74 9e 51 45 67 db 0b 56 13 c4 e7 1f 35 95` as bytes (in hex).
    – dr jimbob
    Commented Feb 22, 2013 at 21:25
  • Point taken. Nonetheless, since the point was just to show that the base64 string was not the encoded form of "12345", I figured that showing the hex string in this case would only confuse the OP.
    – Gurzo
    Commented Feb 22, 2013 at 23:23

There is more than one way of generating such an output. A tool that may be able to help you in a more generic way for this task, it is called Codetective: https://github.com/blackthorne/Codetective

P.S.: I may be biased :P

  • 1
    Welcome to security.SE - you might want to add more substance to your post, and change your PS to "disclosure" stating your relationship to the tool linked. It might get flagged as spam/advertising and get you banned if you don't. see: security.stackexchange.com/help/promotion Commented Jan 30, 2017 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .