Wi-Fi Alliance Launches WPA3 Security Standard (securityweek.com) 97
wiredmikey writes: The Wi-Fi Alliance, the organization responsible for maintaining Wi-Fi technology, announced the launch of the WPA3 security standard. The latest version of the Wi-Fi Protected Access (WPA) protocol brings significant improvements in terms of authentication and data protection.
WPA3 has two modes of operation: Personal and Enterprise. WPA3-Personal's key features include enhanced protection against offline dictionary attacks and password guessing attempts. WPA3-Enterprise provides 192-bit encryption for extra security, improved network resiliency, and greater consistency when it comes to the deployment of cryptographic tools.
WPA3 has two modes of operation: Personal and Enterprise. WPA3-Personal's key features include enhanced protection against offline dictionary attacks and password guessing attempts. WPA3-Enterprise provides 192-bit encryption for extra security, improved network resiliency, and greater consistency when it comes to the deployment of cryptographic tools.
Some info (Score:5, Informative)
Too bad, my submission has been rejected even though it had a lot more information which I'll post anyways:
New security features include:
Source [bleepingcomputer.com]
Re: (Score:2, Interesting)
its a poorly kept secret that wiredmikey is banging msmash
your submission had no chance
Opportunistic Wireless Encryption (Score:5, Insightful)
Most of this is incremental security improvements, as for most users, WPA2 is still sufficiently secure. However, the big deal here is the opportunistic encryption that will encrypt connections that don't require authentication. That's a big deal.
I like to leave my WiFi open for guests, but I have to set up a separate network in order to keep my regular use encrypted. Once everything supports opportunistic encryption, I can just have one network. That's not particularly important.
Where this matters is public WiFi. Many stores have free WiFi with no password. Often they have a login after you connect (annoying, but a separate issue), but there is no encryption on the link. Anyone who knows what they're doing can see every packet you send. When this technology becomes widespread, it will become a bit harder for evesdroppers.
Of course, using public WiFi, you should be using end-to-end encryption on anything important. This is pretty much standard these days for most things, but too often something slips through.
Re: (Score:2)
Aside from open networks like you've mentioned. Also, WPA2 allows offline password recovery when authentication is enabled and that's a really bad thing since many people like to use very simple digit only passwords which can be trivially guessed using a modern GPU and hashcat or using a service like GPUHash.
Re: (Score:2)
However, the big deal here is the opportunistic encryption that will encrypt connections that don't require authentication. That's a big deal.
That's an oxymoron.
Re: (Score:2)
No, it's not.
Encryption means a third party eavesdropping can't parse the communication.
Authentication means the host validates the identity of the client, typically using a password.
There's no requirement that these be linked. Of course, authentication without encryption is quite difficult to do securely. Encryption without authentication does leave the door open for a man-in-the-middle attack, but it does block passive monitoring.
Re: (Score:2)
No, it's not.
Yes it is.
Encryption means a third party eavesdropping can't parse the communication.
Encryption without trust is an oxymoron. "Third party" is a rather meaningless concept when you have no earthly clue who the "first party" is in the first place.
There's no requirement that these be linked.
Trust is a core requirement of EVERY secure system with NO EXCEPTIONS.
Encryption without authentication does leave the door open for a man-in-the-middle attack, but it does block passive monitoring.
Who cares? If I can receive a signal I can transmit one just as easily. All WiFi radios are transceivers.
Given proliferation of https the salient threat to end users from unsecured Wi-Fi has always taken the form of ACTIVE adversaries doing a hell of a lot more than j
Re: (Score:2)
An active attack (e.g. a MITM attack) is detectable.
If active attacks are so detectable why are they allowed to happen? Why are they not "detected"? Did the attacker forget to set evil bit?
A passive attack (e.g. eavesdropping on a WPA2 encrypted connection when you know the PSK) is undetectable.
I think I understand in narrow must be true by construction of argument sense if nothing transmits a signal then a transmitted signal can't be detected. Otherwise in any context with real life import this assertion is most certainly false.
In the real world there must be time and effort expended to prepare attacks. The receiver must have a physical presence and associat
Re: (Score:2)
Allow me to present an analogy: Government spies do "full take" surveillance. They just record everything. This is a passive attack and it's thwarted even by
So now I'm supposed to think that stalking is "attacking" or were the goal posts installed in shifting sands? Where do I file a criminal complaint against Google and Microsoft for "attacking" me?
Government spies are pulling everything enmasse from fiber taps of all the tier 1 carriers. They don't give a crap about local Harbucks wifi except to collect MAC addresses and perform trivial flow analysis to deduce your address and what your doing regardless of your use of encryption.
encryption without authentication. You may think that most Wifi attacks worth pulling off are active attacks, but I posit that you only think so because you don't hear much about passive attacks, as they are practically impossible to detect.
I posit invisible fire breat
Re: (Score:2)
Are you daft? We know that passive attacks on WPA/2 exist.
The thread has nothing to do with attacking WPA2. It's all about stupid pointless quibbling over the relative uselessness of "opportunistic encryption".
OP incorrectly believes it's a "big deal".
I think it's better than nothing and worth doing but only if kept quiet and not advertised to the public as a security measure.
Re: (Score:2)
Once the crypto over wifi is working its working well and strong. Thats not the way in.
The trick was that very first part when wifi had to talk for the first time to a new wifi communications attempt.
The very first attempt at a reach out and before the start of encryption could be overpowered as to allow a third party to become part of that later "secure" wifi ne
Re: (Score:2)
It's an improvement, and I'd much rather have it than not, but without any authentication you have no way of knowing in a public WiFi hotspot if the AP you connected to is the one operated by the hotspot, or the one running off the laptop of the guy next to you sipping a latte he payed for from the bank account of the last guy who sat where you are sitting. Same goes for anything using a symmetric key, so adding a WiFi password that you then tell to everyone does not help things.
It's TBD whether the extra
Forward Secrecy (Score:2)
I also understand that WPA3 will get forward secrecy [wired.com], and sessions will negotiate a temporary ("ephemeral") key for symmetric cryptography (assuming AES).
Should the traffic be recorded, it cannot be decrypted later if the password is broken.
Re: Opportunistic Wireless Encryption (Score:2)
I am a home desktop user. For my passwords, I run a sha256sum against a text string that I can easily remember for a given website and I use that sha256sum hash as my password. The hash from sha256sum is long enough that they can't figure out my initial text input. My simple text string is easy to remember as I can't ever remember what my hashed value waz or would be.
Re: (Score:2)
War is Peace
Freedom is Slavery
Ignorance is Strength
Open is Proprietary
Re: (Score:2)
With a word salad like that I'm not surprised it was rejected. That was incredibly hard to read. Summaries and formatting exist for a reason and a Slashdot Sunday shouldn't take up my entire screen.
Re: Professor Fritzen Posten (Score:1)
I showed up, but the professor was late. So we all went home.
She has huuuuge tracts of land... (Score:5, Funny)
So we built WPA on top of it and it sank into the swamp
Then we build WPA2 on top of it and it caught fire and sank into the swamp
But WPA3.. WPA3 will stand the test of time!
Re: (Score:2)
Anybody selling that lie needs to understand that ALL cryto based security techniques are temporary, regardless of how well they are envisioned and implemented.
Which is why Wi-Fi Alliance has no business rolling their own. They should use TLS at least to derive session keys if for no other reason than crypto agility.
Re: (Score:2)
Re: (Score:2)
How do you propose that the Transport Layer be used to provide security for the Data Link Layer?
TLS is transport agnostic. Just needs something that acts like a byte stream to work. TLS is for example is commonly negotiated over 802.1x/EAPOL which in-turn provides encryption keys to lower layers.
Re: (Score:2)
WPA2 with CCMP (not TKIP) is still secure enough
Re: (Score:2)
It's an arms race. Each new iteration of security is presumably stronger, but the bad actors also get smarter. There will never be a "final" version.
Re: She has huuuuge tracts of land... (Score:1)
Upgrading existing WPA2 WiFI APs (Score:2, Interesting)
Is this something a router/access point running OpenWRT could upgrade to? Or would WPA3 require a driver/firmware upgrade as well?
Re: (Score:2)
Strange the article doesn't mention about upgrade ability. I assume there is none like last time for WPA to WPA2.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, pretty sure. WPA3 development for hostapd has been proceeding abreast the standard development process. Perhaps some chipsets may not be able to pull off the 192-bit crypto suite in hardware... but nearly nobody will deploy that I would guess. No idea on timelines... you can watch for code commits on w1.fi/cgit but you need to know a whole buttload of acronyms to understand WTH is going on.
Why are there two? (Score:1)
Why are there separate Personal and Enterprise ones?
Re: (Score:2)
What's the difference between Personal and Enterprise profiles? [stackexchange.com]
Re: (Score:2)
With luck this time devices will need to support both personal and enterprise to be considered WPA3 compliant. Lack of enterprise support is one of the big pain points in supporting consumer-grade devices on a campus network.
Re: (Score:2)
It's all the little TV-attached gadgets these days. No laptops or phones ship without WPA2-Enterprise.
Now, tons of them still arrive with an insecurable PEAP-MSCHAP/TTLS implementation (thanks tons Google) but that's a different issue.
Re: (Score:3)
It depends on whether you're willing to spend money for additional security.
Personal authentication is less secure, but you don't need anything besides the router.
Enterprise authentication is more secure but requires additional infrastructure. E.g., the 802.1X authentication for WPA2 Enterprise requires a RADIUS server or equivalent to authenticate users. Since enterprise authentication is unique for each user, you can assign network access with per-user profiles with more equipment (e.g., Cisco ISE).
Re: (Score:2)
It depends on whether you're willing to spend money for additional security.
Personal authentication is less secure, but you don't need anything besides the router.
Enterprise authentication is more secure but requires additional infrastructure. E.g., the 802.1X authentication for WPA2 Enterprise requires a RADIUS server or equivalent to authenticate users. Since enterprise authentication is unique for each user, you can assign network access with per-user profiles with more equipment (e.g., Cisco ISE).
And if you want to do Corporate certificate authentication it requires a certificate infrastructure, certificate management, and a way to install certificates on devices (i.e. AD policies, Airwatch, etc.).
Re: (Score:2)
Personal authentication is less secure, but you don't need anything besides the router.
The F**** it is. If you select a PSK with sufficient entropy and successfully guard it from "undesirables" it's way more secure than enterprise.
Enterprise authentication is more secure but requires additional infrastructure. E.g., the 802.1X authentication for WPA2 Enterprise requires a RADIUS server or equivalent to authenticate users.
LOL... is this the same ultra secure protocol that encrypts session encryption keys between authenticator and AP with MD5 xor? Give me a break.
Re: (Score:2)
The F**** it is. If you select a PSK with sufficient entropy and successfully guard it from "undesirables" it's way more secure than enterprise.
It's the guarding it from undesirables part that makes WPA2 less secure. Otherwise it is as secure, not more secure, than properly implemented WPA2-Enterprise.
The trick to properly implementing WPA2-Enterprise is mostly in the client setup, as long as you follow some pretty well understoof best practices on the server side.
As to the GP: if your OpenWRT box has enough RAM and flash, you can get the entire WPA2-Enterprise stack up on a single device.
Re: (Score:2)
The trick to properly implementing WPA2-Enterprise is mostly in the client setup, as long as you follow some pretty well understoof best practices on the server side.
I disagree. With one or a small number of individuals WPA2 provides superior security.
I've never seen a properly configured supplicant in my life.
Basic things like linking cert identity to what your connecting to have been punted to clueless end users. The only reasonable way WPA2-Enterprise works in practice is by pushing configuration to clients in advance.
I've also never seen a secure authenticator in my life. I very much doubt a secure implementation even exists in the field. Encryption keys for the
Re: (Score:2)
I've never seen a properly configured supplicant in my life.
If you have few enough users that you can safely share the PSK among them, you have few enough
users to go secure their supplicants. Also, even misconfigured OSX users are relatively safe assuming they
connect safely the first time, given the supplicant's pinning behavior.
I've also never seen a secure authenticator in my life.
...you ain't been around. Most systems these days authenticate from the controller, not the AP,
so the RADIUS all happens in the DC, behind locked doors. AP/Controller comms is by IPSec
or a vendor's minor perversion of IPSec, usually built
Re: (Score:2)
...you ain't been around. Most systems these days authenticate from the controller, not the AP,
so the RADIUS all happens in the DC, behind locked doors. AP/Controller comms is by IPsec or a vendor's minor perversion of IPSec,
You're right, I've not been around. I've never seen an environment where any of this has occurred. All I see are APs terminating RADIUS and RADIUS over insecure WAN/LAN and even Internet links.
Also a lot of the controllers support either terminating IPSec generically,
or RadSec for RADIUS.
Now I know you are just fucking with me. A lot of nothing currently supports RadSec.
Re: (Score:2)
I guess HPE-Aruba counts as a lot of nothing?
https://www.arubanetworks.com/... [arubanetworks.com]
Re: (Score:2)
I guess HPE-Aruba counts as a lot of nothing?
Did some trolling of vendor sites and while most vendors in our orbit of the world don't support RadSec I did find two that do. This is really nice to see and somewhat unexpected. I hope adoption picks up rapidly.
Re: (Score:2)
Yeah... the generic IPSec support for control plane stuff is even better, but I'll take RADSec when I can't get that.
(We were actually running it from FreeRADIUS with the eduroam TLRs for a while but they stopped supporting it. Hopefully to return some day.)
Was just reading up on EAP-PWD as a result of this thread... needs a password change mechanism and identity privacy but good to see something
else practical gaining some small toehold (on Android).
Maybe wrap it in an opportunistic unauthenticated TLS ses
Re: (Score:2)
Was just reading up on EAP-PWD as a result of this thread... needs a password change mechanism and identity privacy but good to see something
else practical gaining some small toehold (on Android).
EAP-PWD = Dragonfly = Flawed = Fixed protocol = Mistake.
Just use EAP-TLS yet rather than or in addition to certs use a PAKE at TLS layer like TLS-SRP. It is drop in compatible with existing RFCs, you just need to write a couple of callbacks to make it work and it will benefit from generic interfaces for other PAKE like ciphers to provide crypto-agility in TLS 1.3 and beyond so your not constantly chasing protocols.
Maybe wrap it in an opportunistic unauthenticated TLS session to gain fast resumption and identity privacy against passive (but not active) attackers, but that still leaves you without an inline password-change mechanism...
The nice thing about TLS-SRP it allows you to do both RSA and SRP so identity doesn't have to
Re: (Score:2)
What makes enterprise more secure is the fact that the encryption key changes with each user session. So even if someone manages to break your WPA2 Ent. key, they can only get data from that single session
There are two avenues of attack either one is sufficient to completely retroactively defeat session encryption.
The first and most difficult avenue is defeating session keys derived between authenticator and supplicant.
Session keys are derived from the TLS sessions premaster secret + peer randoms. If the authenticator's private key is compromised you can do the exact same shit and compromise all prior sessions for the case where TLS premaster secret was not derived from a forward secure cipher suite. Depen
Re: (Score:3)
Short version: because when you fire an employee you want to cut their wifi access without changing everyone else's password.
Re:Why are there two? (Score:4, Informative)
Re: Why are there two? (Score:1)
Personal and Enterprise bs. (Score:2)
continuing the bs... It should be as good as it can be... no need for half arsed Personal version
Re: (Score:2)
To make use of the additional features of the enterprise version you need additional servers and networking equipment.
Without that additional equipment, you're running the personal version anyway.
Re: (Score:2)
And this is WPA3. It offers more than WPA2. RTFA.
Will enterprise still be a clusterfuck to setup? (Score:2, Interesting)
I understand that WPA Enterprise is built off existing technologies but holy fuck setting up it's infrastructure should not be like pulling teeth.
If someone could figure out a way to create an easy to implement, reasonable cost WPA enterprise-as-a-service they would literally print fucking money. Bonus if you could tie it in to an SSO service.
Re: (Score:1)
They did, it's called FreeRADIUS. [freeradius.org]
The only thing missing is a Wizard to set up the server, and a easy way of getting the certs installed on endpoint machines.
Smart devices work perfectly fine. Just install the cert and go.
Windows needs GP to do this without seeing windows' ugly side. A.K.A. Non-descriptive Dialog
Most important feature (Score:5, Interesting)
Knowledge of the pre-shared key in personal mode no longer give an attacker the opportunity to decrypt everything on the network. In WPA and WPA2, an attacker who knows the PSK (for example that of a public hotspot) can passively record the handshake frames and recover the keys used by other clients. WPA3 prevents this, so even when you use a public hotspot, the connections between your computer and the access point are secure against passive attacks. (An attacker can still perform a MITM attack because there is no way to authenticate a public hotspot with a non-secret PSK.)
Re: (Score:2)
Yep. Anything radio is an untrusted medium. Hell, people use VPNs over leased lines, sure as hell you want a VPN over anything wireless purely for convenience (site-to-site interlinks, it goes without saying that you want VPN).
Plus, it just gives you that double-layer. Sure, you might crack WPA but you've still then got to break through AES or whatever. And sure, AES might get a flaw but if you've got to be nearby and break the WPA to see that you're even using it, that's another layer of protection. T
WPA3 is flawed out of the gate (Score:3)
WPA3 is resistant to dictionary attacks. The Wi-Fi Alliance says that WPA3's SAE is resistant to offline dictionary attacks where an attacker tries to guess a Wi-Fi network's password by trying various passwords in a quick succession.
WPA3 uses Dragonfly which was shown to be vulnerable to small subgroups that can be exploited to conduct offline dictionary attack.
https://en.wikipedia.org/wiki/... [wikipedia.org]
RFC 7664 section 4 even provides optional advice for mitigation.
Amazing to see new security protocols out of the gate include crypto known to be flawed.
Re: (Score:2)
I think you're greatly exaggerating the problems. If you do public key validation, as we've long known you should do to protect against these kinds of attacks, the problem goes away. Or, if you use safe-prime groups, as the community has moved to for DH, the problem pretty much goes away. It should go away for ECC groups, too.
Re: (Score:2)
I think you're greatly exaggerating the problems.
I never expressed an opinion with regards to severity. What I know is the flaw exists in Dragonfly while other PAKEs have addressed the specific problem.
If you do public key validation, as we've long known you should do to protect against these kinds of attacks, the problem goes away.
What this essentially says is that if you punt the problem to something else the original problem no longer matters.
This isn't at all useful. The whole point of PAKEs are to securely leverage mutual password knowledge to establish a secure trusted channel not offload trust to something else. If a particular PAKE is incapable of doing what it is intended
Re: (Score:2)
First, keep in mind the WiFi Alliance isn't developing standards. The standards are developed in IEEE 802.11. The WiFi Alliance is basically creating a profile of the 802.11 standards that they'll cover as part of their certification program. Dragonfly is used because that's what's specified in 802.11.
Are there better ones? Perhaps, although Dragonfly has been around for a while and has been the subject of third-party analysis. There's something to be said for preferring an older scheme with well-unde
Re: (Score:2)
Are there better ones? Perhaps, although Dragonfly has been around for a while and has been the subject of third-party analysis. There's something to be said for preferring an older scheme with well-understood implementation considerations (which you're calling "flaws") over newer proposals that might seem to have better properties, but whose implementations haven't been fully considered. In other words, prefer the devil you know.
SRP-6 is now something like 16 years old. The only excuses in various WGs for not using it last decade were unspecified patent fears from company "L" too lazy to perform an internal search and state a public position. All of that is history now.
Public key validation doesn't refer to a PKI. It just means when you're doing a Diffie-Hellman key exchange you should check that the public key you receive is in the subgroup its supposed to be in.
I don't understand the difference. Who creates the public key? How does the peer validate/trust it?
When I hear use public key I think of cipher suites which leverage both the PAKE and RSA et el together in a single TLS handshake. This requires servers to possess