encryption/cracking

i was wondering if anyone knew if there was a program out there that people could get ahold of to crack passwords. i don't mean by brute force, i mean a REAL cracker that goes through every single integer/char even possibly ascii chars(optional?) up to 24 chars to crack said password. im worried about starting websites etc etc and having someone crack my passwords, let alone my universal password i use for certain things. kind of new to encryption so i can give much more info on what im talking about. also does anyone know of a reliable site etc to get high level encryption source etc in case i start developing again (im behind in times;\ )

Isn't that essentialy a brute force cracker? I thought that was how they worked; by trying every possible combination of bits to find the correct one.

the original brute force cracker i remember was a dictionary cracker.

Quote:

---

let alone my universal password i use for certain things

---

You can stop THIS for a start ........
then you will automatically be more secure, because the 'turd' will have to force EVERY password ...............

You cannot remain safe behind static defences
so you have to start utilising good STRONG passwords / passphrases AND change them on a regular basis [30 / 60 / 90 day cycles]

the turds are a part of our online life nowadays, so why make it any easier for them than you absolutely HAVE to ?

A dictionary attack is not a brute-force attack. Brute-force attacks
by definition try every single possibility [exhaustive search] whereas
a dictionary attack narrows down the possiblities [in this case to the
words in the dictionary] - of course on that level of sophistication you
now have bruteforce dictionary attacks versus other dictionary attacks
that add another layer of elegance and efficiency.
A good password would be long and contain non-alphabetic characters
since a permutation attack would take forever. Like an encrypting key,
a passwords strength is based on two factors: length and symbol space.
The symbols space is those characters that can be used [i.e., all ASCII
characters] and the length is how many characters. The length actually
affects the strength more since the permutation count equals:
(symbol space)^(length)

Perhaps the greatest threat would be from "rainbow tables", which are essentially precomputed brute force password cracks. They greatly speed up the process.

However they require considerable resource to compute and massive storage space. I would go along with Dr MindHacker in that length is more important than complexity (provided that you are not using dictionary words). The most commonly available tables only go up to 14 characters or so, and take up 60Gb of disk space.

You must now ask yourself where the attack is likely to come from? if it is skiddies then a 24 character password should be strong enough, as they are unlikely to have the tables to crack that.

If it is the FEDs you are SOL ;) :p

Yea, Rainbow Tables are very similar to what I used in
my cipher cracker - I have a static set of files [up to 30 MB]
of generated patterns that reduces the computation time
in terms of pattern extraction and pattern searching...
However, unless you plan on running an ecommerce site,
I doubt you'll have any worries about it being hacked except
by script kiddes.

Hi,


The problem with what you are describing is the maths. Essentially, an ennumerator program (which can be quite easily written using C++ for example using a data structure to hold 24 x 255 sets of characters and use a recursive function to odometerize the selection) has to deal with every permutation of ASCII up to 24 slots which is mathematically equal to 255^24 i.e there are 255(1) x 255(2) x 255(3)...x255(24) choices. And this is before you move into unicode.


You then have to hash the results according to whatever method is being used to encrypt to produce your rainbow tables and then sort these for fast searching. Obviously there are different rainbow tables for MD5 etc. Finally, as someone else pointed out, you have to store the results.


As you can imagine, you need fairly powerful and/or multi-distributed computing power to undertake this kind of task. Which is why the rainbow project has taken a number of years to complete.


And the project runs into mud at this point because as fast as you can hash, new hashing techniques can be created and applied. eg. MD6 is coming out soon, if it hasn't already.


Of course there is a limit to how much computing power exists, both economically and in terms of the laws of physics. Moore's law determines that computing power grows exponentially each decade but thereby also sets a limit on the growth of computing power in any one decade. Boltzmann's limit determines that as the amount of power required to compute approaches the energy output of the sun, computing ability will rapidly tail off. Somewhere between these two is a theoric maximum of computing power. Materials science also affects the outcome. There is only so much silicon out there so new materials will be required soon (already happening).


As this point is approached, efficiency rather than brute force effectiveness will be required. This already happens of course because economic limits are approached sooner in each decade than physical ones. For example, elliptic curve and knapsack cryptography is more efficent than using RSA based methods, although public/private key systems are still less efficient than symmetrical key cryptography whatever method is used. What smart aleck said quantum just there now under their breath?


So you are welcome to writing such a program but see you next decade if you are planning on running it with any degree of seriousness.

The low hanging fruit of password cracking is social engineering. It is always faster and easier to breach protocol than technology.

Yurt Ennez

lol... my program [kernel at least] is specifically for monoalphabetic substitution ciphers - not
a "serious" cracker. I wrote begain it out of curiosity and combining my two
interestests: coding and crypto.
I do believe it is the most efficient algorithm for *its* purpose - not modern
cryptanalytic attacks.

Dr MindHacke

i'm sure there's a program that does what you want, basically all it is, is a series of nested loops depending on how many characters you want to use, just going up through the ascii table from your start char to your end char. i tossed together a small java example of what you seem to want.

Code:

---

public class cracker {
        public cracker() {
        }
        public static void main(String args[]) {
                final char start = 33;
                final char end = 127;
               
                for(char one = start; one < end; one++) {
                        for(char two = start; two < end; two++) {
                                for(char three = start; three < end; three++) {
                                        System.out.println(one + "" + two + "" + three);
                                }
                        }
                }
        }
}

---

ascii table for reference: http://www.lookuptables.com/

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?

:)

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.

Quote:

---

if there is an easy way to have a shorter password and have it secure for the general population

---

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.

Quote:

---

and keep it uncrackable

---

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

Quote:

---

where you can get all accounts and just dictionary crack it with JOHN and crack an account easy. thats what i want to avoid.

---

You should not fall for a dictionary attack.................don't use dictionary words :)

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

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