Topic: [SOLVED] What is the point of MD5?

[rv20]

Hope this topic is ok here as i would be using php to do the encryption..


So i have just worked out how md5 hashes work- i thought md5 made passwords ultra secure -  and for a password up to say 6 characters long, including numeric characters, then it is very easy to crack by doing a brute force, so i ask what is the point, i am wanting to encrpt passwords in a db and i can't see why my own 'home brew' method should be any more crackable than an md5 hash.

What encrption would you recommend, so there would need to be a php class avaialble.

[Ken2k7]

Hashing is not the same as encrypting. There is no way to revert or un-hash it. Someone can always decrypt an encryption. You can use your own method if you prefer. No one's stopping you.

Utilize salt + md5.

[BK87]

+1 salt.

[MadTechie]

Okay encryption is very complex, but if you want to write your own then go ahead, trust me, it sounds like a good idea but if i was a betting man, I'll be getting extra cash by not voting for yours (no offense indended),

the why you implement the protection is just as important as the encryption method used,
you say its simple you can brute force it.. okay that assumes you can get the MD5 from the server or the server doesn't have any lockout or delays built in, just say it take 1 second per password test
okay lets say your password is a number from 5 charactors in length, now that's and easy one totally insecure
so that 100000 seconds
1666.67 minutes
27 hours
So over a day!
and that's a very simple one with a fixed length and only a 5 charactors password
..
Okey lets assume you got the MD5 and your can crack ie in 10 seconds using rainbow tables etc..
how would a developer protect against this.. simple
md5(md5(password)+salt)
so you break the hash which reveals another hash you remove the salt and brute force it again. yay password.. this all assumes you got the hash..
but also remember my 5 charactor password.. well that was way the first hash is 32 charactors + salt..

if you want to be more secure then feel free to include md5 or even better use sha1, but to write your own from scratch is a bad idea..

The SHA-1 is based on principles similar to those used by Professor Ronald L. Rivest of MIT when designing the MD4 message digest algorithm [MD4] and is modeled after that algorithm [RFC 1320].

[neil.johnson]

crypt() has a few algorithms built in as long as the server supports them. DES, MD5, Blowfish

[Zanus]

then it is very easy to crack by doing a brute force, so i ask what is the point

You'll have a very hard time decrypting with brute-force..you'd need a super-computer to decrypt it.  Albeit, it's not even supposed to be decrypted.  You encrypt the input and compare it to the encrypted data/password.  So, you are wrong is assuming MD5 is easy to crack.

What encrption would you recommend, so there would need to be a php class avaialble.

I've always used MD5.  There's also sha-1.  And like it was mentioned before, you can add a simple salt to the hash anyway.  You should sleep fine using MD5.

[Axeia]

Read the comments on the hash methods on the php documentation pages.
There are a lot of people that tried to come up with their method and than some math wiz replies pointing out the 'custom' method is many times more insecure than MD5.

Think I read something about not using md5(md5($val)) as well as it would do no good whatsoever (or it might have been worse reducing the maximum number of results) but I really can't remember.

[MadTechie]

MD5 over MD5 okay but it does increase the collision rate.
however MD5(SHA1($pass)) is a bit pointless as your encrypting a 160bit encryption with a 128bit encryption,

[jonsjava]

Ok, if you're uncertain on how to securely encrypt a password that cannot easily be brute-forced, you could try something like this:

Code: [Select]

<?php
function md5_me($input){
$salt = "cheeseburgerinparadise";
$pass = md5($input.$salt);
$pass = str_ireplace(array("a","c","e"),"",$pass);
return md5($pass);
}
?>
What this does is it takes the users password, adds a salt to the end, MD5 encrypts it, strips out all instances of "a","c", and "e", then MD5 encrypts what is left.

There is no perfect solution, but if you must be paranoid with encryption methods, this should make you feel better. If someone gets the MD5 string, and brute-force decrypts it, all they will have is a partial MD5 of the salted password.

[Ken2k7]

I am not sure what difference removing a few characters in the md5() hash would do. I think it'll be the same difficulty in getting a md5(md5) value as the one you have right?

[jonsjava]

I'm just playing devils advocate here:

If you MD5 an MD5, and someone decrypts the finished product, then all they would have to do is decrypt the 2nd (errr....or first...) MD5 to get the plaintext.  My method is for those who don't trust the strength of MD5.

Personally, I trust salt+MD5 myself.

[Ken2k7]

Provided they know what the salt is during the second iteration. It's not easy. And I use a different random generated salt for each user so it's pretty hard to guess or even using brute force.

[rv20]

Ok, if you're uncertain on how to securely encrypt a password that cannot easily be brute-forced, you could try something like this:

Code: [Select]

<?php
function md5_me($input){
$salt = "cheeseburgerinparadise";
$pass = md5($input.$salt);
$pass = str_ireplace(array("a","c","e"),"",$pass);
return md5($pass);
}
?>
What this does is it takes the users password, adds a salt to the end, MD5 encrypts it, strips out all instances of "a","c", and "e", then MD5 encrypts what is left.

There is no perfect solution, but if you must be paranoid with encryption methods, this should make you feel better. If someone gets the MD5 string, and brute-force decrypts it, all they will have is a partial MD5 of the salted password.

Yup that is prety good, would take some mathematics to crack that if at all possible.

[N-Bomb(Nerd)]

Provided they know what the salt is during the second iteration. It's not easy. And I use a different random generated salt for each user so it's pretty hard to guess or even using brute force.

How does that work? I understand once a user logins it should be hashed and checked with what's in the database to verify login. However, how would it return a match if you've used a random salt, wouldn't that mean you would have to store the salt in the database as well?

If that's the case then the only way someone is really going to get the hash for someones login is if they take over your site or steal a cookie or something like that. However if they've taken over your server couldn't they just as easily look in the database to see the random salt?

[Daniel0]

Well yeah, you obviously has to store the salt somewhere. I tend to use two salts. One that's per-user and one that's per-application. The per-user is stored with the user's row in the database and I'll change it whenever I have the chance (i.e. whenever I have the user's password in plaintext). The per-application is statically defined in a config file.