Is WPA enterprise more secure than WPA2 enterprise?

All earlier answers are missing a very important step and its implication and are misunderstanding EAP.

WPA2-PSK (aka WPA2 Personal) basically does the same thing as WPA2-Enterprise from the clients perspective: The client associates to the access point, authenticates to the access point using the pre-shared key and access point creates a 256bit PMK (pairwise master key) from the SSID and the pre-shared key (PSK). This PMK is then used to encrypt data traffic using CCMP/AES or TKIP.

The important thing to note here is that all clients will always encrypt their data with the same PMK, all the time. So it's easy to gather a lot of data encrypted with the same PMK. Should someone break the PMK, they could decrypt all data encrypted with that key, past/recorded and future/real time.

WPA2 Enterprise is only a little bit different behind the scenes, but the security implications are severe: The client associates to the access point, authenticates to the access point, who passes this on to a backend RADIUS server (using EAP, but that's not important here, so more on that at the end). When the RADIUS server has authenticated the client, it gives the access point an OK, plus a RANDOM 256bit pairwise master key (PMK) to encrypt data traffic for the current session only.

Well, that's quite a difference. Instead of each client using the same PMK all the time (the seed of which is known plaintext, because the SSID is used as seed!), now every client uses a different PMK, it changes every session/association and the seed is random and unknown. Not only that, but this PMK will be 256bit real entropy (not a hash from a usually much smaller password containing words), so dictionary attacks are useless.

Should someone break a particular PMK, they only get access to one session of one client. Also (if the right EAP method is used) they don't get access to the users credentials, since they were individually encrypted. That's a whole lot more secure.

Also remember that this PMK is 256bit AES, this is currently "uncrackable" (128 bit is considered safe for the moment, but not for long). The fact that the PMK of WPA2-PSK (also 256bit) can be cracked comes from the usually weak passwords (dictionary attack), the known seed (SSID) and the fact that all clients use the same PMK all the time, so a lot of ciphertext of known plaintext can be captured.

So, then a little about the Extensible Authentication Protocol (EAP). This is often understood as a security protocol in itself, but it isn't. It's basically a standard for passing messages from a client wanting to authenticate and a server that authenticates. EAP itself has no security features, it just specifies how the client speaks with the RADIUS server.

Now, you can encapsulate these EAP messages in a secure tunnel. Like HTTP (an insecure messaging protocol) goes over a secure layer, SSL/TLS to yield a secure connection to a web server. Someone said in another answer that there are over 100 different EAP "methods' ', some very insecure. This is true, because EAP is old there were encryption standards implemented that are sub-standard today.

But in practice, if you need to support recent Apple or Android machines/devices and Windows machines, there's only two options, because others are simply not supported: Protected EAP (PEAP) and TLS-EAP (well, I lied: really there are a few more, but they are basically identical to TLS-EAP in functionality and security).

PEAP is just like a https server, a secure TLS tunnel is setup between the client and the RADIUS server (protecting the entire wireless and wired path between them), the server presents a certificate to the client (in companies often signed by their own CA) and a secure channel is setup on the basis of this certificate.

If the client has the CA as trusted in their certificate store it sends its username and password to the RADIUS server. If the CA isn't trusted, the user gets a warning about the certificate as with a https site that has something wrong with its certificate. The credentials are usually protected with the (old and now weak) MSCHAPv2 protocol, but that doesn't matter, since everything is already protected by 256bit TLS. The MSCHAPv2 protocol talks with the RADIUS server using EAP.

An obvious weak point is that you could set up a false access point, present a false certificate of which you have the private key, and hope that some idiot user gets a warning about an untrusted certificate and just clicks "trust" (and that option is not disabled by an administrator). Then you could maybe capture the client's weakly encrypted credentials that are fairly easy to crack (I'm not sure about this, as I know MSCHAPv2 can be easily cracked if you have the WHOLE exchange, in this case you'd only have the client side as you couldn't send a valid nonce to the client to complete the exchange, as you don't have the real hash of the users password).

While this may get you access to the real network with a lot of work (and I doubt it, but if you must know, look into MSCHAPv2 at http://www.revolutionwifi.net/revolutionwifi/2012/07/is-wpa2-security-broken-due-to-defcon.html), it wouldn't get you access to any other wireless data, as they are encrypted with a different PMK.

But for companies this may still be a problem. Enter TLS-EAP. TLS-EAP is basically the same as PEAP with the notable difference that the client also has a certificate. So the server presents its certificate to the client which must be trusted by the client (because the CA is in the trusted store, or an idiot clicked "trust"), but the client also has to present a certificate to the server. This can be a certificate that's been placed in the cert store when the device/workstation was provisioned, but it could also be from a smartcard etc. The server has to trust this client certificate, or you won't even get the chance to present credentials.

As many of you may know, such 2-way authentication can also be done for HTTP over TLS, but this is not often seen outside corporate settings. In that case, too, you can't access the website unless you first show a certificate that's trusted by the server.

So now the fake access point isn't very useful anymore. You may get the weakly encrypted credentials if the idiot clicks "trust" and you then blindly accept any client certificate, but since you don't have the private key of the client certificate you don't get access to the wireless network, nor do you get encrypted wireless data of this or other clients still courtesy of the random session-based PMK. You may get access to some intranet with the credentials, but if they went to the trouble to setup a CA for wireless they probably require a client cert for that too.

In corporations it's common to have such a client cert on a smart card, which employees then need to access all resources: logging in, network resources, mail using smtps, imaps, pop3s, intranets using https, anything that uses TLS can be setup to require a client certificate. Usually it's as simple as putting it in the keyboard and entering a PIN, then windows will present it when demanded by a trusted server running TLS.

So, I hope this clarifies a bit. The scale goes: "basically unsecured" (WEP) "crackable with some effort" (WPA2-PSK) "partly social-engineerable" (WPA2-Enterprise w/PEAP) "currently secure" (WPA2-Enterprise w/TLS-EAP and similar)

There are ways to make WPA2-PSK somewhat more secure, in that it would take months to crack it instead of minutes (precomputed rainbow tables) or hours (dictionary attack): Set your SSID to a random string of the maximum length (64 I think), since it's used as the seed for the PMK, and use a random pre-shared key (PSK) of the maximum length. If you then change the key monthly you can be reasonably sure that nobody has a current PMK or has access to your network.

Though you can't get rid of the fact that someone could have stored a months worth of data of all clients and reads that once they do get the PMK of that month (which can be done, as it's not a key with 256bit real entropy as you're broadcasting the seed used).

Another drawback is that you will have a highly unique SSID, one that your wireless devices will broadcast wherever you go. If someone has your unique SSID of your home network it's a piece of cake to look up your SSID at https://wigle.net/ and find out where you live. So you're basically walking around with your phone/tablet/laptop announcing where you live...

If you're privacy conscious it's maybe a good middle way to keep your SSID set to one that's common, but not in the top 30 or so (that way it's unlikely to have rainbow tables for it available online) and use a random PSK of maximum length. You lose some entropy though.

If you want the same security as wired, use WPA2-Enterprise with TLS-EAP. (Well, for now... There's nothing stopping someone from capturing and storing all the data they want and decrypting it all in 20 years when we can all rent time on a quantum computer and factor all keys in minutes.

The NSA is said to have built a datacenter to do just that, store anything encrypted they encounter until they can crack it, so that problem also affects everything on wires if it crosses the internet. If something needs to be secure for all time, use a random one-time pad that you exchange out-of-band

All that said, while I'm paranoid and want the best security and thus spend two days making WPA2-Enterprise/TLS-EAP work, this is probably out of reach (and overkill) for most home users. If you don't already have a domain controller or some other directory service on your network, experience with RADIUS and have all expensive pro wifi gear that an enterprise would use then you most likely won't get it to work. You'd be better off just setting up an always-on VPN and running that over your wifi, that gives you all the security and none of the fun debugging EAP.

PS. For the sake of simplicity I also left out the fact that the communication between the access point and the RADIUS server is also encrypted by a pre-shared key (called the "shared secret"). Afaik this encryption isn't any good today (uses MD5 which is basically broken) but since you put TLS over it anyway that doesn't matter. You can use a decent key size (something between 64-128 chars = 512-1024bits depending on the implementation). I always set the largest secret possible, it can't hurt.