7

This is technically not even an attack. We have all the resources at hand, except for the original plain-text. We have the cipher-text (to be converted back to plain-text), as well as the key.

The cipher-text stored in the DB is as follows: HKnvB41kkow+KkR4c7G/8vusmEM=

The hashing function used is as follows:

Public Shared Function EncryptPasswordInHash(ByVal password As String) As String
    Dim EncodedPassword As String = password
    Dim Hash As New HMACSHA1()
    Hash.Key = StrToByte(LicensingBLL.ENCRYPTION_KEY)
    EncodedPassword = Convert.ToBase64String(Hash.ComputeHash(Encoding.Unicode.GetBytes(password)))
    Return EncodedPassword
End Function

The key we have used is : "zooooooooooo123"

Is there any possible way to retrieve the plaintext with all the given information?

  • Like @StackzOfZtuff said, just with brute-force. – Lucas NN Dec 3 '14 at 6:40
12

Nope
Generally speaking: No. Hashing is not encryption. Hashing is not reversible. At all. It always generates a fixed length output. So with an output fixed to say 32 characters, and an input of 33 characters, there is no possible way to reverse this. The information of that one character is irretrievably lost. -- And along with it all other characters.

Brute force feasible for small inputs
But: If you know, that your input is only digits 0-9 and there are only ever 3 of them, then you just try all 1000 of them, and yes, you have effectively reversed the hash. (By "Brute Force".)

There's no unlocking a keyed hash
Also: The "key" you use in a keyed hash is not the kind of key that will unlock anything. "Key" is really a bad, confusing name in that context. It is just one more input that is mixed with the regular data in a special way. -- After which all of it goes through the hash-function meat grinder and is turned into fixed length output.

Sidenote: Weird way to store passwords
You seem to be using HMAC to store passwords. This is unusual. And also it means that you're basically storing peppered, unsalted, low-round-count-hashed passwords. Peppered is good. (If the pepper is stored somewhere other than the hash itself.) Unsalted is always bad. Low-round-count-hashing is also bad. (Details: See this question: HMAC - Why not HMAC for password storage?) -- All of this will make it easier to brute force the hash if the key is known, but it must still be brute forced.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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