I guess it's time to make sure you use Blowfish hashes. Hash tables for fast cracking

I'm not really a human, but I play one on earth. flash japh

Replies are listed 'Best First'.
Re: OT: Cracking hashes made easier
by Corion (Patriarch) on Nov 11, 2005 at 13:20 UTC

    A lookup table doesn't help you if the (MD5) hashing is set up correctly:

    my $secret = "Secret Passphrase"; my $password = get_password; my $salt = get_username; die unless $password; die unless $salt; my $md5 = md5($secret.$password.$salt);

    That way, as long as the $secret remains secret, the hash lookup cannot be reversed to something you would enter in the password entry field, unless all entries in the hash lookup list have the same (secret) prefix.

    Of course, if you can create enough users (and passwords), you can try an attack to recover $secret.

      Of course, if you can create enough users (and passwords), you can try an attack to recover $secret.
      That's the thing about hashes and reverse lookups; given a hashed value, the reverse lookup table gives you an input that hashes to that hash value, not necessarily the input that was used initially. So, I think that by employing your scheme, an attacker is highly unlikely to recover the secret. Of course, I'm not a cryptographer, so I may be missing something.

      thor

      Feel the white light, the light within
      Be your own disciple, fan the sparks of will
      For all of us waiting, your kingdom will come

        If you're using a 128 bit hash, and your key+password is less than 16 characters, then the shortest reverse lookup is probably the right one.

        If we include the fact that key+password are usually made up of typeable characters, then the shortest reverse lookup that is typeable is probably the right one out to 19 or 20 characters.

        I suspect that fairly few people use a long enough secret key to provide protection against this fact. But if you do, then you're right that the secret is still protected.

        Depending on what the secret is used for, that might not matter. For example, if it is a password, a hashed version of my password is stored on the server. ONLY the hash is stored, not the original password. When I try to log in, whatever I type is hashed, compared with the stored hash, and if it matches I am allowed in, regardless of whether I type "ilikepie" or "iamquicheeatinghippyscum".

        Yes, that's a somewhat naïve scheme, but it serves to illustrate the point.