Is there any point encrypting passwords with more than md5?_问答_开发者

I am not a security expert... so I might be very wrong here.

Am I right in that the only advantage to using a stronger algorithm is to slow down password cracking?

In which case they must have the password hash and so will have already comprimised my database right?

As I do not store any thing of real world value wh开发者_高级运维at is the point in using a strong password algorithm? If they are already in my database they can change anything they want so why would they want the passwords?

The only reason I can see would be to slow down brute forcing and to secure my users passwords in case they use the same one for their email accounts...

I have implemented SHA256... but I am wondering if it was worth it

MD5 isn't encryption, it's a one-way hash.

The only purpose of using a better one-way hash is to delay reversing the password. As computers have become more powerful and vulnerabilities in various hashing algorithms have been discovered, better hashes must be developed.

In which case they must have the password hash and so will have already comprimised my database right?

The purpose of salting and hashing passwords is to protect the password itself, even in the event of database compromise. Many (most) users use the same password for multiple logins, so if it's compromised, so is every account it's linked to.

SHA-256 should be more than sufficient, but make sure you're also salting the passowrd. Your functions should look like this (pseudo-code):

fun store_password(plaintext):
    salt = random_alphanumeric(40) # maybe put 40 in a config, or #define somewhere
    hashed = sha256_digest(salt + plaintext)
    return "sha256!" + salt + "!" + hashed

fun check_password(plaintext, stored):
    algo, salt, hashed = stored.split("!")
    if algo == "sha256"
        return (sha256_digest(salt + plaintext) == hashed)
    else if ... # other supported password schemes here

A commenter below pointed out that with a sufficiently powerful attacker (or, weak passwords), storing the full salt might allow the plaintext to be brute-forced. If you're concerned about that, use a two-part salt. Generate part of it every time (saltA), and store the other in a config file (saltB). Then combine them to generate/check passwords:

import my_config

fun store_password(plaintext):
    saltA = random_alphanumeric(40)
    hashed = sha256_digest(saltA + my_config.saltB + plaintext)
    return "sha256!" + saltA + "!" + hashed

fun check_password(plaintext, stored):
    algo, saltA, hashed = stored.split("!")
    if algo == "sha256"
        return (sha256_digest(saltA + my_config.saltB + plaintext) == hashed)
    # ...

Note that if you choose this system, changing your saltB will invalidate every stored password.

Jeff has a great post titled You're Probably Storing Passwords Incorrectly which addresses the issues surrounding this type of password storage. Highly recommended reading.

Yes. If someone gets your database with your passwords in it, using something stronger than MD5 will slow down their ability to do a dictionary attack against the whole thing. The really important thing you need to do along with this that increases security by leaps and bounds is to add a salt to your passwords before hashing them.

Basically you should read everything that's pertinent to what you're trying to do at http://www.owasp.org and follow it to the T, unless you count yourself as a security researcher.

Don't use MD5 for cryptographic purposes - it's broken! Use the SHA256 you implemented, or better a library widely tested (I bet you missed many security issues in your implementation).

BTW: cryptographic hash functions are built such that you cannot decode the initial text. Encryption always you to restore the original text only if you know the password.

Using a stronger algorithm is probably worth it.

First of all, most users of MD5 are probably using a library that has been tested and reviewed. A lot of these libraries are no-cost and open source. And most of these will also provide SHA-1, and maybe even the SHA-2 algorithms.

So, the "cost" of using SHA-1 or SHA-256 is likely to be very small.

On the other hand, what is the value? Even though an application might not contain much data of significance, and a compromise of the password table is likely to include the rest of the data anyway, it helps to remember that most passwords are used for multiple applications. Even though the user might not care about your application getting hacked, they will be upset if that gives the hackers access to the password they also use for banking.

I think that it's worth upgrading to a better hash algorithm.

Also, the motivation for ditching MD5 in favor of SHA-1 or SHA-256 would be that MD5 is "broken." There are shortcuts to find hash collisions, so that brute-force isn't required. To slow down a brute-force attack, you also need to use a key-strengthening technique. Usually, this means repeating the hash operation a few thousand times. You'll also need to use a random salt to thwart pre-computed lookup tables, like rainbow tables.

Of course, algorithms like the key derivation algorithms in PKCS #5 spell out in detail a secure way to "hash" passwords for authentication tables. Using a standard like that will give you access to high-quality analysis of your chosen technique, and alert you to potential vulnerabilities. You are also more likely to find implementations that have already been widely reviewed and tested.

Yes, SHA-256 is recommended for passwords. In fact for secure US government software it's mandated by NIST starting in 2010.

See http://www.openssl.org/ for a free, open-source cryptographic library that's validated by FIPS. It implements message digest algorithms, including the SHA-2 family.

There are still legitimate uses for MD5, SHA-1, and other hashing algorithms of lesser strength, but they are not recommended for hashing passwords.

If the password is crossing the wire in any unencrypted way (e.g., it's a password for a web app running on a non-SSL server), then they wouldn't necessarily have access to your DB, just to the wire traffic. So in this case, you'd want to make sure that password was as protected as you can get it within reason, hence using something stronger than MD5.

If you enforce better passwords it will do the job without changing the algorithm. md5 should not be reversible, at least not to a wannabe novice "hacker". using good passwords (longer than 12 chars and using both numbers, capital and small letter) will do a better job than changing the algorithm.

@John Millikin had good point about salting the password - which is even better than just enforcing good password.