Let's say in database user password is encrypting in MD5 and it's no more readable by human, but i can copy MD5 hash and go to any website which provide MD5 decryption and get actually password. So am I missing something?
MD5 is a one-way operation (hashing), it is not possible to decrypt it. But you can hash a lot of passwords and check whether the hashes are the same (brute-forcing). When you find a match, you can not know if that was the original password though, because many other passwords result in the same hash (collisions).
Mitigating brute-forcing and other cracking techniques is the goal of password-hash functions like BCrypt, SCrypt, PBKDF2 or Argon2. Absolutely use them instead of MD5 and you will see, that there exists no websites offering "decryption".
Related
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.
Before I use cryptography algorithm or whatever one i choose, how should I attach the salt to the password string? I was thinking I could put alternate characters from the password and salt into the string for hashing before i get to the end of the password string then tack the rest of the salt on or something like this? also what cryptographic algorithm would you recommend if i want to minimize the ease with which someone can get the password from the hash?
Don't use a cryptographic hash for password storage.
Use a slow, secure, tried and tested algorithm.
For example:
Bcrypt (the hashing algorithm, not the encryption one).
PBKDF2
Scrypt
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).
This question already has answers here:
What is the advantage of salting a password hash?
(3 answers)
Closed 8 years ago.
When using salt in a password hash, why is it recommended to use a different salt for each password and store it unencrypted in the database?
It seems so pointless. Surely if an attacker gets access to the database and they find out the salt it's just like having no salt at all?
If they are trying to crack passwords through bruteforce and they have the plain unencrypted salt right there in the same row as the encrypted password, they could just concatenate the salt with all the words/phrases they are going to try couldn't they?
The point of the salt is to prevent someone from attacking all the passwords at once. Since each password has a different salt, an attacker has to attack them individually. This greatly reduces the number of possible passwords he can try for each account.
Otherwise, an attacker could just hash a billion possible passwords and then compare each hashed password against his list.
See http://en.wikipedia.org/wiki/Rainbow_table first.
If you use a random salt for each password, the hacker cannot make use of a rainbow table.
You need to store the salt unencrypted, to be able to hash a string to check if it matches the salted hash of the original password.
Some crypt functions concatenate the unencrypted salt (amongst other things) to the encrypted, salted password. Der php bcrypt blowfish for example.
To bruteforce a hashed password, an attacker needs to try to hash all possible combinations of letters and symbols and compare it to the hashes he has.
If the attacker has bruteforced a plaintext > hash combination like this once, he knows the plaintext for all identical hashes.
A salt is added to a plaintext before hashing so the same plaintext hashes to a different hash, forcing an attacker to try all combinations of letters for each individual hash, slowing him down tremendously.
A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. The attacker has access to both the encrypted password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
If someone gets a hold of your DB, you're in big, big trouble for a variety of reasons. It would be a lot easier for an attacker to get (or guess) a single salt .. in theory. If they know the only salt you use, they can brute force all passwords simultaneously. If you use a different salt for each user, the attacker has to know each individual salt to attack effectively.
As for encrypting the salt for storage .. I suppose there's nothing wrong with doing that, it's just that it is hopefully rare that an attacker will be able to dump your entire DB. If they could, they may be able to get what they were after anyway even without having to circumvent authentication.
You need the salt to make rainbow tables and that sort of things useless.
The salt can be stored encrypted of course, making things a bit more complicated to crack a single password.
But look how it usually works: You send the salt to the client which uses it to hash the salt+password. So your client would have to decrypt the salt first, which can be done by any atacker in many cases. In cases where the attacker hasn't got the chance to observe the client-behaviour, encrypted hashes might improve security (security by obscurity).
I am possibly taking over an app that literally just encrypts user passwords by doing md5( password )
They have ~2000 users to date. How can I migrate those passwords to a stronger encryption schema (e.g. involving a salt, user-specific hash, and their password, all encrypted with sha1, bcrypt, whatever)?
MD5 is a cryptographic hash function, not necessarily an encryption method. A hash is designed to only be performed in one direction, and cannot be reversed other than by dictionary attack. As an example, you can try out this hash database lookup if you're feeling frisky.
You will probably want to save these old passwords in a separate column, then when the users login to the "new" system, compare the MD5'ed version of that password with the old one, and if the digest matches, perform SHA1 with a salt on that password and store that in a separate column.
Alternatively, and probably a better approach, is the force the users to change passwords... and when they enter their new one, use the new hash algorithm on it instead.