What does salt mean in bcrypt hashing?
Can I retrieve plain text from salt and hash?
Is there any online websites or tools to decrypt bcrypt hash correctly?
Thank my dear freind.
The point of hashing is creating input => output transform that's hard to reverse.
The point of salting the input is to prevent identical inputs from getting the same output by adding some random portion to input sequence before hashing.
So no, you cannot retrieve plain text from salt and hash (other than brute forcing or exploiting, if any, vulnerability of bcrypt algorithm or it's implementation).
Related
This question already has answers here:
How long to brute force a salted SHA-512 hash? (salt provided)
(3 answers)
protect hash code? [closed]
(2 answers)
Closed 3 years ago.
I have a question regarding the purpose of hashing passwords. I understand that hash functions are a one way pseudo random algorithm that turns a string into a seemingly random n-bit string (depending on the hash). Sure, this means that they cannot be reversed to find the original string and they do not need to be stored as plain text in a database. But if the hashed passwords were to be obtained or leaked in any way, what is stopping someone from performing the same hash function on them to crack the passwords? There exist a few number of hash generators online such as MD5, SHA-1 and SHA-256 that anyone can (potentially) use to brute-force or dictionary attack a list of hashed passwords if they wanted to.
Maybe the idea is that one does not know what hashing function was used to generate the hashes? But even then the length of the hash itself could give it away. Maybe it's because hashes take a while to compute? But couldn't online generators speed up the process by mapping lists of words to certain hashes?
Any help or understanding would be greatly appreciated!
Salting the hash prevents the brute forcing and the usage of rainbow tables.
From Wikipedia:
In cryptography, a salt is random data that is used as an additional
input to a one-way function that "hashes" data, a password or
passphrase. Salts are used to safeguard passwords in storage.
I'm very close to understanding exactly how the compare function of bcrypt works, but there are a few missing holes in my knowledge.
My understanding so far:
brcypt gens a hashed password using a plain text password and a randomly generated salt. The hashed password is a combination of the bcrypt version, the hashed salt and the concatenated hashed plain text password. When a user logs in, their plain text password is ran through the compare function. At that point, bcrypt knows how many characters in the hash and from what offset to begin to slice the hashed salt out of the full hash. It then concatenates the salt with the passed in plain text password, running it through the hashing algorithm to arrive at the final hashed string. The hashed string is compared to the hashed string in the database and if there is an exact character match, the password is correct.
2 questions..
Aren't hashes supposed to be impossible to reverse? If so, then how does bcrypt know how to decrypt the hashed salt and then use it to hash the incoming plain text password. That doesn't make any logical sense to me.
If brcypts algorithm is written such that it can always create a hashed salt that it always knows how to decrypt, can't hackers just use that algorithm to grab every hashed password from a database and slice the salts out? Then it could create a rainbow table for every salt and crack each individual password? That seems logical to me.
Pardon if my question doesn't make any sense. Happy to edit.
Read articles, read stack overflow questions, watched videos and asked a senior engineer.
A rainbow table is a pre-compiled list of every password you can find, and their hash.
Your rainbow table has:
hash("password1234")
hash("hunter2")
hash("correct horse battery staple")
But it doesn't have:
hash("ȃ#🙍♽😔ƅ😠☸☑+password1234")
hash("ȃ#🙍♽😔ƅ😠☸☑+hunter2")
hash("ȃ#🙍♽😔ƅ😠☸☑+correct horse battery staple")
You could go ahead and create a rainbow table that contains every password for this salt. But that's just called a Brute Force attack.
And this second rainbow table doesn't help you with the next website that chooses a different salt:
hash("®óó»♠☘☛🙈Ũh+password1234")
hash("®óó»♠☘☛🙈Ũh+hunter2")
hash("®óó»♠☘☛🙈Ũh+correct horse battery staple")
And to eliminate all the guesswork, and all the difficulty of storing a salt, and deciding a salt: modern password hashing algorithms generate a different random salt for every password for you, and store the salt in the resulting hash string for you:
hash("ȼŚ😑¥dĥ😥®µ+password1234")
hash("ČɆǝ%ËȌÁpmLȫ+hunter2")
hash("♼♄ș♰;⚁f)²ŋì😱³UÍ+correct horse battery staple")
Which is in essence what bcrypt does; it generates a different salt for every password.
As an ordinary method, I always used to save MD5 of passwords in database while there are many websites that decode the MD5 hashed data to its original data (using rainbow database).
I wonder if it is more safe to modify the output of MD5 function (e.g. omitting the last character of MD5 output to create a new hashed data)? or there is a logic behind the MD5 that makes is more safe than every modified version?
No this doesn't do much good to make your passwords more secure. It adds a bit of "security by obscurity", but when we hash passwords, we prepare for the case where the attacker knows the hashes and the algorithm.
The problem with MD5 in general and with derivations is, that they can be calculated ways too fast. With common hardware you can calculate 8Giga MD5/s, which makes brute-forcing too easy. Todays password cracker tools do not only offer plain MD5 hashes, you can calculate also derivations, e.g. md5(strtoupper(md5($pass))) out of the box.
For a secure storing of passwords you need a slow hash function like BCrypt, PBKDF2 or SCrypt with a cost factor. Of course they should be salted with a unique salt per password.
Perhaps you should consider a different hashing algorithm instead?
https://security.stackexchange.com/questions/4789/most-secure-password-hash-algorithms
I know about storing passwords as salted hashes and I know it is even safe enough for Linux.
But even before I knew this, I was wondering if it is safe to store a password in an AES container encrypted with the password itself.
In case my question got incomprehensible, some pythonish pseudo code:
AES(data=password, key=password)
No, that is not as safe as using a Password Based Key Derivation Function. The most important issue with passwords are dictionary and brute force attacks - trying passwords, in other words. Now the outcome of AES(data=password, key=password) is always the same value (as the calculation does not contain any salt). This means that building a rainbow table is possible. Furthermore, AES is a very fast, so it is very easy for attackers to check many passwords.
So you are much better off using a PBKDF such as PBKDF2, bcrypt or scrypt, with a high iteration count and at least 64 bits of random salt.
I remember a guy telling me that if I let him change 4 bytes he can make a file have any checksum he wants (CRC-32).
I heard mention of salting a hash. I am wondering if someone had his file match my file would salting the MD5 or SHA-1 hash change the result so both files no longer collide? Or does it change the end hash value only?
You are mixing up two different uses of hash values:
Checksumming for guarding against random (non-malicious) errors.
Computing cryptographical message digests for storing passwords, signing messages, certificates ...
CRCs are a good choice for the first application, but totally unsuited for the second, because it is easy to compute a collision (in math-speak: CRCs are linear). This is what your friend is essentially telling you.
MD5 and SHA1 are cryptographic hashes intended for the second kind of application. However, MD5 has been cracked and SHA1 is considered weak these days. Still, even though MD5 can be cracked it takes a long time to find MD5 collisions (days to weeks).
As for salt, it makes the computation of the cryptographic hash local by mixing in some random non-secret value, this value is called the salt. This prevents computing global tables which make it easy to compute possible values (e.g. passwords) from the hash value. The computation of the tables is extremely expensive, but without salt the cost would be amortized over many cracked passwords.
The attack (against CRC-32) is irrelevant if the hash you are using is not CRC-32 - MD5 and SHA-1 are not vulnerable to that kind of attack (yet).
The current attacks against MD5 are where an attacker creates two documents with the same hash.
Salts are used for password verification - they prevent an attacker performing an offline attack against the password database - each user's password has a salt attached to the plain-text before the hashing - then a pre-computed rainbow table of plaintext <-> hashed text is useless.
Adding salt to your hash function doesn't really serve any purpose if the digest function has been compromised, because the salt will have to be made public to be used, and the attacker can adjust their file to factor this in too.
The solution to this problem is to use a secure hash function. MD5 has shown to be vulnerable to hash collision, but I believe SHA-1 has not (so far).
Salting is usually used in password hashes to avoid dictionary attacks. There are plenty of web based reverse hash dictionaries where you enter the hash (say: 1a79a4d60de6718e8e5b326e338ae533) and get back the text: "example". With salt, this becomes next to impossible. If you prepend a password with random salt, the dictionary attack become more difficult.
As for collisions, I don't think you need to worry about entire files having the same md5 or sha1 hash. it's not important. The important use of the hash is to prove the file you receive is the same as the file that was approved by someone who is an authority on the file. If you add salt to the file, you need to send the salt so the user can verify the hash.
This actually makes it easier for the attacker to spoof your file because he can provide a false salt along with the false file. The user can usually tell if the file is faked because it no longer serves the purpose it is supposed to. But how is the user supposed to know the difference between the correct salt and the attacker's salt?