If you think passwords as weak as the ones below aren't in use anymore, then think again. Not long ago, I was running a packet sniffer while wired into a switch that was acting as a hub; basically, it was broadcasting all processed traffic to all its physical ethernet ports.) Not long after my local network interface entered promiscuous mode, I noticed an OS/400 login with the password "000000" (without the quotes.) I quickly emerge'd a TN3270 emulator from Gentoo portage and successfully accessed the offending account on the IBM AS/400 mainframe.
Furthermore, legacy big iron operating systems aren't the only boxen out there with ridiculously weak passwords. I once telnet'd to an HP-UX machine whose /usr/bin/login process graciously gifted me a shell prompt after trying username "oracle" and password "oracle". The moral of the story is, never rule out old school password guessing as an effective testing technique. There's a reason that all those worms/botnets/etc. are continuously attempting to authenticate with SSH daemons listening on the standard TCP port number 22. You've most likely seen the login failures being logged to /var/log/secure. It's because such crude techniques still do work--luckily most malware that attempts this isn't advanced enough to perform application layer fingerprinting (looking for SSH server version string banners, basically) against other TCP ports in case the system adminsitrator re-configured the daemon to listen elsewhere.
After installing Oracle Solaris 11.2 (x86) in Microsoft Hyper-V,
I found myself searching the web for login credentials. To my surprise, there
were only four characters separating me from the
SunOS command line; both the
login and pass were jack. Although the jack
account wasn't in /etc/sudoers, I was still able to execute
/bin/su - to attempt root logins. After a couple guesses,
I discovered the root pass: solaris. The take-away from
story is that newly imaged VM's need a
feature similar to WPS, an acronym
for
Wi-Fi Protected Setup™, which is essentially a feature that allows
not-so-savvy users to easily authenticate with highly complex pass-phrases by
using a hardware reset button, NFC,
or other hardware components of a wireless router's embedded system. Another
take-away is that default credentials are almost always lower-case.
No authentication component should ever allow a password that's identical to a username. At the beginning of the millenium some widely deployed user database implementations began to add an option that prevented credential simplicity of this sort; and more recently I've noticed that some of the larger well-known web sites will even disallow passwords that contain substrings or even permutations of the associated username. It's also typical those types of algorithms applied to previous passwords; so when a password expires, the user is forced to change to a new one that doesn't at all resemble the password(s) they used in the past. Of course, the problem with password history is that the old password data needs to be stored somewhere in order to be referred to when a new private code is being set on the account. There's no doubt that a hacker sometime/somewhere/somehow will obtain historical password information and use it to their advantage.
At any rate, there are way too many systems out there that still persist in
the behaior mentioned above. The most difficult pass-phrases to crack are those
with considerable length; note, there's a reason I called them "phrases".
Naturally it follows that "pass-sentences" are even stronger. This is assuming
the encryption system even honor the extra length. Those that recall the state
of UNIX password security before /etc/shadow was created may remember
the dreadful situation UNIX password security was in. When the passwd
command was executed getpass() would return any C-style string it
could malloc() in its entirety. The problem arose when the
crypt() library function would only encrypt the first 9 characters
of the entered password into ciphertext created by the notoriously weak (as well
as export-grade) DES algorithm. Some Unices even offered up silly solutions like
the crypt16() and bigcrypt() functions. This didn't
matter much since the hashes were stored in the world readable
/etc/passwd file anyway; so for example, any local user was able to
download /etc/passwd with ftp, rz, etc. and then run
john.exe against
it on their 80486 IBM-compatible PC with MS-DOS and Windows 3.1. Although those
days are over, programmers need to learn from their past mistakes. Clearly, the
the new status quo has at least some parts of computer security history
repeating themselves.
The inception of the pre-computed hash cracking technique (colloquially known as rainbow tables) certainly made its mark on this ongoing game of cat and mouse. Many password cracking suites support pre-computed hashes now, a few of the most popular being RainbowCrack and L0phtCrack. Essentially, all ciphertext representations of a certain password format (for instance: length 7, alphanumeric, and symbols) are generated into a special data structure stored in large files whose size is typically at least several gigabytes. They allow rapid lookup of the plaintext corresponding to a given ciphertext value--it's a textbook example of a classical algorithmic approach in computer science theory that trades time for space.
Sometimes hash cracking isn't an option. Attack tools such as
Brutus and
THC Hydra launch a
brute force search via network requests to discover valid credentials. To speed
up the process, they use multi-threading like so many other tools of the same ilk. Usually, the default degree of parallelism (i.e. the number of simultaneously
active threads) can be set to a higher value with a graphical range control,
command line argument, configuration file setting, etc. Some accounts can be
authenticated through more than one interface; a determined brute force attacker
may time each interface to decide which one to go after or even search through
multiple interfaces concurrently. If using proxy servers to evade detection,
their uplink speed and network routing distance from the target are factors to
consider when tweaking brute force attacks for optimal speed. When more complex
source location obfuscation is in use like connection stacking as in the case
of Tor onion routes, tweaking tor.conf and
tortunnel
are both ways that can make the brute force process go faster. Albeit rare,
there is authentication code out there that utilizes
exponential back-off to slow brute attacks, in which case testers will just have
to slow down. Check if back-off kicks in based on username, source IP address, etc. As a last ditch effort, pay attention to timing details and thus the
pattern(s) required to trigger idleness in the target login process. If it's open source back-off code that's being tested, then certainly take advantage of that fact. A good example is the login-backoff capability from OpenBSD's /etc/login.conf. To prevent the activation of any back-off, insert function calls in the brute force tool like:sleep(), usleep(), and nanosleep().
A common security feature that will quickly thwart a brute force attack is account lockout. The most obvious way to subvert lockout is to try a single password against a list of accounts instead of the other way around. Some systems base account lockout policy on a per-connection basis. Voice mail boxes are notorious for this. It's easy enough to get around: if it locks after 3 PIN number entries then simply hangup after the second unsuccessful attempt and call back.
Some authentication systems will simply drop the connection after so many failed attempts. Sometimes this is implemented in combination with account lockout and sometimes it isn't. If not, then the countermeasure is the same as the voice mail box example above.
The most cutting-edge hash cracking techniques nowadays are definitely related to the utilization of various forms of parallelism, sometimes in combination with each other. Now that it's common for PC motherboards to feature multiple CPU sockets as well as multi-core CPU's, there is now good support for OpenMP in John the Ripper. OpenMP is a standard for automatically multi-threading sections of code using C preprocessor directives (instead of making cumbersome function calls with a library like libpthreads.) In addition to multi-threading, GPU acceleration has already been integrated into some commercial password cracking suites; an open source example is oclHashcat-plus. which uses the OpenCL standard as well as NVIDIA CUDA API. In fact, it also has support for distributed style cracking in combination with hardware acceleration. New parallelization libraries and new abstractions of old concurrency concepts are always under development; OpenACC is an excellent example which is similar to OpenMP in that it's a set of directives for C, C++ and FORTRAN. OpenACC was developed by people who also developed OpenMP, thus there are stark syntactical similarities. OpenACC allows heterogenous computing environments that offer parallelism via both multi-CPU and multi-GPU to take advantage of both simultaneously, so code optimization can benefit from the best of both worlds.
However, some things never change. Still, the length, complexity and use of control characters (e.g. high-bit ASCII) exponentially decrease the likelyhood of a successful crack. This timeless axiom is now understood by a larger segment of the world population due to the advent of the Internet. What we call a password was known in early forms of English as a watchword. ROT13 (Caesar's cipher) is the senior of Ye Olde English by more than a millenium, but the concept of a secret sequence shared between individuals pre-dates language itself.
These are some of the most common passwords discovered in real-world large user database compromises. Sometimes they're a slight variation, such as a first capital letter, a period at the end, all caps, etc. As a result, many login brute forcing and hash cracking tools now exist that feature heuristics for attempting common permutations over the usual word lists and dictionary files out there.
As a side note, I've read that for some reason it's extremely common in the United States for users to simply add the number "1" after their usual secret character string to comply with password complexity restrictions. Hence, the steady increase in validation of passwords against severely mucked up formatting requirements.