February 21st, 2006 10:36 PM
I think he is looking for a marrying of the two... I haven't seen any tools out there, but it sounds like a good idea to me.
All the common passwords are already hashed out... you try your small set of tables first... proceed to other methods if that doesn't work.
Is that so hard to understand? Is that pointless? T_Stark is new to security, so he is thinking outside the box... because he doesn't know what the box is!
Then again, maybe T_Stark is confused...
February 22nd, 2006 10:05 AM
I think that you have a good point. I haven't seen such a tool either.
OK, I don't know Tony's precise requirements, so I cannot come up with a slick workaround (not that I would be able to anyway )
I would put together an application that called on a dictionary cracker, then a brute forcer. You might want to make it a bit more sophisticated and enter "rules" like "if the password is more than X characters, skip the dictionary bit because it cannot be a word, and go straight for brute force."
If the objective is to validate user passwords in accordance with your security policy's password rules then you need something to test the password before it is submitted. I would just create a table of banned passwords and compare the submission to those. This would be a dictionary plus common defaults for systems and applications. So the test would be something like:
1. Is the password between the minimum and maximum allowed characters?
2. Does it contain numbers and letters?
3. Does it contain upper and lower case?
4. Does it contain symbols?
5. Is it in the "prohibited table?"
6. Has it been used before in the last X passwords for this user?
and so on......................................that way you check the password and enforce reasonably secure ones, without irritating the user by letting them think they are being spied on.
I know that you will hear people say that long passwords are bad because people cannot remember them? Well my solution (so far) is to recommend "packing" the password:
1. Select your "core password" say it is "password" which is 8 characters. Then disguise it:
"pa$sW0Rd"...................might as well leave the inverted commas?..............now add some packing:
AbCdEfG"pa$sW0Rd"0987654321...................so that's it, all we need is a bit of wrapping?
And there you have an easily remembered 31 character password. When you change it, all you do is change the 8 character core.
Just a few thoughts
If you cannot do someone any good: don't do them any harm....
As long as you did this to one of these, the least of my little ones............you did it unto Me.
What profiteth a man if he gains the entire World at the expense of his immortal soul?
February 22nd, 2006 10:26 PM
You are correct, I guess my thing was that I have seen dozens of different rainbow tables generated so it may take dozens to do the job....so I figured that if I could hash the actual passwords that the time to finish and the number of tables would be minimal.
Originally posted here by SirDice
Read it again as you clearly misunderstood what rainbow tables are. You create tables for every password possible. So that includes anything and everything, any user can think of..
Please don't get me wrong, I completly understand what you're saying, it just seemed less time to hash the actual password list. I guess I should have taken a server and made my own tables, unfortunatly I don't think the hashin program that comes with LC5 uses more than one processor and I don't think the tables built by other apps will work with LC5.
Next on my list is suggesting we use Rainbowcrack, Cain or John the Ripper...
Thanks for the response!