Hello,
First off I am a complete noob at all of this and know very little about SHA256 Hash and have been trying to read up and learn what I can about it. I have read that SHA256 Hash are very hard to crack and was curious if it would be a good idea to generate a hash from a hash. Since it would be just as random and it would be 64 char that would have to be figured out seems like it would be unbreakable to me. Or am I mistaking? Would generating a hash from another hash be easy to crack since you knew which char the first hash generated? Hopefully this makes sense.
Example of what I am talking about.
Starting Hash
bc6f622525292996fbd592a1dcdaf7de33c8f2983d223a62a34f13d36390c05f
Then using the above hash to generate this hash.
72b9552553f31ee99d8a3b37c4150dd8966d487b47d1cfd0eabed80b2cc9f355
Then using the above hash to generate this hash.
154fd351815b5350bb99a98b1948d14eb7bb0c503a2f216e3c7e15af953df406
Is this a strong way to protect your hashes or easily reverse since you know which characters are being used to produce the following hash?
I've moved this to the General Talk forum since this has nothing to do with hashcat.
No, this is not a strong way to hash passwords. SHA2 is cryptographically strong, but is not appropriate for password storage because it is way too fast. You can create a fairly secure password storage function using SHA2 if you were to salt and iterate it; however, in your example above, you are only using 3 iterations and it is unclear if you are salting, so this scheme would be extremely weak.
Never never never design your own password hashing function. Always use a proven password hashing scheme designed by people who know what they are doing.
For decent examples of iterated & salted SHA2-based schemes, see sha256crypt and PBKDF2-HMAC-SHA256 (32-bit), or sha512crypt and PBKDF2-HMAC-SHA512 (64-bit.) However, note that SHA2 is very amenable to acceleration and thus has a fairly high Attacker-Defender Ratio (ADR), so neither sha*crypt nor PBKDF2 are really the best choice for password hashing. It is much better to use a memory-hard password hashing function such as bcrypt or scrypt, or the new Argon2 or yescrypt schemes when they are finalized.
Hey Epixoip,
First off I am sorry I posted this in the wrong forum :| my bad.
Second - there is no salt being added into my example above, you say this is not a strong way to produce a hash for a password. Is that because its easy to reverse the tree of hashes to find the starting hash? I checked this with a brute force calculator and its said it would basically take "ForEver" to be able to crack it. What am I misunderstanding about using a method like this to generate a hash from a hash?
You are relying on security through obscurity and ignoring Kerckhoff's Principle, as the security of your scheme comes solely from keeping the iteration count secret. However, when the iteration count is known/learned/guessed, the password is only protected by only three rounds of unsalted SHA256, which is extremely weak as it can be computed extremely quickly.
Three rounds is very easy to guess (there are crackers that already do this like mdxfind), but even if you used a larger iteration count, it could still be learned by reading the source, reverse engineering, etc. Especially in the case of web applications, many time the vector that was used to compromise the password database can also be leveraged to read other secrets on the system, such as the webapp source code, config files, etc. If we could rely on secrets being kept secret, then we wouldn't need password hashing in the first place. But we can't, so we do.
The example schemes I provided above do not hide their iteration count, as the security of the scheme does not depend on any obscurity. The security comes from thousands of iterations of salted SHA2. But again, SHA2 is easily accelerated so it is not really the best choice.
It is very clear that there is a lot of reading you need to do on the topic. There is a lot of information on this topic available on the Internet if you bother to search for it. In the meantime, please use a real password hashing function like those listed above, and do not attempt to create your own password hashing function. Look at some hashcat benchmarks and look at all of the algorithms that can be calculated millions or billions of times per second -- those are all people who designed their own password hashing functions and didn't have a clue what they are doing. Don't be one of those people.
Epixoip, thanks for taking the time to answer this question and explain to me why this wouldn't work. I do have a lot of reading to do and I have been doing a lot. I was just curious if it was easy to reverse engineer a hash like this and be able to find the hash that was used to generate it. From the sounds of things this is what the "MDXFIND" you mentioned would be able to do.
I am not trying to be one of those people who design their own password hashing, just trying to understand the flaws in using a system like this. It sounds like if you had an even longer list or a chain of hashes that where all generated from the hash before them that it would be even easier to crack the hashes to find out the has that was used before them to generate it per say. Hopefully that makes sense.
"Reversing" hashes is only possible for cryptographically broken hashing algorithms. Hashes being somehow reversible is not the problem you need to care about. But cryptographic hashes are optimized for easy hardware acceleration and high speed - exactly what you don't want for password hashes.
Passwords are cracked by running the used hashing scheme on known plaintexts and compare the output with the attacked hash. The faster you can calculate the password hash the easier it is to crack a password.
You should not worry much about the underlying cryptographic hashing algorithm but only about the used password hashing algorithm. bcrypt, scrypt, yescrypt and argon2 being strong ones as already pointed out by epixoip. All those PHA internally use cryptographic hashing algorithms but make sure to severely slow down attacks and prevent hardware acceleration. They all use salts, too.
Using no salt allows an attacker to crack an (almost) arbitrary number of hashes at the same time without significant performance hit. A salt (of proper size) will slow down an attack by the amount of hashes being attacked. 1 million hashes? -> 1 million times slower. What it does not help much against is attacking one single target hash (except preventing usage of default pre-calculated lookup tables like rainbow tables). But in this case still the other features of a PHA come to play: slowing down the calculation of a hash by all possible means while preventing acceleration through specialized hardware or optimized routines on generic hardware.
Your proposed scheme does prevent nothing of those things.
So basically what you're saying is that if someone had a word list of sha256 hashes they could just brute force that list against the current hash and hope to find a hash that would generate the current hash they know?
So taking my example
Starting Hash
bc6f622525292996fbd592a1dcdaf7de33c8f2983d223a62a34f13d36390c05f
Then using the above hash to generate this hash.
72b9552553f31ee99d8a3b37c4150dd8966d487b47d1cfd0eabed80b2cc9f355
Then using the above hash to generate this hash.
154fd351815b5350bb99a98b1948d14eb7bb0c503a2f216e3c7e15af953df40 <----if you knew this hash, you could just use a word list to brute force the hash above it, and hope to fine a match or fine another hash that produces this same hash.
my main question was if you had lets say 100 hashes that were generated from 1 SHA256 hash that if you knew 99 of those hashes it does it or doesn't it make it any easier to crack the last hash in the chain?
154fd351815b5350bb99a98b1948d14eb7bb0c503a2f216e3c7e15af953df40 (Starting Hash)
Use the above hash to generate 99 Hashes
Hacker knows all 99 hashes but doesn't know starting hash. Does having the 99 hashes that where generated from the
"Starting Hash" make cracking it any easier?
Hopefully that makes sense.
I'm starting to think you don't really understand how password cracking works.
I am pretty sure I said I was new to this! Forgive me for not knowing how this all works together right off the bat.
Okay let's asume you got 100 hashes and you know 99 of them (these 99 are hashes created in a chain from the 1st hash as you stated above).
Now please tell me how you come to the idea that knowing the last 99 will make it easier to crack the first? (Also what do you mean by knowing the hash?)
btw I'm not trying to be mean, really just curious.