Re: Craking Serv-u passwords stored in .ini file.

From: Hans Porter (
Date: 09/04/04

  • Next message: Hans Porter: "Re: Any caveats for linux under VMware, pen testing?"
    Date: Sat, 4 Sep 2004 05:39:01 -0400
    To: "M. D." <>

    Hi Nekro,

       First off, let me say that I ran across Lepton's crack about a year
    ago when searching for something to crack Domino passwords, and I
    absolutely love the program! I like the Regex option, which most
    crackers don't give you, so kudos on that. Now, on with my comments.

    > It would have been much stronger, for example, the following:
    > 1) hash the password, with or without prepending the salt, doesn't matter. I'm not using it in this example:
    > password: test
    > MD5 hash: 098F6BCD4621D373CADE4E832627B4F6
    > 2) append the salt to the hash:
    > new "password": ab098F6BCD4621D373CADE4E832627B4F6
    > 3) hash the resulting string:
    > new MD5 hash: BDF3BAAC3C947956A57CFA97310B5DE0
    > 4) append the salt to the last hash if you like, but I don't see any particular reason to do so
       I agree, it would have been much stronger if this had been done
    rather than purely concatenating the "salt" of "ab" to the beginning
    of the password used. Although, as you state in point # 4, you don't
    see any reason to append the "ab" to the last salt if you, but you see
    no reason. There is actually a very good reason to do so. If salts
    are unique to the password, the system storing the hash has no idea
    which salt to use for a specific password UNLESS it is stored with the
    hash. So, unless we have "ab" stored there somehow, we would never
    know that "ab" was used in step #2, so we would never be able to
    compute and compare the hash resulting in step # 3, thus the user
    would never be able to logon. So there definitely is a need to store
    "ab" with the resulting hash. What could be done is take the user name
    and append the password to it and then hash, such that the username of
    nekromancer and a password of leptonscrack becomes
    "nekromancerleptonscrack", which results in the MD5 hash of:
    now, since everything used to generate this hash was supplied by the
    user (assuming that the algorithm is static for the system), there is
    no need to include anything in the hash to indicate the salt, as the
    username is already supplied in the credential record of the system
    (database, /etc/shadow, etc.). However, as you pointed out, it is
    trivial to use a password cracking utility that allows you to specify
    fixed strings for part of the password, as I can try my dictionary of
    words with the username (nekromancer) prepended. Granted, this will
    still work, but you really will never be able to defeat brute force,
    we need to try to combat precomputation attacks, where tables of
    global (non-salted) hashes are pre-generated for near instaneous

    Well, that's all I have. Keep up the good work with Lepton's Crack
    and I'm looking forward to the inclusion of typical salted MD5 (unix,
    Linux, Cisco) password support in the future.

       --- Hans

    Ethical Hacking at the InfoSec Institute. All of our class sizes are
    guaranteed to be 12 students or less to facilitate one-on-one interaction
    with one of our expert instructors. Check out our Advanced Hacking course,
    learn to write exploits and attack security infrastructure. Attend a course
    taught by an expert instructor with years of in-the-field pen testing
    experience in our state of the art hacking lab. Master the skills of an
    Ethical Hacker to better assess the security of your organization.

  • Next message: Hans Porter: "Re: Any caveats for linux under VMware, pen testing?"