This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Secure hash and salt for PHP passwords
Alright so im thinking of double hashing passwords with md5 (example hashing the password and then hashing the hash of the password). I want to know if anyone ever experienced any problems with this method and if you think its a good way to salt something. Thanks
I disrecommend hashing twice.
You might lose some password hashes, making your code even more insecure. It won't help with security.
The best way is to add salt to password and hash once!
The purpose of the salt is to make it more difficult to brute-force short passwords with pre-computed tables. You can make the salt user dependent.
MD5 is cracked. No matter how many times you rehash the hash, it adds absolutely no more security.
No it is not a good way to salt something.
Salting a password means adding extra data to the original password and then hashing the result.
You should generate a salt of at least 256 bits with a cryptographic random number generator, add that to your original password and then use a hash that has not been cracked, aka SHA-512.
MD5 is broken - so go far a SHA2 hashing. Hashing can be improved with salting and hashing in an iteration - which will secure you from dictionary and rainbow table attacks.
First, MD5 is significantly broken - Do Not Use, consider something like SHA-256 instead.
Second, salting is something quite different - having a hash(hash(password)) will not give you any security increase. See this for a further discussion: Secure hash and salt for PHP passwords
Related
I need to store the hashed password in the database the first time the user registers into the system. The standard approach is to take the Password and a salt, append them and use a hash algorithm whose output is saved in the database.
I am going to use Cryptographically Secure Pseudo-Random Number Generator(CSPRNG) for generating the salt. The salt generated using CSPRNG are very secured for generating salts as I have read from sources Link. Since the salt is very difficult to predict, using the MD5 for hashing the final String(Password || salt) is a good decision or is there any better alternative ?
NOTE:
The parameters I am considering for choosing a Hash Algorithm:
1) The security should be considerably good.
2) The hashing algorithm should be fast enough to not hinder the user experience.
This has been covered time and time again all over the internet, but here we go, once more...
Use bcrypt, argon2 or PBKDF2. Use a CSPRNG to generate a salt. Storing the salt with the hash is fine. Don't use MD5, SHA256, or anything else without an intentional iteration count.
Basically One-way functions have two properties:
1. Irreversible
2. Collision-Resistance(which means no two same words have the same hash value correct me if im wrong)
On the other hand i see that Salted Hash Passwords are used to provide more security to hash values of passwords and also provide collision-avoidance to passwords which have the same plain value.
So why does this happen, aren't hash functions supposed to have Collision-Resistance, why does Salt have to provide this when hash functions already have that property?
Thank you in advance.
It would be wonderful if one-way hash functions were really one-way.
What happens if two users choose the same password? Without salt, they get the same hash.
Guess what? People are not good at choosing passwords. These creatures of limited memory and lacking in natural internal cryptographic randomness often choose passwords that are short, low entropy, and brute-forceable.
If you want to crack the hash of a password that didn't involve salt, then just Google it.
Salt helps fix the problem, but it is not the panacea. With salt, two people who choose the same password do not get the same password hash, assuming the salt is different for both users. Salts also help prevent rainbow table attacks, which is a time-memory trade-off to hack out passwords.
Still, this does not solve all problems. If your database becomes public, salt + cryptographic hash is not enough because attackers can still brute force-passwords using low cost GPUs.
So what is the solution? You not only need salt, but you also need brute forcing to be a slow process. That's why we don't use hash functions for passwords, instead we use password hashing functions. Don't blame me for the stupid terminology, I fully agree. Bottom line: choose from bcrypt, scrypt, argon2, pbkdf2. I personally recommend bcrypt.
Just want to add a detail to #TheGreatContini s answer.
For passwords hashed without a salt, you will probably find an
already prebuilt rainbow-table.
If you use a single salt for all passwords, an attacker has to build 1 rainbow-table using this salt,
to get all passwords.
If each password gets its unique salt, an attacker would have to build a rainbow table for each password. Building a full rainbow-table to only get 1 password doesn't make sense, that's why we can say that unique salt prevents rainbow table attacks.
I'm not really up to date with the most recent developments regarding hashing algorithms strengths; what is currently my best bet for storing passwords?
Also, how much more security do salting and key stretching offer me?
MD5 has been broken.
SHA-1 has significant weaknesses.
SHA-2 is considered adequate at the moment.
SHA-3 will shortly become a FIPS standard.
Best practice is to combine password hashing with random salting and key stretching, e.g. PBKDF2.
A good discussion on password salting, hashing, and stretching.
My implementation of password salting, hashing, and stretching in C#.
As for the extra security provided by hashing, that depends on how many hash iterations you use. As an example, say that you decide to use 2^14 hash iterations. This increases the password's entropy by 14 bits. According to Moore's Law, each extra bit of entropy provided by the hash means approximately 18 extra months to crack the password in the same time as today. So it will be 21 years (14 x 18 months) before the iterated hash can be cracked in the same time as the raw password can be cracked today.
The extra security provided by salting is twofold: it prevents the effective use of a rainbow table, and it makes it more time-consuming to crack a large list of passwords (but not a single password).
Check out this.
This question over at security.stackexchange is a good discussion of bcrypt vs. PBKDF2 - Do any security experts recommend bcrypt for password storage?
The key is that a hash function alone will not prevent a precomputation attack (e.g. rainbow table). And adding a salt won't protect you from a dictionary or a brute force attack. You are much better using bcrypt or PBKDF2 than building your own scheme with a hash algorithm.
I have an application whose source code is checked into a public repository. This source code includes configuration files, and in those configuration files are SHA-256 hashed passwords.
My understanding is that when it comes to hashed passwords, an end user doesn't actually have to enter the password you used to generate the hash, but any password that generates the same hash value. I believe this is called a collision.
So can I display my hashed passwords in public with a reasonable assurance that someone can't take that hash and then generate a password (or generate a collection) that can be used to get access to my application? Is that a guarantee that these hashing algorithms try to make?
There are no known practical attacks against SHA-2 in the general case. It's generally considered better to keep hashed passwords secret, though, because there are rainbow tables, dictionary attacks, and other such things. If you took the proper precautions such as salting, round robin hashing, and having a nice long passphrase, it should be perfectly safe.
It's still better to not do this, though. You never know what cryptographic attacks might be developed in the future.
It is not likely for someone to reverse a HASH, SHA1, SALT etc. There are some ways out there to reverse one, but if you think your at that much of a risk I'd use SHA1 and SALT for maximum security. Having a long password makes it difficult to reverse, but unless they are real seasoned coders, your not very like to be a victim of it.
Read up on the algorithms at Wikipedia...
SHA1: http://en.wikipedia.org/wiki/SHA-1
SALT: http://en.wikipedia.org/wiki/Salt_(cryptography)
Just use a unique password and you should be fine ;-)
I mean actually making it hard to exploit even if the user has chosen a relatively simple password(s)? I can't think of anything besides using additional cryptographic functions.
There are a few things you can do:
A cryptographically stronger hashing algorithm.
Salts
Key strengthening (e.g. bcrypt / scrypt / PBKDF2)
Use all these techniques for the best security.
The last is not particularly efficient in terms of performance, but that's deliberate. The problem with most commonly used cryptographic hash functions is that they are designed to be fast to compute, which means that they are also fast to crack if the password is a dictionary word. The idea of key strengthening is to make the algorithm so slow to compute that even a weak password will take a long time to crack.
Don't think, read ;) (and ask on SO) You'll want to salt passwords with their own individual salt so that the same password won't result in the same hash
http://en.wikipedia.org/wiki/Salt_(cryptography)
You might want to add a salt http://en.wikipedia.org/wiki/Salt_(cryptography) to the password you're going to hash. Anyway, be aware that there'll always be some risk associated with hashing a password, take a look at this article http://www.f-secure.com/weblog/archives/00002095.html
Leave crypto security, and analysis of it, to the experts, and just use a better crypto function.
Not using MD5 for hashing passwords. The same goes for about any hash function that's optimized for throughput. The idea of SHA1 and MD5 is, that you can generate a compact representation of virtually unlimited amounts of data, so that you can check it's integrity and also sign it cryptographically.
The idea of hashing passwords is, that you cannot retrieve the password from the hash. However most passwords are shorter than their hash, and implementing a brute force or dictionary attack is trivial. So given a hash, the used hash function one can implement the check logic locally -- possibly on a massive parallel computer, think GPU -- and break passwords reasonably fast.
What you actually want to do is using a hash function, that's so computationally intense that hashing takes so much time, that even attempting a brute force attack on a 4 character password took hours.
Just add some salt to the user entered password.
$salt = 'random string';
md5(sha1(md5($salt . $_POST['password'])));
Almost no way that result can be cracked.