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. :)

You should just have your system utilize a password complexity requirement and skip all this stupid auditing.

cheers,

catch

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"?

Quote:

---

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 :p :D

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 :)

Quote:

---

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.)

Quote:

---

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

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

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.

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"?

:)

Quote:

---

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

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

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?

:)

Of course...

PHP Code:

---

Enter new password: *****
Sorry must be at least eight (8) characters.

Enter new password: ********
Sorry your password may not contain personal information such as your name or user name.

Enter new password: ********
Sorry your password must contain at least one (1) non-lowercase alpha character.

Enter new password: ********
Retype new password: ********
Thank you. 


---

Is the way all systems I've ever used do it...

cheers,

catch