Well, there are no benefits, because using PMKID allows to skip authentication stage, which is non-existent when PSK is used anyway. The only reason to include PMKID when PSK is used is because 802.11 does not seem to be very specific about whether it must be included. What if there is some client that is very strict on checking what it receives?Are there any benefits for sending PMKID for non-EAP networks (some people claim that there aren't)?
We will add an option to disable sending PMKID in handshake message 1.If no, is it planned to fix this vulnerability (by not sending PMKID for PSK networks)?
PMKID is generated based on PSK used in key exchange, so in order to brute force particular password you must sniff handshake frame sent by AP that contains PMKID generated using PSK that you are interested in. Note that "access-list" operates on mac-address that can be spoofed by attacker relatively easy, so it is not adding more security - attacker either needs to observe handshake of legitimate client or spoof clients mac-address and attempt handshake (it will fail, but nevertheless attacker will get the frame with PMKID). If you use per-client PSK, in case PSK for one client gets compromised, you only need to change it for particular client, not all of them.Also what is behavior for this bug when "/interface wireless access-list" is used to provide different PSKs for different client MAC addresses?
Considering that attacker can sniff frames and spoof mac-address, the only situation where this will help is when attacker can not figure out the mac-address it should use to attempt connecting, but this can not be considered protection. If attacker finds out mac-address of client that is allowed to connect, he can cause key handshake and attempt to brute force the PSK.And what is behavior for this bug when wireless interface has "default-authentication=no" (in combination with "/interface wireless access-list" entries)?
Possibly Ubiquity might not be sending PMKID.The only reason to include PMKID when PSK is used is because 802.11 does not seem to be very specific about whether it must be included. What if there is some client that is very strict on checking what it receives?
Thank you very much for adding this option!We will add an option to disable sending PMKID in handshake message 1.
So in this scenario:PMKID is generated based on PSK used in key exchange, so in order to brute force particular password you must sniff handshake frame sent by AP that contains PMKID generated using PSK that you are interested in. Note that "access-list" operates on mac-address that can be spoofed by attacker relatively easy, so it is not adding more security - attacker either needs to observe handshake of legitimate client or spoof clients mac-address and attempt handshake (it will fail, but nevertheless attacker will get the frame with PMKID). If you use per-client PSK, in case PSK for one client gets compromised, you only need to change it for particular client, not all of them.
No. In order to obtain any PMKID attacker must get to key handshake phase that happens only after successful 802.11 association. If client is not in access-list, it is refused 802.11 association and AP does not even go to key handshake phase.So in this scenario:
- "default-authentication=no" is set for access point
- corresponding "/interface wireless security-profiles" has wpa-pre-shared-key and wpa2-pre-shared-key set to some value (e.g. "wpa-pre-shared-key=Password123 wpa2-pre-shared-key=Password123")
- "/interface wireless access-list" has entries for clients with a different "private-pre-shared-key" for each client
- at the moment of attack no clients are connected (and attacker does not know MAC addresses of clients)
The only information attacker can obtain is PMKID of "wpa2-pre-shared-key" mentioned in security-profile (in this example - hash that bruteforces to "Password123"), correct?
So in this scenario attacker won't be able to obtain any password hashes (assuming attacker will not try to guess MAC addresses)?No. In order to obtain any PMKID attacker must get to key handshake phase that happens only after successful 802.11 association. If client is not in access-list, it is refused 802.11 association and AP does not even go to key handshake phase.
Correct. Like I said - in order to obtain PMKID attacker has to either observe or cause key handshake and that happens only after successful 802.11 association. In RouterOS access-list checking (and radius-mac-authentication as well) happens before key handshake (this is kind of obvious, because access-list or radius-mac-authentication can provide PSK).So in this scenario attacker won't be able to obtain any password hashes (assuming attacker will not try to guess MAC addresses)?No. In order to obtain any PMKID attacker must get to key handshake phase that happens only after successful 802.11 association. If client is not in access-list, it is refused 802.11 association and AP does not even go to key handshake phase.
This is an English forum. Please post in English for all to read. You can edit your post and change it.a inda a varias vulnerabilidade, depois vou mostrar umas das brechas a ser corrigido.
So far all devices i tried connects just fine.What's new in 6.43rc56 (2018-Aug-13 11:13):
...
*) wireless - added option to disable PMKID for WPA2 (CLI only);
...
According to Qualcomm you need new chipsets for WPA3 so it seems that old gear wont be able to support it ...And what about working on WPA3?
As far as I can tell that is a big spit of "bullspit" WPA3 can be done in software only if the hardware features in a old chip is to slow. But then again braindead old cheap AP's have slow cpu's as well so........... But supporting a new standard is one thing. Turning on ALL nerd nobs of that new standard is another one.According to Qualcomm you need new chipsets for WPA3 so it seems that old gear wont be able to support it ...And what about working on WPA3?
Or at least, "whether"
Mikrotik: How about a statement of how,when,where will we be able to use WPA3 instead?
Yes it is true. Sometimes Mikrotik might be the firstSomeone has to be the first, if all is waiting for all other to release WPA3 it will never come
It already is. Just try it.Of course this will be also as option on Capsman?
@Normis, When can we expect WPA3 updates on the Mikrotik devicesWPA3 is not supported in any client devices yet, as far as I know.
People have other devices too.Not a single Mikrotik hardware uses Cypress or Broadcom wireless chipset, so answer is clearly NO.
Update: Cisco is working on patches.Kr00k.... should we worry about this?