I have a string that was salted, hashed with SHA-256, then base64 encoded. Is there a way to decode this string back to its original value?
SHA-256 is a cryptographic (one-way) hash function, so there is no direct way to decode it. The entire purpose of a cryptographic hash function is that you can't undo it.
One thing you can do is a brute-force strategy, where you guess what was hashed, then hash it with the same function and see if it matches. Unless the hashed data is very easy to guess, it could take a long time though.
You may find the question "Difference between hashing a password and encrypting it" interesting.
It should be noted - Sha256 does not encrypt the data/content of your string, it instead generates a fixed size hash, using your input string as a seed.
This being the case - I could feed in the content of an encyclopedia, which would be easilly 100 mb in size of text, but the resulting string would still be 256 bits in size.
Its impossible for you to reverse the hash, to get that 100mb of data back out of the fixed size hash, the best you can do, is try to guess / compute the seed data, hash, and then see if the hash matches the hash your trying to break.
If you could reverse the hash, you would have the greatest form of compression to date.
SHA* is a hash function. It creates a representation (hash) of the original data. This hash is never intended to be used to recreate the original data. Thus it's not encryption. Rather the same hash function can be used at 2 different locations on the same original data to see if the same hash is produced. This method is commonly used for password verification.
You've done the correct thing by using a salt aka SSHA.
SHA and SHA-2 (or SHA-256) by itself without a salt are NOT considered secure anymore! Salting a SHA hash is called Salted SHA or SSHA.
Below is a simple example on how easily it is to de-hash SHA-1. The same can be done for SHA-2 without much effort as well.
Enter a password into this URL:
http://www.xorbin.com/tools/sha1-hash-calculator
Copy paste the hash into this URL:
https://hashes.com/en/decrypt/hash
Here's a page which de-hashes SHA-2. The way this pages works is somebody must have hashed your password before, otherwise it won't find it:
md5hashing dot net/hashing/sha256
Here's a page that claims to have complete SHA-2 tables available for download for a "donation" (I haven't tried it yet):
crackstation dot net/buy-crackstation-wordlist-password-cracking-dictionary.htm
Here's a good article that explains why you have to use SSHA over SHA:
crackstation dot net/hashing-security.htm
Related
This is hash type MD5 '9931BF135E464FE91E444DF4E046006A' but I can't change it to string is there any website that can do that.
There are several reasons why what you're asking is not possible.
First, the process by which the MD5 hash code is created loses information. MD5 is a 128-bit hash code. So if you take the hash code of anything larger than 128 bits (that's 16 bytes), by definition you're going to lose information.
Related: there is an infinite number of possible strings. By the pigeonhole principle, there is more than one string that will hash to any particular MD5 value.
Given a hash value, is it possible to guess the hash function used to generate it?
For example, let's say that 9b35a8503abcecadfb85726cfefb99a9 is generated by MD5 or SHA-1(If it's SHA-1, let's say that it is only the first 16 bytes of it), and the content was plain english text. Is there any hint that makes it more likely to be generated by MD5 than SHA-1 or vice versa?
No. If there was, that would indicate some defect in the hashing algorithm.
Of course, you can search against a rainbow table or by brute force. But other than that, there's no significant hint.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is SHA-1 secure for password storage?
I am new to encryption and I have a doubt. It may be a stupid question but I am going to ask. I know SHA1 is not decrypt-able. But a quick thought, if a hacker create a table containing two columns - non encrypted password and its SHA1 encrypted value. And the rows contains passwords of all combinations of characters which he generated using a program in 6 months (say 900 million records). Can't he easily get the non encrypted password if he got an SHA1 encrypted password?
If yes is there any solution to prevent this?
Thanks in advance.
The attack you’re describing is called a rainbow table. Yes, it certainly is a valid concern for short passwords – thus the typical security requirements on the minimum length of passwords. However, the size of the table needs to grow exponentially with the length of the password; for example, an alphanumeric case-sensitive password would increase the table by a factor of 62 for each additional character. Thus, it becomes intractable to compute beyond a certain length. (Just 8 characters would give rise to around 218 trillion combinations.)
Another precaution you could take is to salt your passwords (which may simplistically involve appending a constant string to each password before computing its hash). This way, even if the attacker has access to a pre-computed rainbow table, it would be of no use against your hashes; a new rainbow table would have to be computed for each salt.
The common solution to prevent rainbow table attacks is using a Salt.
I would add though, that SHA1 is not considered very secure. Using brute force to find the unscrambled passwords is quite easy with a powerful computer. For storing passwords, it's recommended to use a slow hashing algorithm like bcrypt or PBKDF2.
Yes. That is why its important to salt your hash. As long as your has is properly salted the type of table you are talking about is only useful for a single password.
see http://msdn.microsoft.com/en-us/magazine/cc164107.aspx for example
A dictionary attack, such as the one you described, can be prevented by salting the hash. Essentially, you force the length and complexity of the plaintext beyond the scope of the dictionary being used.
It's simple to implement, too. One way is to maintain a password, such as "0shunF1ave" and attach it to your plaintext. So, instead of storing SHA1(password), you'd store SHA1("0shunF1ave"+password). When you verify the password, you perform the same hash against the candidate like SHA1("0shunF1av1"+candidate) to your originally stored hash and see if they match.
I am trying to verify an OAuth signature generated in code against a "known reputable source". All my steps are verified correct except the last, wherein a 'base signature string' is HMAC-SHA1 hashed against a secret key and then base64 encoded.
I have confirmed that my hash value is the same as expected by the algorithm. I then disconfirmed that my base64 encode was the same. Attempting to determine why my encode failed, I wanted to check the encoder I was using.
Here is the (hash) string being base64 encoded:
203ebb13a65cccaae5cb1b9d5af51fe41f534357
Here is the base64 encode that results in my code:
MjAzZWJiMTNhNjVjY2NhYWU1Y2IxYjlkNWFmNTFmZTQxZjUzNDM1Nw==
According to http://www.motobit.com/util/base64-decoder-encoder.asp, that is the correct result:
But, according to http://www.online-convert.com/result/096d7b00138f3726daee5f6ddb107a62 (provided with the secret and base string, not the hash), a different base64 should have been output. Note that the hash output is my correct hash despite the difference in base64:
Finally, the "official" tester (http://hueniverse.com/oauth/guide/authentication/) outputs a third different base64 from the same hash:
I have no idea what I'm doing wrong, and the fact that these tools are outputting different results makes me wonder if there is in fact such a thing as base64 encoding or if they are actually using different algorithms? Perhaps the fact that it's for OAuth would help you help me identify the answer.
Thanks for any leads from the wise.
OK, in this case the first website was making the same "mistake" I was (in my case it was a mistake, the first website may just be making an unstated assumption).
That mistake is whether the hash is interpreted as a string (which gets base64encoded) or as a series of hexadecimal values which get base64encoded. In the former case, the resultant encode is longer than the original string, while in the latter the resultant encode is shorter than the original string. This is not only empirically true but the interwebs show that it is one of the concepts behind the standard in the first place.
The second website, working from (as stated) "hex" data, got the correct answer.
Try to check via https://base64-encode.org
On this website you can convert all types of images to Base64 string.
I have a user model on my app, and my password field uses sha1. What i want is to, when i get the sha1 from the DB, to make it a string again. How do i do that?
You can't - SHA1 is a one-way hash. Given the output of SHA1(X), is not possible to retrieve X (at least, not without a brute force search or dictionary/rainbow table scan)
A very simple way of thinking about this is to imagine I give you a set of three-digit numbers to add up, and you tell me the final two digits of that sum. It's not possible from those two digits for me to work out exactly which numbers you started out with.
See also
Is it possible to reverse a sha1?
Decode sha1 string to normal string
Thought relating MD5, these other questions may also enlighten you:
Reversing an MD5 Hash
How can it be impossible to “decrypt” an MD5 hash?
You can't -- that's the point of SHA1, MDB5, etc. Most of those are one-way hashes for security. If it could be reversed, then anyone who gained access to your database could get all of the passwords. That would be bad.
Instead of dehashing your database, instead hash the password attempt and compare that to the hashed value in the database.
If you're talking about this from a practical viewpoint, just give up now and consider it impossible. Finding the original string is impossible (except by accident). Most of the point of a cryptographically secure hash is to ensure you can't find any other string that produces the same hash either.
If you're interested in research into secure hash algorithms: finding a string that will produce a given hash is called a "preimage". If you can manage to do so (with reasonable computational complexity) for SHA-1 you'll probably become reasonably famous among cryptanalysis researchers. The best "break" against SHA-1 that's currently known is a way to find two input strings that produce the same hash, but 1) it's computationally quite expensive (think in terms of a number of machines running 24/7 for months at a time to find one such pair), and does not work for an arbitrary hash value -- it finds one of a special class of input strings for which a matching pair is (relatively) easy to find.
SHA is a hashing algorithm. You can compare the hash of a user-supplied input with the stored hash, but you can't easily reverse the process (rebuild the original string from the stored hash).
Unless you choose to brute-force or use rainbow tables (both extremely slow when provided with a sufficiently long input).
You can't do that with SHA-1. But, given what you need to do, you can try using AES instead. AES allows encryption and decryption.