2

Hey Guys im thinking about something what i can do to improve the current password safeness. Most of you know rainbow tables which can decrypt "hacked" md5 hashes in seconds.

My thought was, how can i make this more secure. What if the "hacker" who hacked got some md5 hashes has not the full md5 hash?

For example, the password i choose "rabbit" md5 hash equals (a51e47f646375ab6bf5dd2c42d3e6181) Nearly every rainbow table in the internet can decrypt these md5 hash into the clear word "rabbit".

But what if i parse only the first 10 signs into the database. And if the user sign in with its password it will be checked if the first 10 signs equals the 10 signs in the database. So, if the hacker got some hashes he could not revert any of them because none of these makes any sense..

Is this possible and really more secure?

This is only an idea which had and i would really appreciate it for your comments.

Thanks!!!

YeppThat'sMe
  • 1,812
  • 6
  • 29
  • 45

3 Answers3

3

I would recommend to follow Secure hash and salt for PHP passwords

Community
  • 1
  • 1
Moyed Ansari
  • 8,436
  • 2
  • 36
  • 57
  • 1
    While this may theoretically answer the question, [it would be preferable](http://meta.stackexchange.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. – Matt Ball May 05 '12 at 17:34
2

While this does make driveby rainbow table-based attacks less viable, it doesn't really add security. Once the attacker figures out you're using 'trunctated' MD5 hashes, your approach actually makes things easier for him or her - after all, s/he doesn't have to find the one single phrase with the correct hash, just one that shares the first 10 characters or so.

This is almost a textbook example of security through obscurity, I'm sorry to say. It's good that you're thinking about ways to store passwords more securely - and that you're aware that using plain MD5 hashes is not a good idea - but this is the wrong approach.

Yuka
  • 473
  • 2
  • 10
  • Oh okay ;) but thanks for that answer. Im not a pro in such things related to security but im interested in. Then i have to use more secure methods which are already recommended. But thanks a lot for explaining why this is the wrong approach!! :) – YeppThat'sMe May 05 '12 at 17:39
1

A more secure way to store passwords is to use a different hashing algorithm for each user - or to use different parameters for a hashing function per user and store that. This way someone would have to generate rainbow tables for a ton of different possibilities.

Check out Salting for more information.

K2xL
  • 9,730
  • 18
  • 64
  • 101
  • 1
    While this may theoretically answer the question, [it would be preferable](http://meta.stackexchange.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. – Matt Ball May 05 '12 at 17:31
  • @MattBall I agree. I updated my answer to include more information. – K2xL May 05 '12 at 17:40
  • Isn't that impossible without to store both the password-hash and which encrypting method was used? And if there is mentioned which password method is in use it would also be easy to crack it?! If not i have to check each password against any password hashing method which is in use… i think this will need a lot of performance on a huge system with a lot of users – YeppThat'sMe May 05 '12 at 17:47
  • @YeppThat'sMe Here's an example... md5($RandomSaltStoredForUser.$password). You can also change the salt every time the user logs in. – K2xL May 05 '12 at 17:57