1

I recently obtained the l0pht-CD for windows and tried it out on my PC and It WORKS!!

2600hertz.wordpress.com/2009/12/22/100-windows-xp-vista-7-password-recovery

I'm designing a "Login-Simulator" that stores pwd-s in a similar manner. The current implementation will be vulnerable to the above attack. Plz could anyone illustrate (in as simple terms as possible), how to strengthen against such a rainbow tables attack.

MY GOAL : Build "Login-Simulator" to be as secure as possible. (Read Hacking Competition ;-) )

Thank You.

AstroCB
  • 12,337
  • 20
  • 57
  • 73
TheCodeArtist
  • 21,479
  • 4
  • 69
  • 130
  • 1
    You want *to strengthen the rainbow table*? I have to admit that I did not read the URLs you posted - but normaly you strengthen the login process against the use of rainbow tables. Read here: http://stackoverflow.com/questions/1012724/what-exactly-is-a-rainbow-attack and you protect agains this kind of attacks by using a salt: http://en.wikipedia.org/wiki/Salt_(cryptography) – tanascius Apr 20 '10 at 12:38
  • I think he's actually trying to strengthen the hash. – SLaks Apr 20 '10 at 12:40
  • 1
    @SLaks, @tanascius: Yes, I think he's actually trying to figure out how to make his login simulator _defend_ against rainbow tables. It's not worded very well. – John Feminella Apr 20 '10 at 12:43

2 Answers2

14

Since a rainbow table is a series of precomputed hash chains for various passwords, it is easily foiled by adding a salt to the passwords. Because hash functions usually remove much of the local correspondence between input and output (that is, a small change in input produces large, seemingly unrelated changes in output), even a small salt will be immensely effective.

Best of all, the salt does not need to be secret for this to be effective; the rainbow table needs to be recomputed for all possible password-salt combinations.

John Feminella
  • 303,634
  • 46
  • 339
  • 357
9

You should use bcrypt, which has been designed by professional cryptographers to do exactly what you're looking for.

In general, you should never invent your own encryption / hashing schemes.
Cryptography is extremely complicated, and you should stick to what has been proven to work.

However, the basic answer to your question is to add a random per-user salt, and switch to a slower hash.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • @SLaks. Thanks for bcrypt. Regarding the "salt" i have a doubt. if my password is "test123" and salt is "small-salt" then it can still be easily broken. Right?? the aim is to make the salt "really-long-and-computationally-hard-salt" Am i right??... – TheCodeArtist Apr 20 '10 at 13:09
  • The salt should be a reasonably long array of completely random bytes. – SLaks Apr 20 '10 at 14:10