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?

Improve this question
1
  • Like @StackzOfZtuff said, just with brute-force. Commented Dec 3, 2014 at 6:40

1 Answer 1

Reset to default
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.

Improve this answer
2
  • Note that the guessing attack is pretty fast. I'm too lazy to dig out the numbers, but a single GPU should be able to check more than a billion candidates per second. Commented Dec 3, 2014 at 13:52
  • Related questions: Is it possible to reverse a sha1? and Brute forcing an HMAC Commented Dec 3, 2014 at 17:30

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.