Sunday, October 30, 2011

Mobile phones and tablets will come with a browser, but depending on your mobile operating system there might be alternative mobile browsers you can use on the device.

There are a number of Web browsers available to choose from – each with its own distinctive look and features. With the growing popularity of smartphones and mobile devices, now there are also a number of mobile web browsers (also called a microbrowser) available to download.
Mobile browsers are optimized to display Web content on the smaller mobile device screens and will perform efficiently on these devices, which have far less computing power and memory capacity as a desktop or laptop computer running a standard Web browser.

List of 7 Mobile Web Browsers

1. BOLT Browser
Developed by Bitstream Inc., BOLT is a mobile browser that works on phones of all types. BOLT is built on a WebKit based cloud-computing architecture to enable advanced PC-Style internet functionality on mobile devices. The BOLT browser supports the HTML5 web standard and comes tightly integrated with social media applications like Facebook and Twitter.

3. Firefox Mobile
A The Mozilla Firefox Web browser brings the best of desktop browsing to mobile with the latest security and privacy features. Firefox mobile let's you browse favorite sites with minimal typing and access your browser history, bookmarks, passwords and open tabs from any device. Other features include tabs, personas, bookmarking and location-aware browsing.

4. MaxthonDeveloped by Maxthon, the Maxthon Browser lets users sync bookmarks/favorites to the cloud, switch between www and WAP versions of the Web. Other key features include speed dial, tabbed browsing, RSS reader, personalization and a download manager. Maxthon also offers a browser designed specifically for 10" tablets.

6. Skyfire Web Browser
Skyfire is a smart and social mobile browser designed for the social networking generation. Features of Skyfire include a customizable toolbar, Flash video support, Facebook QuickView, Fireplace Feed Reader, Facebook Like and easy sharing services.

Friday, October 28, 2011

Introducing 'SCM Breeze'

SCM Breeze is a set of shell scripts (for bash and zsh) that enhance your interaction with tools such as git. It integrates with your shell to give you numbered file shortcuts, a repository index with tab completion, and a community driven collection of useful SCM functions.
Disclaimer: git is currently the only supported SCM. I've kept the project's name open because it won't be difficult to port it for other SCMs.

File Shortcuts

SCM Breeze makes it really easy to work with changed files, and groups of changed files. Whenever you view your SCM status, each modified path is stored in a numbered environment variable. You can configure the variable prefix, which is 'e' by default.

git_status_shortcuts:

These numbers (or ranges of numbers) can be used with any SCM or system command.
For example, if ga was your alias for git add, instead of typing something like:

$ ga assets/git_breeze/config* assets/git_breeze/install.sh

You can type this instead:

$ ga $e2$e3$e11

But SCM Breeze aliases ga to the git_add_shorcuts function, which is smart enough to expand integers and ranges, so all you need to type is:

$ ga 2 3 11

And if you want to add all unstaged changes (files 1 to 10):

$ ga 1..10

(Note that ga will also remove deleted files, unlike the standard git add command. This behaviour can be turned off if you don't like it.)
You can also diff, reset or checkout a file by typing:

$ gd 3
$ grs 4
$ gco 5

You can use these shortcuts with system commands by passing your command through exec_git_expand_args (default alias is 'ge'):

Keyboard bindings (disabled by default)

My most common git commands are git status, git add and git commit, so I wanted these to be as streamlined as possible. One way of speeding up commonly used commands is by binding them to keyboard shortcuts.
Keyboard shortcuts are turned off by default, but here are the default key bindings if you enable them:

The commit shortcuts use the git_commit_prompt function, which gives a simple prompt like this:

(When using bash, this commit prompt gives you access to your bash history via the arrow keys.)

And if you really want to speed up your workflow, you can type this:

$ 2 3

This sends the HOME key, followed by git_add_and_commit:

Repository Index

The second feature is a repository index for all of your projects and submodules. This gives you super-fast switching between your project directories, with tab completion, and it can even tab-complete down to project subdirectories. This means that you can keep your projects organized in subfolders, but switch between them as easily as if they were all in one folder.
It's similar to autojump, but it doesn't need to 'learn' anything, and it can do SCM-specific stuff like:

Running a command for all of your repos (useful if you ever need to update a lot of remote URLs)

Auto-updating a repo when you switch to it and it hasn't been updated for at least 5 hours.

The default alias for git_index is 's', which could stand for 'source' or 'switch' :)
You will first need to configure your repository directory, and then build the index:

Anything else?

I mentioned there was a 'community driven collection of useful SCM functions'. Well... The 'community' hasn't quite started yet.
If you have any awesome SCM scripts lurking in your .bashrc or .zshrc, please feel free to send me a pull request. It would be cool to make this project into an oh-my-zsh for SCMs.

Installation

(The install script simply appends the following line to your .bashrc or .zshrc):[ -s "$HOME/.scm_breeze/scm_breeze.sh" ] && . "$HOME/.scm_breeze/scm_breeze.sh"

Configuration

SCM Breeze is configured via automatically installed ~/.*.scmbrc files. To change git configuration, edit ~/.git.scmbrc.Note: After changing any settings, you will need to run source ~/.bashrc (or source ~/.zshrc)
I know we grow attached to the aliases we use every day, so I've made them completely customizable. Just change any aliases in ~/.git.scmbrc. You can also change or remove any keyboard shortcuts.
Each feature is modular, so you are free to ignore the parts you don't want to use. Just comment out the relevant line in ~/.scm_breeze/scm_breeze.sh.

Updating

Run update_scm_breeze. This will update SCM Breeze from Github, and will create or patch your ~/.*.scmbrc files if any new settings are added.

Enjoy!

1. Introduction

What you're just reading is the beginning of series of articles dedicated to development on Linux systems. However, with minor modifications (if any), you will be able to use this knowledge you will get by reading our series on any other system that uses the same tools (OpenIndiana, BSD...). This first article will deal gradually with the intricacies of writing C code on Linux. You are expected to have basic programming knowledge, either on Linux/Unix systems or on other platforms. The idea is that you should know the basics of programming, like what a variable is or how to define a structure. Even though, you will get this information from this article, we won't insist very much on beginner-level concepts. A word of warning: we won't include everything there is to tell about C, because that would take lots of space and of course, we don't actually know everything about C. However, for more information and discussion about C please visit our new Linux Career forum.

1.1. Why C?

Some of you might argue that C is not the best beginner-level language ever. Agreed, but again, you're expected to have some basic programming knowledge, for one. Second, C and Unix, and Linux afterwards, are intimately tied together that it only seemed natural to start our development series with C. From the kernel, of which a substantial part of it is written in C, to lots of everyday user-land applications, C is used massively on your Linux system. For example, GTK is based on C, so if you're using Gnome or XFCE applications, you're using C-based applications. C is an old, well-established programming language, vital tool in many parts in the IT world, from embedded systems to mainframes. Therefore, it is only fair to assume that C skills will not only enrich your CV, but they will also help you to solve many issues on your Linux system, that is only if you take this seriously and practice a lot by reading and writing C code.

2. About C

2.1. History

C is more than 40 years old, with beginnings at Bell Labs with Brian Kernighan, Dennis Ritchie and Ken Thompson as the "usual suspects." Unix development and C's evolution are intimately linked, as we said, because Unix was initially written in assembly, but that had lots of shortcomings. Therefore, when moving to the PDP-11 as the main hardware platform, the developers started C as the as a core language for Unix. In 1978, Kernighan and Ritchie wrote, "The C Programming Language," a book that is today as it was 20 years ago: THE book on C programming. We heartily recommend you get it.

2.2. Classification

There are always people keen on classification of things and of course, programming is no different. Joking aside, since we're at the beginning, we thought you should know that C is a procedural structured programming language, with weak typing. What we just said, in English, is that C uses procedures (the usual name used by C programmers, and the one we'll use as well, is functions however), that it uses a structured approach (think blocks of code) and finally, it supports implicit type conversions. If you don't know what any of the above means, fear not, you'll find out!

2.3. Our approach

This article which is just the introductory part and we will regularly publish next parts where each chapter will deal with an important part of the language: variables, pointers, structs, etc. ( subscribe to RSS feed if you have not done so yet ) At the end of the theoretical part, we will show you a practical example, for which we chose yest, a tiny piece of software written by Kimball Hawkins (thanks, Kimball). We will compile it, then package it for Debian and Fedora systems. Debian developer Andree Leidenfrost will then show you how to submit our new package into Debian repository, making sure we respect all package requirements to be admitted to Debian distribution (thanks, Andree). We recommend you to try our examples on your system, take some time to examine the code and try to make modifications of your own.

3. The necessary tools

Before we begin, let us make sure we have all essential tools installed on your Linux system. You will need a compiler, namely gcc, the binutils package and a text editor or an IDE. Whether you choose text editor or some sort of IDE depends largely on your preferences, but more on that later. Depending on your Linux distribution and installation options you have used, you might already have the necessary tools installed. We put together a tiny script to help you see whether you have all mandatory development tools installed:

Why you need binutils binaries and gcc, you will see shortly. Now let's focus a bit on "editor vs IDE" question.
The only thing we will advise you in this respect is "use what you feel comfortable with and disregard what others tell you". This matter is very subjective and it depends on many variables. For example, if you develop (or used to develop) on other operating systems, you might be used to an IDE. You will find many good IDEs on Linux, including Eclipse, Geany, KDevelop or Anjuta. Try installing them to see what you find more suitable. On the other hand, if you want to go the simple editor way, there are lots of options here as well: vi(m), emacs, kate, nano, jed and so on. By searching the Internet you will find a lot of discussions regarding what the best editor is. We say install few of them and find out what suits you best. You are the only judge of this, and it will be a tool you will use frequently, so take your your time, use it, read about it and get familiar with it. Regardless of your choice, we will assume that you have made your choice in regards to the editing tool and you are familiar with its use.

4. The compilation process

In simple words, this process is what starts from the source code you wrote and if all goes well the result is an executable binary or a library. Needless to say, there's more to it but it is essential for you to understand the above sentence before you move on. You do not need to memorize all the concepts now as they will become clearer later. At this stage it's only important to get the general idea.
Let's say we have the source code written and now we want a compiler to process it and give us the executable binary. The workflow of this process is illustrated on your right.
Please note that this is applicable only to C, which is a compiled language, as opposed to interpreted languages (Perl, Python, Shell), and we will refer strictly to gcc and friends for the rest of our guide. As the figure on your right illustrates the preprocessor (cpp) takes your source code, looks for preprocessor instructions (in C, they start with a hash) and if everything looks right, the result is an output understandable by compiler. The compiler (gcc) does all the hard work, including code optimization for the underlying hardware (if you are interested in compiler theory or cross-compilation, there are lots of good books on the subject, but we assume a more beginner level here). The result is assembly code, intimately close to the machine, from which the binaries will be generated (as is the tool). In the end, depending on the options and the code, "ld" will link the executable to all necessary libraries and voila! the end result: your program. If you want to see all the resulting intermediate files, gcc flag -save-temps as will help you to do so. We recommend you read the gcc manual page, at least frugally, and make sure that your compiler us up to date. You will get used to usual gcc flags by reading our examples, but you are expected to know what they do, not just copy and paste commands you see on the screen.

5. Example C program

Every self-respecting programming tutorial starts with a "Hello, world" program. This program does nothing else but print "Hello, world!" on the screen, then exits. It's used to illustrate the very basic structure of a program and some essential concepts. So, without further ado, here it is.

Now, let us dissect the program line by line and see what each line represents. The first one is a preprocessor directive (see above) which asks for the stdio.h file, which provides the definition for the printf function. Header files are files that usually contain various definitions (functions, variables...) and make .c files less cluttered. All what a source file (.c) will need is an #include statement and possibly an argument to the linker. Everything that's defined in the included header file will be available in your source code.main() is a mandatory function in every C program. As the name states, the main activity will happen here, regardless of how many functions you have defined. int main() means that this function does not have any arguments (the empty parentheses) and that it returns an integer (the initial int). All these will be discussed later. The most important thing here is the printf function, which takes our text as an argument and displays it. "\n" means "newline" and it's the equivalent of using the Enter key (or ^M). It is called an escape sequence and all escape sequences in C begin with "\". For example, to better understand what an escape sequence is, imagine you're writing HTML code and you need to print a "<" character. HTML's syntax uses angle brackets to define HTML tags, so chances are your bracket will be interpreted as HTML code instead of being displayed. So, what to do? We escape it with "<" and it will appear properly. Just the same, if you want to insert a newline character, you can't type it directly, as the compiler could care less if you write your program on a single line or not and therefore you you need to escape your new line character with "\n".return 0 tells the compiler that everything is ok and the execution of main() function ends there. That is because 0 is the code for successful execution, while values greater than 0 (integers) is an indication that something went wrong. The curly braces that begin and end the main function delimit its' execution block, that is, what happens in main(), stays in main(). You may have noticed the semicolons at the end of the statements: they are mandatory as a sign that the current statement ended there, but they are not to be used in preprocessor directives as #include.

6. Compilation

Compilation will be discussed in more details in upcoming parts of this guide. But for the completeness here is a simple command line example on how to compile and execute our first "Hello World" C program:

$ gcc -o hello hello.c
$ ./hello
Hello, world!

7. Conclusion

We hope we didn't cram too much information in your brain and that you will enjoy staying with us on this programming tutorial. Part 2 will be dealing with a comparison between C and other programming languages in order to help those who already have some experience in development. So make sure you are subscribed to our RSS feed so you'll know when part two arrives. Here's what you should expect:

We reserve the right to alter the list at any time necessary. Seriously, although this is a rough overview of what's to come, we might change our mind regarding titles or subtopics, but the general idea will be as above.

Thursday, October 27, 2011

Is your network safe? Almost all of us prefer the convenience of Wi-Fi over the hassle of a wired connection. But what does that mean for security? Our tests tell the whole story. We go from password cracking on the desktop to hacking in the cloud.

We hear about security breaches with such increasing frequency that it's easy to assume the security world is losing its battle to protect our privacy. The idea that our information is safe is what enables so many online products and services; without it, life online would be so very different than it is today. And yet, there are plenty of examples where someone (or a group of someones) circumvents the security that even large companies put in place, compromising our identities and shaking our confidence to the core.

Understandably, then, we're interested in security, and how our behaviors and hardware can help improve it. It's not just the headache of replacing a credit card or choosing a new password when a breach happens that irks us. Rather, it's that feeling of violation when you log into your banking account and discover that someone spent funds out of it all day.

In Harden Up: Can We Break Your Password With Our GPUs?, we took a look at archive security and identified the potential weaknesses of encrypted data on your hard drive. Although the data was useful (and indeed served to scare plenty of people who were previously using insufficient protection on files they really thought were secure), that story was admittedly limited in scope. Most of us don't encrypt the data that we hold dear.

At the same time, most of us are vulnerable in other ways. For example, we don't run on LAN-only networks. We're generally connected to the Internet, and for many enthusiasts, that connectivity is extended wirelessly through our homes and businesses. They say a chain is only as strong as its weakest link. In many cases, that weak link is the password protecting your wireless network.

There is plenty of information online about wireless security. Sorting through it all can be overwhelming. The purpose of this piece is to provide clarification, and then apply our lab's collection of hardware to the task of testing wireless security's strength. We start by breaking WEP and end with distributed WPA cracking in the cloud. By the end, you'll have a much better idea of how secure your Wi-Fi network really is.

The majority of tests in this article were performed in the field, facilitating an exploration of network security under real-world conditions. There were a few situations where the signal strength of our target network prevented us from proceeding further in our experiments, though. In those rare cases, we used our Cisco Linksys E4200, which we set up to use 802.11g at 2.4 GHz.

Network Security: The First Line Of Defense

There's no such thing as guaranteed security for folks connected to the Internet. However, by adding additional layers of protection, it's possible to make a system increasingly difficult to compromise. Banks have multiple safeguards to prevent physical robberies, and well-built networks employ the same thinking to keep digital assets safe. You don't usually see the same thoroughness in home networks, though, because it costs a lot and requires a particular expertise in order to stay one step ahead of of the folks who'd like access to everything behind your firewall.

Instead of a tiered approach to security, most of us are only protected by our routers. That's what separates the local network from the Internet. It prevents strangers from using an IP address to access your system directly. And the router represents the first security layer in your network.

But it isn't just your first line of defense; it's also the most important. Why? Most people believe that you can enhance data security by installing a software firewall and a data encryption scheme like TruCrypt. However, most of us also make at least some of our data available to other users on our networks as a matter of convenience and easy accessibility. Perhaps we do this without even thinking that it could be seen by someone else. Regardless, when we do this, the integrity of our wireless network, protected by certain authentication technologies, is all that keeps our precious information safe from anyone in range and able to circumvent our safeguards. Adding additional security measures to keep Internet-based traffic out doesn't change that fact.

So, sure, streaming a high-def movie from your NAS to an HTPC in the living room might be easier as a result of wireless access. But anyone able to breach those invisible walls can do the same thing. And that doesn't even take into account the damage they can do on the Internet from an address that'd appear to be coming from your own little network.

In the early days of home networking, you could rely on the physicality of wired networking to restrict access. Now, with wireless technology, you have to worry about attacks coming from the Internet (hopefully being stymied by your firewall) and breaches closer to home that might allow an unsavory character right onto your network alongside other trusted devices. There is where stronger wireless security comes into play. That's the easiest way to protect your network from intrusion.

Now, we're assuming that most Tom's Hardware readers aren't setting up their access points and leaving them wide open to the pillaging of neighbors. You're using some sort of security protocol to at least discourage casual Web browsers looking to bum a ride on your bandwidth or amateur script kiddies testing their mettle.

WEP Is Dead, Haven't You Heard?

Wired Equivalent Privacy (WEP) was the first security algorithm used by wireless networks to restrict access. It was originally introduced in 1999 as part of the 802.11 standard. However, it has long been considered to be a "broken" algorithm, and was effectively replaced by Wi-Fi Protected Access (WPA).

If you're still using WEP on an older wireless router, try not to feel too safe. The Wi-Fi Alliance abandoned WEP in 2003 because it's very easy to crack. With $20 and some basic technical know-how, a neighbor can procure your WEP password in about 10 minutes using publicly-available tools. It really is time to upgrade to at least WPA.

The process of breaking a WEP password can vary, but we've seen it done enough times that there's little reason to detail this bit of deviousness here on Tom's Hardware. Think of us like AMC's Breaking Bad. We're not here to show you how to cook meth. But our story hinges on the process. An enthusiast using WEP should know how easy it is to circumvent, and we did it so that you don't have to learn the hard way. To give you an idea of what's involved, we used Cain & Abel, Aircracking-ng, and an AirPcap Nx adapter to find a nearby network's WEP key in about five minutes. The length of the key doesn't affect recovery time, either.

The fundamental problem is that it's incredibly easy to eavesdrop on a WEP network and sniff out the information needed to crack the RC4 cipher backing the protocol. Even if there aren't enough packets traveling between the router and clients inside the network, it's possible to send packets in such a way to simulate reply packets, which then can be used to find the key. It's even possible to forcibly boot users off a router in order to generate packets with authentication information. Scary stuff; avoid it at all costs if security truly matters to you.

This is one of the most critical differentiators separating WEP and WPA. WEP doesn't obscure your password in an effective way. That is a huge security risk because hackers can directly extract it from packets sent during authentication. This makes it easy for those same folks to sit in parking lot or lounge around in a mall and break into networks. Once enough packets are gathered, extracting the key and connecting to the network is easy. WPA is different because the password is hidden in a code (in other words, it's hashed), forcing hackers to adopt a different tactic: brute-force cracking.

In one of our last security-oriented pieces, we noticed some confusion in the comments section where readers were asking for more clarification on concepts like rainbow tables, hashes, salting, and transformations.

There are two major parts to converting a password value to a decryption key. The first is called salting. It's possible you've heard this term used once or twice. This is a method in cryptography that prevents two systems from using the same key, even though they may share the same password. Without salting, a pair of machines using the same password, even coincidentally, end up with the same key. This is a vulnerability for rainbow tables, which are huge spreadsheets that allow you to look up the original password (provided you know the key). Salting largely nullifies the use of rainbow tables, because every password uses a random value to generate a different key. It also effectively renders password derivation a one-way function, because you can't backwards-generate passwords from keys. For example, SSIDs are used to salt WPA passwords. So, even if your neighbor uses the same password, he's going to have a different key if his router has a different name.

PBKDF2 takes things one step further by using a key derivation function (KDF). The idea itself is pretty simple, but it's a little math-heavy. There are two steps:

Generate data1 & data2 from password and salt.

Calculate key using transformation invocations using a loop, which looks like:

Basically, you input the password and salt (the random bits) in order to generate the first data parameter. This represents the key in it's non-final form. From there, the key is continuously hashed in a cycle, where the next calculation relies on the previous one in order to continue. For every interval, the value of the key changes. Repeat this a couple thousand times and you have the final decryption key. And because you can't go backwards, brute-force cracking requires you to "recreate" the key on every password attempt.

This process accounts for 99% of the computational overhead required in brute-force cracking, so throwing copious compute muscle at that wall is really the only way to chisel it down. Hash cracking lets you to try multiple passwords at a time because the process doesn't employ a key derivation function or salt, making it magnitudes faster. As a practical matter, the impressive speeds you see from hash cracking shouldn't scare you. This form of brute-force hacking is limited in scope, since just about everything secure utilizes salting and a key derivation function.

To give you a sense of scale, WinZip uses 2002 SHA-1 transformation invocations to generate a key. This value is constant for any password length, up to 64 characters. That's why a 10-character password is just as easy to defeat with AES-256 as it is with AES-128. WPA, on the other hand, uses 16 388 transformations to convert a master key (MK) into what's known as a Pairwise Master Key (PMK). That makes brute-force cracking in WPA 8x slower than it does with WinZip/AES.

WPA relies on a Pre-Shared Key (PSK) scheme. You may enter in a master key (the value that you see in the password field on the router), but you can only "sniff out" the Pairwise Transient Key (PTK) during what is known as a "four-way handshake."

Authentication relies on deriving the PTK from a Pairwise Master Key, which is in turn derived from a master key. It takes about five or six more transformations to go from the PMK to PTK, but WPA cracking speeds are often presented in PMK units, the most computationally-intensive portion of the brute-force attack.

WPA Cracking: It Starts With Sniffing

There are three steps to penetrating a WPA-protected network.

Sniffing: Intercepting packets in order to get the data necessary to perform an attack.

Parsing: Inspect the harvested packets to see if there's a valid handshake. This is the critical step. The information you're trying to capture consumes less than 1 MB, but it's important that it includes packets that contain PTK authentication information. This means that someone needs to log on to the network while you're sniffing.

Attacking: Employ brute-force password cracking.

The entire process of sniffing, parsing, and attacking tends to be modular, but the exact procedure is a little different, depending on the operating system. At the moment, Linux is the preferred route for many networking ninjas, but there are tools in Windows that streamline the process too.

No matter what software route you take, making this happen isn't as easy as typing in the right commands. Getting past the sniffing step is perhaps the most difficult part because it requires a particular type of wireless card. Specifically, you need one that has drivers able to provide access to low-level 802.11 protocol information. The majority of wireless cards don't cut it because they use a driver that filters the RAW 802.11 packets and hides them from the upper layers of the operating system.

But the right equipment doesn't cost an arm and a leg. Many compatible wireless cards cost less than $50. Ultimately, skill is what separates the beginners from hackers. Without giving you the blow-by-blow, these screenshots give you an idea of how easy it can get. In all, I spent about 10 minutes getting the information needed to set up the password attack, which is step three.

There is one caveat worth mentioning. Capturing the authentication information (four-way handshake) requires you to monitor for the packets transmitted when a client attempts to connect with an access point (AP). The act of connecting is what generates the packets that hackers are interested in exploiting. If there are no wireless clients connected, a hacker must wait for someone to establish a connection. Checking your morning email just got a little more real, didn't it?

If a client is already connected, it is still possible to capture the requisite information by forcing a reconnection attempt. How, you ask? By targeting a specific user and booting them off the network with one simple command-line instruction.

After we're done sniffing, we have to use a cracker to brute-force every master key against the PTK. Between Linux and Windows, there are fewer than 10 programs that actually perform the brute-force attack. The majority of them, such as Aircrack-ng and coWPAtty, rely on a dictionary attack. That means you need to provide a discrete database of words to check against. In the end, there are really only two programs that perform truly random brute-force attacks: Pyrit (combined with John the Ripper in Linux) andElcomsoft's Wireless Security Auditor (Windows).

It should come as no surprise that coordinating an attack in Linux is more involved than Windows. Aircrack-ng is used to sniff and parse. Then you switch to Pyrit in pass-through mode via coWPAtty (PMK-PTK conversion) for the brute-force attack. In comparison, Elcomsoft offers a much more fluid experience with its Wireless Security Auditor. Admittedly, that app is so easy to use, a caveman could do it. It sniffs (provided you have an AirPcap adapter), parses, and attacks a WPA-protected network in no more than 10 mouse clicks.

Although cracking is slightly more complicated to pull off in Linux, it's also less expensive. The fully-automated version of WSA runs $1199, but it lets you use up to 32 CPU cores and eight GPUs, it adds sniffer support, and it features support for dedicated cracking hardware like Tableau's TACC1441 (the serious FPGA-based stuff). The standard version is more limited. It's restricted to two CPU cores and one GPU and only costs $399. You do need a third-party app for the sniffing step, though.

OS

Linux

Windows

Windows (fully automated)

Sniffing

Aircrack-ng

Aircrack-ng

Wireless Security Auditor Pro Edition

Parsing

Aircrack-ng

Wireless Security Auditor Std. Edition

Wireless Security Auditor Pro Edition

Cracking

Pyrit via CoWAPtty

Wireless Security Auditor Std. Edition

Wireless Security Auditor Pro Edition

Software Cost

Free

$399

$1199

Brute-Force Cracking

If you want more information on how brute-force attacks work, we suggest that you read page four ofHarden Up: Can We Break Your Password With Our GPUs?. In a nutshell, brute-force attacks involve "guessing and checking" on a much larger and faster scale in an attempt to defeat passwords.

Brute-force attacks are only effective when they can check passwords at a high speed, as the number of potential passwords grows exponentially with a larger character set and longer password length (possible passwords =n[password length] , where n is the number of possible characters).

Most of the time, hackers don't know the length of your password, though. That's why they have to perform an exhaustive search of all possible combinations, starting from a list of single-character options.

CPU-Based Cracking: Like Watching Paint Dry

If the guy trying to get into your network is only armed with a conventional desktop processor, don't fret about the security of your WPA-protected network. Those 16 388 SHA1 transformation invocations really bog down brute-force attacks. While we were able to crack WinZip archives at 20 million passwords per second in our previous piece, we're only able to manage about 5000 against WPA using an Intel Core i5-2500K.

Total Search Time Search, Assuming 5000 WPA Passwords/Second

Passwords Between 1 and 4 Characters

Passwords Between 1 and 6 Characters

Passwords Between 1 and 8 Characters

Passwords Between 1 and 12 Characters

Numbers

Instant

4 minutes

6.5 hours

7.5 years

Lower-case

2 minutes

18 hours

1.5 years

662 263 years

Alphanumeric (including Upper-case)

52 minutes

140 days

1481 years

Next Big Bang

All (Printable) ASCII characters

5 hours

5 years

48 644.66 years

Next Big Bang

How's this for a sense of futility? There's really no way to brute-force an alphanumeric password longer than six characters using our Core i5 processor. If you're using the entire (printable) ASCII set, a WPA password longer than five characters is reasonably safe.

In the pages to come, we're going to present two numbers from Linux: the result from Pyrit's benchmark command and the figure reported by CoWPAtty using the Pyrit pass-through function. The Pyrit benchmark command is commonly used to highlight GPU performance, but it doesn't figure in the last couple of transformations needed to go from PMK to PTK. There is some overhead there because the PMK-PTK conversion occurs outside of Pyrit.

CoWPAtty and Elcomsoft's Wireless Security Auditor test the speed at which master keys are checked against the PTK information contained within captured packets. As such, those are the real-world numbers you would see in mounting a brute-force attack against a WPA-protected network.

GPU-Based Cracking: AMD Vs. Nvidia In Brute-Force Attack Performance

So, what happens when we put GPUs to work on the same task?

Intel Core i5-2500K

Nvidia GeForce GTX 460 1 GB

Cores

4 (no HT)

336

Clock Speed

3.3 GHz (base)

1350 MHz

Wireless Security Auditor

4752 passwords/s

18 105 passwords/s

Pyrit Benchmark

3949.13 PMKs/s

17 771.6 PMKs/s

Pyrit w/CoWPAtty

3306.85 passwords/s

19 077.15 passwords/s

Time To Crack Passwords Between 1 and 6 Characters (Alphanumeric)

140 days, 14 hours (WSA)

35 days (Pyrit)

Time To Crack Passwords Between 1 and 8 Characters (Alphanumeric)

1480 years, 311 days (WSA)

368 years, 319 days (Pyrit)

Compared to CPUs, the performance difference is incredible. A single GeForce GTX 460 manages roughly 4x the performance of a Core i5-2500K.

That Forensic Computers, Inc. Tableau TACC1441 mentioned earlier should have been an indication that GP-GPU computation would outperform desktop CPUs. After all, the FPGA-based accelerator consists of a massively parallel array of processors that operate in concert to attack multiple types of encryption schemes. This is a problem better-addressed by many cores operating concurrently.

Now, we know how a mid-range graphics card fares against a fairly mid-range CPU. What happens when we start ratcheting up the complexity of our graphics configuration?

It's striking to see how much faster AMD's cards are than Nvidia's. The Radeon HD 6990 sports a greater number of ALUs than the GeForce GTX 590, though. Moreover, it has been shown that there are certain operations AMD's ALUs are able to execute more efficiently.

For some reason, we did have to enable CrossFire to get the second Radeon HD 6990 to appear under WSA (generally, multi-GPU configurations don't need to be running in CrossFire or SLI to operate cooperatively). Both technologies can slow down a brute-force attack because they're designed to help balance GPU workloads. In this case, CrossFire actually works to the detriment of performance. With AMD's multi-card feature disabled, we achieve the expected linear performance scaling in Linux.

Brute-force password cracking in a reasonable amount of time is wholly dependent on the number of cores you wield and the speed at which they operate.

Time To Find Crack...

Passwords Between 1 and 6 Characters (Alphanumeric)

Passwords Between 1 and 8 Characters (Alphanumeric)

Nvidia GeForce GTX 460 1 GB

35 days (Pyrit w/ CoWPAtty)

368.9 years (Pyrit w/ CoWPAtty)

Nvidia GeForce GTX 590

11.6 days (Pyrit w/ CoWPAtty)

122.5 years (Pyrit w/ CoWPAtty)

2 x Nvidia GeForce GTX 590

6.5 days (WSA)

68.66 years (WSA)

AMD Radeon HD 6850

20.4 days (WSA)

214.75 years (WSA)

AMD Radeon HD 6990

5.88 days (WSA)

62.24 years (WSA)

2 x AMD Radeon HD 6990

3.08 days (Pyrit w/ CoWPAtty)

32.97 years (Pyrit w/ CoWPAtty)

Though not common, a pair of GeForce GTX 590s or Radeon HD 6990s in a high-end gaming rig isn't unheard of. Clearly, passwords consisting of seven characters or more are fairly safe. But bear in mind also that we're also looking at worst-case scenarios. The numbers cited above are indicative of searching for a password between 00 and 99, and the right answer ends up being 99. The correct answer is just as likely to be 00, slashing the compute time.

Nvidia's Tesla And Amazon's EC2: Hacking In The Cloud

Cracking passwords works best on a scale exceeding what an enthusiast would have at home. That's why we took Pyrit and put it to work on several Tesla-based GPU cluster instances in Amazon's EC2 cloud.

This machine is strictly a Linux affair, which is why we're restricted to Pyrit. The best part, though, is that it's completely scalable. You can add client nodes to your master server in order to distribute the workload. How fast can it go? Well, on the "master" server, we were able to hit between 45 000 to 50 000 PMKs/s.

Are you scratching your head at this point? Only 50 000 PMK/s with two Tesla M2050s?! Although the hardware might seem to be under-performing, the results are on the order of a single GeForce GTX 590, which of course is armed with two GF110 GPUs. Why is that?

Nvidia's Teslas were designed for complex scientific calculations (like CFDs), which is why they so prominently feature fast double-precision floating-point math that the desktop GeForce cards cannot match. Tesla boards also boast 3 and 6 GB of memory with ECC support. However, the process we're testing doesn't tax any of those differentiated capabilities. And to make matters worse, Nvidia down-clocks the Tesla boards to ensure the 24/7 availability needed in an enterprise-class HPC environment.

But the real reason to try cracking WPA in the cloud is scaling potential. For every node we add, the process speeds up by 18 000 to 20 000 PMKs/s. That's probably not what most folks have in mind when they talk about the cloud's redeeming qualities, but it does demonstrate the effectiveness of distributing workloads across more machines that what any one person could procure on their own.

Each GPU cluster instance is armed with a 10 Gb Ethernet link, restricting bidirectional traffic between the master and nodes to 1.25 GB/s. This is what bottlenecks the cracking speed. Remember that a single ASCII character consumes one byte. So, as you start cracking longer passwords, the master server has to send more data to the clients. Worse still, the clients have to send the processed PMK/PTK back to the master server. As the network grows, the number of passwords each additional node processes goes down, resulting in diminishing returns.

Harnessing multiple networked computers to crack passwords isn't a new concept. But ultimately, it would have to be done differently to be more of a threat. Otherwise, desktop-class hardware is going to be faster than most cloud-based alternatives. For example, about a month ago, Passware, Inc. used eight Amazon Cluster GPU Instances to crack MS Office passwords at a speed of 30 000 passwords per second. We can do the same thing with a single Radeon HD 5970 using Accent's Office Password Recovery.

Securing Your WPA-Protected Network

Rest easy. From a practical standpoint, WPA is fairly safe. There are far too many salted key-derived hashes to process. The Wi-Fi Alliance got that portion of the protocol right. Even with a pair of Radeon HD 6990s, we're limited to about 200 000 passwords per second, and that means any alphanumeric password longer than seven characters is almost impossible to crack in under a year. That's a long time to wait for free Internet access from the guy next door (you'd be better off using social engineering to get the password from him; try a 12-pack of Newcastles). After adding a few special keystrokes, brute-force attacks look completely infeasible on passwords longer than six characters. Though, the point is kind of moot considering WPA/WPA2 requires a password longer than eight characters.

Unfortunately, most of us use passwords that include words. As such, those passwords are vulnerable to dictionary-based attacks. The number of words in conversational English is in the tens of thousands. A single GeForce GTX 590 can manage at least 50 000 passwords per second against a WPA-protected network. Even if you add a few variations, you really only need to spend a day or two crunching passwords to break the proverbial lock. Why? Because an entire word is functionally the same as a single letter, like "a." So searching for "thematrix" is treated the same as "12" in a brute-force attack.

Ideally, you should avoid the following if you are trying to make your network more secure:

Avoid words from the dictionary. The Oxford English dictionary contains fewer than 300 000 entries if you count words currently in use, obsolete words, and derivative words. That's nothing for a GeForce GTX 590 or Radeon HD 6990.

Avoid words with numbers appended at the end. Adding 1 to the end of password doesn't make it a more secure. We can still crunch the entire English dictionary and numbers in half a day with a pair of Radeon HD 6990s.

Avoid double words or simple letter substitution. PasswordPassword only doubles the number of words that we have to search. That's still fairly easy, considering how fast we can scan words. Also, p@55w0rd isn't a much more secure password. Password crackers know all the usual shortcuts, so don't take that route.

Avoid common sequences from your keyboard. Adding QWERTY to the dictionary of tested passwords isn’t hard work. That's another shortcut to avoid.

Avoid common numerical sequences. 314159 may be easy to remember. It's Pi, after all. But it's also something that's easy to test for.

Avoid anything personally related, such as your license plate, social security number, past telephone number, birthday, and so on. We live in a world where a lot of information is public domain. If you have a Facebook or Twitter account, the amount of information available keeps growing.

To the average hacker, WPA holds up remarkably well. Even if you're using a short, random password, the cracking speed we see from GPUs is simply too slow as a result of the high computational requirements for the key derivation function.

The real threat is distributed computing. Buying four Radeon HD 6990s help you reach close to half a million passwords per second. But the cards alone cost nearly $3000. If we went to the trouble of tweaking the Pyrit code, it would be possible to achieve the same performance for $8 by renting 10 EC2 Cluster GPU Instances. If you're unable to scale your code for automation, you can still achieve that level of performance by manually managing the workload across multiple servers.

The current distributed offerings might not offer impressive performance, but their speed isn't what worries us. It's their low price tag. Moxie Marlinspike, a hacker, runs a service called WPACracker, which can be used to crack the four-way handshake capture of WPA-PSK using 400 CPU clusters on Amazon's EC2 cloud. This scaling allows you to crunch through a 135 million word dictionary specifically created for WPA passwords in under 20 minutes. Even though that's ~112 500 passwords per second (equivalent to a single GeForce GTX 590), you only have to pay $17.

Total Search Time Assuming 1 Million WPA Passwords/Second
(Cost using EC2 Reserved Rate)

Passwords Between 1 and 4 Characters

Passwords Between 1 and 6 Characters

Passwords Between 1 and 8 Characters

Passwords Between 1 and 12 Characters

Numbers

Instant
Estimated Cost: $0.74

Instant
Estimated Cost: $0.74

2 minutes
Estimated Cost: $0.74

12.75 days
Estimated Cost: $226

Lower-case

Instant
Estimated Cost: $0.74

5 minutes
Estimated Cost: $0.74

2.5 days
Estimated Cost: $44.40

3147 years

Alphanumeric (including Upper-case)

Instant
Estimated Cost: $0.74

16 hours
Estimated Cost: $11.84

7 years

103 981 388 years

All (Printable) ASCII characters

2 minutes
Estimated Cost: $0.74

9 days
Estimated Cost: $159.84

231 years

Next Big Bang

Thomas Roth, a security expert who helped highlight the flaws of the Sony PlayStation Network, seems to be the only person that has publicly demonstrated a properly-scaled GPU distributed cracking network. His setup linearly scales the speed of individual EC2 Cluster GPU Instances by balancing the workload and reducing bottlenecks. So, even though we need about 10 Radeon HD 6990s split among three desktop systems to reach 1 million WPA passwords per second, we can do the same by spending $60 to rent 20 Cluster GPU Instances (the limit was recently increased to 64 servers). The only hurdle is optimizing code in Amazon's cloud. And no, we aren't going to share our code.

ZoomComputational clouds like Amazon's EC2 were originally intended to help developers and scientists solve complex mathematical problems without a heavy investment in building a server farm. I doubt that Amazon had hacking in mind, but the cat's out of the bag. The fact is that it can and will be done. If someone wants onto your network badly enough, your strong password might be the only thing stopping them.

And that's ultimately why you need to change your password strategy. The fact that that most of us use alphanumeric passwords to lock our Wi-Fi networks only serves to weaken them. How many of us know friends or family who never changed their default router passwords, either? We know that AT&T's U-verse routers (identified with SSIDs like 2Wirexxx, where x is a number) come with default passwords limited to numbers and are only 10 characters in length. Using a pair of Radeon HD 6990s, you can mow through every possibility in under 14 hours.

Besides using a unique SSID, a WPA password should follow the following rules:

For those of you in IT, you're better off investing in an authentication server, which adds another layer of wireless security since the master key is hidden from the user and generated dynamically. This means that the PMK is a fresh symmetric key particular to the session between the client and AP. It infinitesimally increases the complexity of a brute-force attack. In fact, as an IT professional, you should worry more about someone bribing an employee or stealing an unencrypted laptop.

Whenever someone talks about security, it's easy to go overboard. We get so caught up in locking down our information that we forget to ask ourselves if we have anything worth stealing.

To some degree, everyone has information they'd prefer stayed private, which is why we think everyoneshould be putting some effort into keeping intruders out. And the fact of the matter is that most troublemakers will see your locked access point and simply move on. Users in the Netstumbler forums estimate that 10-20% of networks still use WEP encryption. If someone really wants to hijack a network, they'll likely look for a WEP-protected target first. Whether someone is willing to spend hours, days, or even years banging on your WPA-secured fortress will depend on the state secrets hiding on the other side.

The fact of the matter is that most of us aren't high-profile enough to attack, so long as the right protocol is in place. It's often said that a pump-action shotgun is the best tool for home defense, not because it's any scarier than a handgun or rifle, but because the sound of a shell cycling is enough to make any intruder turn and flee. Well, consider WPA your pump-action.

Of course, not everyone agrees that security is necessary. In fact, many people purposely run open Wi-Fi networks. According to a post at TorrentFreak, the legality of holding a network owner responsible for the actions of users remains in doubt. One defendant writes, "Not all unsecured networks are due to a lack of technical knowledge. Some of us leave them open to friends and others out of a sense of community." That's super-generous and all, but if you're using one of those networks, just be aware that you're already rubbing shoulders with the bad guys.