How can I crack a salt, when I know the password and the final salted hash? I would be very graceful for help. And sorry for my bad English.
I've searched for some information about this topic but I didn't find anything!
Related
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.
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).
I have a old database where password is in Hashed format,i need to decrypt hashed password.Is there any method in membership to decrypt hash password.
The hash is probably designed to be one way. If you know the hashing algorithm used you could use brute force, but otherwise no, there is no way to "decrypt" the password.
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.
Ok, I’m trying to understand the reason to use salt.
When a user registers I generate a unique salt for him/her that I store in DB. Then I hash it and the password with SHA1. And when he/she is logging in I re-hash it with sha1($salt.$password).
But if someone hacks my database he can see the hashed password AND the salt.
Is that harder to crack than just hashing the password with out salt? I don’t understand …
Sorry if I’m stupid …
If you don't use a salt then an attacker can precompute a password<->hash database offline even before they've broken into your server. Adding a salt massively increases the size of that database, making it harder to perform such an attack.
Also, once they've broken in they can guess a commonly used password, hash it, and then check all of the passwords in the database for a match. With a different salt for each user, they can only attack one password at a time.
There's an article at Wikipedia about salts in cryptography.
Another intention behind the use of a salt is to make sure two users with the same password won't end up having the same hash in the users table (assuming their salt are not the same). However, the combination of a salt and a password may lead to the same "string" or hash in the end and the hash will be exactly the same, so make sure to use a combination of salt and password where two different combination won't lead to the same hash.
If an attacker creates a giant table of hash values for plaintext passwords, using a salt prevents him from using the same table to crack more than one password. The attacker would have to generate a separate table for each salt. Note that for this to actually work propertly, your salt should be rather long. Otherwise the attacker's precomputed table is likely to contain the salt+password hash anyway.