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].

 

[JonnoTheDev]

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

[Zane]

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:

 

<?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:

 

<?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.

[rv20]

This is a bit off topic but, i downloaded an "md5 bruter" cracker, just for learning purposes.

 

Anyway, i set a character set of [a-z][A-Z][0-9] and 3 more symbols :_- i then generated an md5 for a 12 character password in php md5("passpasspass") etc  and fed that md5 into the cracker now the cracker tells me that this will take about 32,000 years to crack.  How long do you think it would take if you hooked up say 10 supercomputers and coded the cracker in assembler?

[MadTechie]

You might as well use 1000 PS3 it would probably be quicker, super computers are good for heavy calculations but the playstation 3 was designed to do simple calculations quickly, no matter how you do it, you still have the getting the HASH & salt problem

[Daniel0]

I think 1000 PS3s would be regarded as a supercomputer by most computer scientists. In this article they refer to a cluster of eight PS3s as a small supercomputer.

[MadTechie]

Cool and add this article

With about 200 PlayStation 3 (PS3) farm (its Cell processor is popular with code breakers because it is good at performing cryptographic functions)

and we have some good cracking options

[waynew]

If an attacker can read your md5 password hashes, encryption strength would be the least of your worries.

[N-Bomb(Nerd)]

As extreme as this sounds, would something like the following work?

 

Get a domain and some hosting on a different box, then creating only one script (the hashing script) on that hosting for maximum security purposes. Then sending whatever you want to that script that you want hashed and it will only output the hashed version of whatever you sent to it. Then of course reading the source of the output of the script would contain your hashed string without the actual hashing method on the local box. Therefore if you do get hacked or something happens then nobody knows exactly how you've came up with your hashing method. What's a few extra bucks for the safety of your members? 

 

Yeah, I might be extremely tired at the moment.. but it honestly sounded like a good idea like 20 minutes ago on the shitter.

[Daniel0]

No, because obscurity is not security.

[GingerRobot]

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

 

<?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.

 

You really are missing the point of hasing. Hashing is a one-way process. It cannot be 'cracked'. Yes, you can use rainbow tables. Yes, you can analyse the algorithm in order to increase the chances of collisions. No, you cannot reverse it.

 

For example, if i tell you a number is 6 mod 7, what was the original number? You can't tell me. You can tell me an infinite amount of numbers that are also 6 mod 7, but you cannot guarantee that you're telling me my original number. Therefore, you cannot reverse it. While this is an extremely simple example, it should illustrate the point.

[Daniel0]

Another way that you could say it is that the cardinality of the domain is infinite, but the cardinality of the range if finite. MD5 will always output a 32 digit hexadecimal number. There are 16 different hexadecimal digits, so that means 16³²≈8.7*10⁴⁰ distinct outputs. It's a lot, but clearly much lower than the infinite number of possible inputs. Incidentally it also means that there is a fixed upper limit on the number of checks you have to perform before you will get a match*.

 

You say that if x₁ ≠ x₂ and f is a hashing function then if f(x₁)=f(x₂) you have a hash collision. There is an infinite number of hash collisions. As GingerRobot said, this means you cannot reverse it. However, in terms of checking the hash of an entered password with the stored hash of the real password, it is irrelevant whether or not you can reverse it because one of the colliding inputs will also match and log you in. This is also why doing things like md5(md5()) is a bad idea. Doing that you are drastically decreasing both the final domain and range and thus increasing the chance of a hash collision.

 

 

* I'm not 100% sure this last statement is true.

[aschk]

Here's what I would do.

1) Use SHA1 not MD5 firstly.

2) Use salts.

3) If you're providing login facilities, then also provide a limited number of access attempts, before locking out the account (e.g. 3).

 

Thus, if you have a lockout time of say 30 minutes for every 3 attempts, you adding a HUGE amount of time to any possible crack. Also, it would be a good idea to log the offending attempts with IP address so you can backtrace any potential threats to their source and implements IP banning on top if you see patterns of attempts from the same IP.