Wifi – WEP or WPA what should I use for the WiFi networks connection

You're understanding is basically correct.

First I'd like to mention that if you know the PSK, or have a copy of the certificate, it's basically game over. Cracking the the session key is cryptographically trivial if you've got that much information. If you don't have the PSK or cert you're left with brute force, as you mentioned.

Certificates are just as "easy" to brute force as PSKs, except that certificates are usually longer. A sufficiently long PSK works just as well however (for practical purposes). Also cracking RC4 is essentially as easy as cracking AES (for the purposes of NGOs)

You are however drastically underestimating the processing power required to crack a decently complex PSK. A PSK should be at least 12 characters long, using lower case, upper case, numbers, and symbols.

If you wanted to search all the possible keys up to 15 characters long (using all the aforementioned characters) you would have to search about 800 septillion keys. If your computer can calculate a billion keys per second it would take about 24 billion years to try them all.

Now after you you get half way through those keys, you're more likely than not that the next key you calculate will be the correct key; thus for the purposes of probable key cracking, you can chop that time in half.

Best get started now, you've going to be there a while. See also, Jeff's Post.

It'd be much easier to simply break into the person's house and beat the information out of them. (I absolutely do not condone, advocate, or suggest physically harming someone or threatening to do so)

WiFi under WEP everyone shares the same encryption key anyway, so broadcasts are no trouble. Under WPA/WPA2 a Group Transient Key (GTK) is given to each endpoint after the initial PTK (session key) is setup. Broadcasts are sent using this GTK so that all endpoints can decrypt it. In infrastructure mode endpoints aren't allowed to talk to each-other directly, they always go through the AP.

Edit:
If you need to generate a good WPA password, here's a random password generator.

If you pick a weak dictionary based passphrase, it can be cracked very quickly (<5 minutes) with an average modern laptop; it does however require the cracker to intercept the 4 way handshake when a WPA is setup.

Edit2:
NGO = Non-Governmental Organization (ie, typical corporations or mad scientists, people without the resources to build or use a top100 supercomputer to break keys, even if they wanted to).

Within WEP, WPA, and WPA2 there is no way to prevent legitimate users who can "hear" the two initial nonces from cracking the PTK. Another layer such as IPSec could be grafted over the top (in fact, IPSec could be used to replace WEP/WPA). WEP and WPA are not meant to insure individual privacy. They are meant to make your wireless network as secure as a wired network (which is not very secure in the first place). While they aren't perfect, they meet this goal most of the time.

What you're talking about is something we do in several Customer sites (including a school District who appears to be doing exactly what you want).

This isn't a click-for-click guide, but if you don't mind playing around with the tools a bit I think you'll find they're fairly self-explanatory.

The IAS server will need a certificate installed as a pre-requisite to performing EAP. If you don't mind using a self-signed certificate (which we're doing everywhere w/ no major issues) you can install Microsoft's Certificate Authority and the IAS machine will request a certificate automatically (assuming the machine hosting IAS is joined to a domain in the forest with the Certificate Authority). Reading about the best practices suggested by Microsoft re: the Certificate Authority is a good idea (particularly the parts about what can't change after you create your CA), but if all you're using your CA for is EAP you could probably get away with decommissioning it and starting fresh if you ever needed to.

Once you've got a certificate installed in the IAS machine, you need to configure your RADIUS server to accept requests from your wireless access points (RADIUS clients). The Microsoft RADIUS server (at least in W2K3) isn't very good about handling DNS lookup failures effectively, so, much as I hate to say it, I'd recommend using the IP addresses of the APs when creating the RADIUS client entries on the IAS server. The "shared secret" is the value that the RADIUS client (the AP) uses to authenticate to the RADIUS server (IAS). Be sure that you enter it identically on both the AP and the IAS server.

You'll need to create a remote access policy on the IAS machine after you've defined your APs as RADIUS clients. The built-in wizard can do a good job of creating a policy for you. Basically, you want a policy that matches "Wireless - IEEE 802.11 OR Wireless - Other" and, if so desired, a specific Windows group containing users who will be granted access (like, say "Domain Computers" or "Domain Users"). The wizard can guide you thorough this process.

Once you've gotten the policy created you can attempt to connect from a client manually. I'm only discussing configuring the Windows built-in Wireless Zero Configuration (ha!) service here. If your WLAN NIC has a third-party configuration manager and you can get away with removing it I would. Using the built-in Windows service makes the odds of getting the NIC to come up and authenticate properly during boot (assuming you allow "Domain Computers" access in your RADIUS policy) much greater. (I can tell you that I have a large number of wireless clients at my school district site that never plug into wired Ethernet but are able to process group policy, etc, with no problems.)

The procedure varies a bit between Windows XP and Windows Vista / 7, but basically we're talking about going to the list of wireless networks, adding the SSID of the new WPA-RADIUS protected network (remove the old one if you're re-using your existing SSID), and making sure some properties are set properly. The "Network Authentication" should be set to whatever combination of WPA/WPA2 and AES/TKIP you configured on your AP. (Personally, I'd use WPA2-AES if you can, but WPA-TKIP is the lowest common denominator and is supported by older clients.)

In the authentication properties for the new SSID, be sure that "Protected EAP (PEAP)" is selected as the EAP type. If the client isn't a member of your domain, go to the the "Properties" dialog for PEAP, uncheck "Validate server certificate", go to the "Configured" dialog for "Select authentication method" and uncheck the "Automatically use my Windows logon name and password (and domain if any)", and uncheck the "Authenticate as computer when computer information is available" under the "Authentication" properties of the new SSID. This will force Windows to prompt you for credentials on a non-domain-member computer.

Once you get a client "talking" I'd recommend deploying the SSID's settings using group policy so that you don't have to "touch" any clients. I love this functionality and have used it in many sites to great success. As long as the new domain-member client computer is allowed to apply group policy once on a wired network it will "just work" once it's put in range of the wireless network. Nirvana!

For non-Windows devices (iPods, Linux netbooks, Android phones, etc) you'll have to work thru the configuration of the connection yourself. It's not too bad, though. We've got a variety of devices authenticating to WLANs configured in this manner just fine.

Edit:

On non-domain-member computers you'll want to untick the items I describe in my above to prevent the client from validating the server certificate and trying to authenticate automatically. The user will have to manually supply their credentials.

In terms of automatically deploying the configuration profile to non-domain-member clients you can use the "netsh wlan" command on Windows Vista and Windows 7.

On Windows XP, deploying WLAN configuration without Group Policy is really similar to Vista, but requires installing software.