hey guys,
i want to hash the password so it is totally encrypted, i am able to hash the password, but now the issue is i am not able to again get back the real password, is there any way i can get the real password using any of the hash, or is there any other way to encrypt and also decrypt the text into its original content...
Please reply as soon as possible..
Thanks and regards
abbas electricwala.
Hash is a one way encryption - that's the point - not to be able to get the original information from it. Hash is meant for verifying integrity. You can check if a entered string is the correct password by hashing and comparing the hashes with the one you had before.
The whole point of hashing a password is so that you do not have to save passwords in clear text. If someone can get the hashed passwords, he can't convert them back to passwords. Also, don't forget to salt your hashing otherwise your hashed passwords are vulnerable to rainbow tables.
Hashing isn't encryption, you cannot reverse it. You use hashing to check whether someone has a specific password, without knowing the password yourself.
The idea of hash functions is, to make it impossible to reconstruct the orignal data from the hash. Furthermore there are infinite different inputs to a hash function giving the same result.
If you want to check if a password entered in, say a login form matches the valid passwort, hash the newly input password and compare the hashes.
You typically can't and shouldn't. You also hash the received password and compare the two hashes
Theoretically once the data is converted using a one-way hash function, the hashed version of the data cannot be used to recreate the original data.
You may want to try a brute force attack against the hash code, using a dictionary. It naturally helps if you know which hash function has been used.
Related
So I've been looking at hashing passwords in vb.net and came across this thread (https://security.stackexchange.com/questions/17421/how-to-store-salt/17435#17435) and it showed about the salt only increasing the time to make brute force attack if the salt is known to the intruder as they need to make a new rainbow table. Could this be made more secure by making the salt a hash of the plaintext?
As an example to hash "plaintext" but adding a salt the string, this salt then being a hash of "plaintext" making "32nfdw213123" as example then hashing the total "plaintext32nfdw213123". In this case the salt is different for every value used but when used for verification doing the same process to a correct check string should produce the same salt and therefore the same hash value and verify. Is this actually more secure?
Thanks
TLDR: not really.
Longer answer:
Let's say some baddie has your database with all the passwords in it. He can now start brute-forcing passwords. Your goal is trying to make the brute-forcing as hard as possible.
So, theoretically, given that he has your database, he probably also knows how you're hashing your passwords (remember that security through obscurity is a bad form of defense). Your salts are no longer random, so our baddie can create a new rainbow table.
I have big database with user and passwords in sha256 hash. Now I write new version and I want to use sha256+salt. Is there a way to convert same passwords with sha256 to sha256+salt and have no trouble with login?
Surely it is a good idea to make your password hashes more safe, but using a salted SHA-256 is the wrong way to go.
Best practise is to use a password hash function with a cost factor, which allows to control the necessary time to calculate a hash. Good algorithms are BCrypt, SCrypt, Argon2 and PBKDF2. In another answer I tried to explain how the switch to a new algorithm could be done.
The problem with the fast hashes like SHA-256 is the unbelievable speed of GPUs, one can brute-force about 3 Giga SHA-256 per second with affordable hardware.
The way to salt and hash a password is to take the plaintext password, add the salt to it and THEN hash it. When you have an existing password database already sha256-hashed you don't have the plaintext passwords, and you can't easily get them back in plaintext once hashed (which is a good thing).
What you could do instead would be to take the passwords in their current form, sha256 hashed, add the salt and then hash them a second time - or better: many times, with better hashing algorithms.
The function to verify the password would then repeat those steps to check that the password is correct. Assuming the second hash is just sha256-hashing once to make the example clearer, though it's not sufficiently secure:
step1 = sha256(plaintext_password)
password = sha256(step1 + salt)
If you really want to avoid working on top of your existing hash you could create a new table of users where you process passwords in the new way from the beginning, and then gradually migrate user's passwords over to the new table as they log in with their plaintext passwords, and remove them from the old table.
A third solution could be to deactivate all the old accounts and require them to change their passwords before they can sign in again, via fx. e-mailing them a link to change their passwords.
Makes sense?
That said you will get more qualified answers at https://security.stackexchange.com . For instance I just found this question on why salt->sha256 hashing once is insufficiently secure, and another one here on how to process passwords for more secure storage.
I have a user table, each user has a password, and a password salt.
I want to reset every user password using a sql script, but I need to know which hash is used for password, here is an example:
pass : $2y$10$WjgvLQbIyx4Oab69b2vEKuOPafgWC2yzWD7JqYvC6dgvjW2iuNi/m
password salt: AF7
It looks as if the hashed password was generated with the PHP function password_hash.
The $2y$10$ at the beginning seems to indicate that the default algorithm was used (second parameter):
password_hash(password, PASSWORD_DEFAULT)
I hope you didn't use "AF7" as a salt for all passwords. That would completely defeat its purpose. It's the same as using no salt at all.
When setting new passwords, it's not relevant what hashing function was originally used. Instead, it's important what's used to verify the password. I assume that PHP's password_verify function is used. So you can easily use a different algorithm and a random salt. It's all encoded in the string that's stored in the database and password_verify will be able to handle it.
That looks like a hash generated by a method such as password_hash, bcrypt or a similar method.
Hashes are not encryption, they one-way functions designed not to be reversible, information is lost, by design, in the hashing function.
Normally a password is stored with a one-way algorithm, so that it makes hard to discover the plain text from it.
But I've been thinking: What if I store a SHA512 of both username and password melted together (A+B=SHA512), instead of the username and the password hash separately.
Is this method secure?
EDIT: In my opinion the Username 'salt' the password, so there will be no equal hash two times...
(1) You should be using something like bcrypt, scrypt, or pbkdf2 instead of something like SHAwhatever for password processing. Google this.
(2) How would you deal with forgotten password scenario?
(3) See my blog, particularly the section on "A simple example: protecting email address": https://littlemaninmyhead.wordpress.com/2015/09/08/a-retrospective-on-ashely-madison-and-the-value-of-threat-modeling/
Sure that would work. But would you ever want to retrieve a list of user names?
In the authentication implementations I have written, I use the username as part of the salt. That combined with a sitewide salt plus a bit of constant salt ends up creating around 120 bits of salt per username.
Is there a way to do this?
In my mapping class, I want to decrypt a MD5 password when I fetch my database data into entities. Is this possible?
Thank you!
MD5 can be used to encrypt passwords. MD5 is considered as a broken. What you do is you hash the password with MD5 and compare it with the original hash value in the database. Since MD5 is one way, if the passwords are same, hash value is same.
Edit:
If you are looking for cracking MD5 encrypted passwords, That is something different. Take a look at this
You mist first understand that this is not technology specific. These are basic computer science generic concepts which can be used implemented using various technologies. In you case C# and NHibernate etc.
To be simple, what you are doing with MD5(Message-Digest algorithm 5) is, you do hashing. because it is a hashing function. take a look at this.
But this MD5 is a one way hash function. "one way" means that it's nearly impossible to derive the original text from the string. That is why it is used for password encryption. Because you can not reverse a one way function and get the actual password. Take a look at this as well.
I assume that you want to check weather the inserted password is correct and allow log-in or do what ever necessary. You should not be doing decryption a password. If you are not going to crack a password. Password cracking is more of a guessing and scope can be reduced using the weaknesses of implemented methodologies(In MD5 hashing collisions).
In password creation, you take the password and you hash it using MD5(in your case).Then this hash value is what you are going to store in a database. Then next time you want to check weather the password is correct. Then you again take the password and you again hash it using MD5. then you take that hash value and compare it with the hash value in the database. If they match inserted password is correct.
I can see that you are new to SO. What I recommend is that you better learn these concepts first and the these concepts will help you irrespective of what technology you use.
You might as well ask if you can turn a pile of ashes back into the log before it was burned. Hashing is a one way action... you cannot "reverse" it. The only thing you could do is determine some source values that generate the same hash (hash collision).