January 3rd, 2006, 05:02 PM
Hi, Happy New Year all,
I think that karmine is asking more about possibility/probability that "how to". In other words a vulnerability assessment?
What we don't know is what degree of threat he is contemplating? A 24 character strong password should be enough to stop any skiddies or less than seriously determined assailants?
January 8th, 2006, 05:39 AM
nihil is somewhat right in his assumption to what im asking. i realize now that 8char/int passwords are somewhat simple, i havent worried about security and such (password-wise) since like 1995 (lol?). but i know that people are capable of cracking up to 24 especially with the computers we have now, and BROADBAND which is available everywhere now. back then we had 56k and if you were lucky you had ISDN at home etc etc, or if you were in college a T1 i presume. my linux crashed along with my power supply and im trying to figure out why the drive wont work right, i think i have a power supply problem with the new one i got even though its a tiny bit better. things are just driving me crazy. and its not even script kiddies im worried about, its people who actually know something and develope the tools for the skiddies. not all of them are good and release them just for malicious reasons. i know, i use to be one years ago. but there has to be an easier way to make a good password without memorizing 24 length passwords (and ive read that shadowed passwords are not even secure). thats why im asking crypto nerds if there is an easy way to have a shorter password and have it secure for the general population (not feds) and keep it uncrackable. most remember the old wwwboard exploit....where you can get all accounts and just dictionary crack it with JOHN and crack an account easy. thats what i want to avoid.
January 8th, 2006, 12:18 PM
Unfortunately not. At the end of the day password length is an important factor in its strength. Just look at the available cracking tools and see how long a password they will accept.
if there is an easy way to have a shorter password and have it secure for the general population
It is wise to assume that all passwords can be cracked given sufficient time and resource. This is where you need to do a bit of risk modelling. For example, if it will take three weeks to crack my password and I change it every two weeks, then I am "safe".
You should not fall for a dictionary attack.................don't use dictionary words
where you can get all accounts and just dictionary crack it with JOHN and crack an account easy. thats what i want to avoid.
Right now, I would consider the biggest threat to be brute force using rainbow tables (forget quantum stuff for the moment, it is beyond skiddies). The longer the password the bigger the tables and the more players you force out of the game.
If I were very seriously concerned, and couldn't trust myself to remember a password of suitable length and complexity, I would go down the hardware store and buy a bunch of dog tags. I would then take my Dremel with a diamond engraving bit and engrave the pass on the tag and wear it round my neck.................I would simply replace the tag each time I changed the password.
January 8th, 2006, 05:11 PM
If you're operating a website, the last thing you want to have happen is for a hacker to somehow manage stealing your database of passwords, etc. As long as a would-be-cracker doesn't have a *local* copy of the encrypted password to work with, and as long as your server remains in full control of the passwords, they will have to resort to social-engineering or otherwise capturing your password as it travels across the network.
Brute-forcing over a network (ie sending passwords to your server and being denied) will always be slow and controllable. A long time ago (and something I no longer have) I wrote a program (more of a hobbled-together script) that was supposed to brute-force passwords to my wireless router's admin interface. It used NetCat and sent password attempts through GET requests of the HTTP protocol and had a 'dumb' analysis to check the length of the page returned. I knew the length of a page that was a failed password attempt (and knew the lenght was different for success), and wrote off passwords that returned pages that said 'wrong password'. It worked at a painfully-slow 3-5 passwords-per-second, and would not have found the 6+ character long password in any reasonable time. The router keeping in control of authentication made the difference by slowing attempts down a lot.
If a cracker could rip through a local copy at 50,000+ combinations per-second or more, you're SOL. But at 5 combinations per-second, and in a networked environment that is traceable, they have to be more creative. Here you have to ensure hacks like XSS don't work on you, that your server has no vulnerabilities that leave you defenseless, and you don't have someone with ill-intentions working under your radar. And you need to look at the logs, and understand them.
Encryption buys time if security fails. But you really should worry about security first, unless the encryption side of the equation is like swiss-cheese (full of holes). I'd say what was found about MD5/hashes by Wang, etc., is more influential to larger files where collisions actually happen regularly. For passwords, rainbow tables and the like are more worrisome. Pick a password length out of reach of rainbow tables, and you should be at least better off if your database is stolen.
In short, ensure you don't lose your databases. As long as your server is in control, you're alright. Oh, and it does no good to have your hosting company backup your server and lose the tapes to the bad guys either. How much is that one password worth? Diversify. Cheers.