Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Rainbow Tables for Password Auditing?

  1. #1
    Junior Member
    Join Date
    Oct 2005
    Posts
    17

    Rainbow Tables for Password Auditing?

    I am just curious, is rainbow tables any use for password auditing?

    I do not want to crack all the passwords but do want to check if they are secure, and reveal the unsecure ones which I am using John for at the moment.

    Maybe generate some alpha-numeric tables only and use Cain?

    What types of auditing could I do with SHA1 tables? I am looking for practical applications on how the different types of tables (MD4,MD5,SHA1, etc) could be utlized for auditing if possible.

    Or am I wasting my time and should just continue use John with some good wordlists.
    \"Luck is what happens when preparation meets opportunity.\"
    (Roman philosopher, mid-1st century AD)

  2. #2
    Banned
    Join Date
    May 2003
    Posts
    1,004
    You should just have your system utilize a password complexity requirement and skip all this stupid auditing.

    cheers,

    catch

  3. #3
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    Hey catch ,

    Could you give us a professional view on this?

    Like I would take the view that rainbow tables are brute force.............so it will depend on the size of tables and processing power, after all I think that we all agree it is not "if" it is "when"?

    and skip all this stupid auditing.
    NO! surely the purpose of auditing is to ensure that requirements are being met?...........or did you use to work for Enron

    And how do we factor in the vector? a skiddie with his 2gig tables, or Uncle Sam with his tables to crack a 127 digit pass?

    I am not "having a go", I would like to have a bit more detailed reasoning from a guy I would trust to be able to give me some answers.

    No rush mate, I know you are on a pretty big project of your own at the moment

  4. #4
    Banned
    Join Date
    May 2003
    Posts
    1,004
    NO! surely the purpose of auditing is to ensure that requirements are being met?...........or did you use to work for Enron
    This is a flawed statement.

    In this case you should not audit passwords, you should verify the system's password complexity requirements (as I stated in the first post.)

    And how do we factor in the vector? a skiddie with his 2gig tables, or Uncle Sam with his tables to crack a 127 digit pass?
    It doesn't matter, you can't consider every attackers' capabilities... all you can do is ensure that your own system meets an agrred upon definition of security (either industry best practices, trusted facilities manuals, or stakeholder definitions) in this case by verifying that passwords meet minimul complexity requirements.

    cheers,

    catch

    edited for typos and clarity

  5. #5
    Senior Member
    Join Date
    Aug 2003
    Posts
    185
    for auditing generate lm_alpha-numeric#1-7_0_2400x40000000_all.rt (5x640MB)
    so you are able to do a fast check
    put uncomplete passes into your wordlist and bruteforce
    may be you will minimize needed time for auditing
    Industry Kills Music.

  6. #6
    Junior Member
    Join Date
    Oct 2005
    Posts
    17
    Thanks. Thats a good idea for a fast check.

    I might generate a set of those tables (lm_alpha-numeric#1-7_0_2400x40000000_all.rt) and try to integrate this into our password auditing process.
    \"Luck is what happens when preparation meets opportunity.\"
    (Roman philosopher, mid-1st century AD)

  7. #7
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    OK catch what we are saying is:

    1. Set system rules for passwords.
    2. Test on entry and refuse non-compliant ones.

    Basically you are arguing for a proactive, rather than a reactive approach?

    That does seem to be "the better way to go"?


  8. #8
    Banned
    Join Date
    May 2003
    Posts
    1,004
    OK catch what we are saying is:

    1. Set system rules for passwords.
    2. Test on entry and refuse non-compliant ones.
    What we are saying? What I am saying, everyone else is saying that you should audit each password. Attempting to brute force the passwords is useless:

    1. It is needlessly time consuming (verifying correctness of a password complexity requirement take only a few minutes with compehensive testing)
    2. It won't flag very basic password (checking every possible password up to 10 chars for Springfield Nuclear Powerplant won't tell you that Homer's password is "margesimpson" even though this could be easily guessed)
    3. It may divulge private information (many users use the same or similar passwords across different user accounts, there is no reason for the admin to discover potential ebay or web banking passwords)

    At the end of the day, password cracking as a means of auditing serves no purpose, is a waste of resources, is ineffectual, and may be a violation of the corporate security policy as it flies in the face of CSC-STD-002-85 (the Green Book). This type of auditing merely serves the auditor's sicko ego needs of feeling one up over the users.

    cheers,

    catch

  9. #9
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Unusually, I'm totally with catch on this one.

    My take on it is:

    - Set whatever password complexity policy you feel is necessary (although bear in mind that excessive requirements can actually make things less secure by forcing users to write the passwords down)
    - If you don't need it, DISABLE LANMAN PASSWORDS on NT based systems. Nobody needs lanman passwords these days, only ancient (DOS?) clients require them. This may make cracking the passwords harder, but you shouldn't need to do so yourself.

    Slarty

  10. #10
    Senior Member nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,188
    Yes, I can see the various objections.

    My main reservation is that any sort of auditing retrospectively is a weakness in the process. If I have set a complexity policy then I would want that validated before a password was accepted, otherwise there is a potential period of vulnerability?

    Apart from that, brute force cracking does seem a rather crude and laborious approach?


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •