Re: WPA-PSK password length requirement
On 12/11/2012 06:27 PM, Dan Williams wrote: On Tue, 2012-12-11 at 14:01 -0500, Robert Moskowitz wrote: On 12/11/2012 01:53 PM, Dan Williams wrote: On Tue, 2012-12-11 at 13:17 -0500, Robert Moskowitz wrote: On 12/11/2012 10:02 AM, Dan Williams wrote: On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. First I was a major contributor to 802.11i and wrote the first paper on the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your typical end user having a complaint on client behaviour. Yesterday, I was at a major corporation for a meeting and the quest SSID had a 6 digit all numeric passcode. NM would not let me connect; it seem to insist that a passcode for WPA2-PSK be at least 8 characters long. The meeting participants using Windows had no difficulty with this 6 digit passcode and were able to get on the guest wireless network. If it's a 6 digit passcode, then it's not a valid WPA passphrase. Um, I helped write that section of 802.11i. Of course now it is just part of 802.11-2012: M.4 Suggested pass-phrase-to-PSK mapping The pass-phrase mapping defined in this subclause uses the PBKDF2 method from PKCS #5 v2.0 [B53]. PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256) Here, the following assumptions apply: — A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal characters. — Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal), inclusive. So, yes, we wrote the standard for 8-63 characters. But there are product out there that allow for smaller. Just bad implementations, but the real world. And these devices pass WiFi Alliance certification? Given who this company is, I suspect yes. I was just thinking; I can get the BSSID and that will give us the MAC manufacture which is probably the device manufacture :) But their security certification has always been weak to compliance. ICSAlabs put in a bit back in the days, but we lost out as all we were 'good' at was the security and did not have experience in RF certification. Note that wpa_supplicant does not allow passphrases with a shorter length than 8 characters: if (len < 8 || len > 63) { wpa_printf(MSG_ERROR, "Line %d: Invalid passphrase " "length %lu (expected: 8..63) '%s'.", line, (unsigned long) len, value); return -1; } If you plead your case to Jouni (the hostap/wpa_supplicant maintainer who also helps draft 802.11 standards), and he agrees to allow shorter-than-8-char passphrases, then I'll entertain lowering the limit in NetworkManager. I will probably see Jouni at the January meeting in Vancouver. Random aside: another problem we periodically have is the character encoding for hashing passphrases to the actual PSK. When entering the initial setup passphrase in a browser, and if the browser allows non-ASCII characters, it's entirely unknown (a) what encoding the browser is set to, and (b) how the software on the AP hashes the passphrase to the PSK. We've had problems with passphrases that contain umlauts, for example. Oh, we have discussed this endlessly at the IETF, going way back. It can get very messy. Even Unicode will not help you out here; in fact it can make it worst! And this is causing major chanellenges for ISN. When you're next at that location, if there's any chance you get get the actual hashed passphrase (ie 64 hex chars) from somebody, I'd love to see see how the shorter-than-8-char passphrase got hashed to a PSK; did it get padded with zeros or something? Or just hashed straight-up? I am so rusty with running Wireshark over wireless. I was probably running F10 when I would be doing this sort of thing. I will try and brush up early next week (I am off the next 2 days to visit my son in NJ). I recall now that on the white board where they wrote down the wireless access, they definitely said WPA2-PSK and that 6 digit code. And windoze people were getting on the wireless network. If you're able to get a scan of that network, I'd be very curious to see what it's output is. It *may* be a WPS network, which is a method to set up a wifi connection somewhat like pairing a Bluetooth device. That allows all numeric PIN codes, and automatically determines the *actual* passphrase from a handshake that uses the PIN. Nope, as there is more involved to use WPS. That does not work well at all in a big office building in the meeting rooms in same. But for the 'fun' of it, I will try it with WPS. On any SSID I set up, I will use a reasonably strong passcode (though I would REALLY like to start using SAE in place of PSK!), but sometimes you have NO control over what others do. I REALLY need an override on the passcode length requirement; I will again be at that location for a meeting Dec 19. Excel
Re: WPA-PSK password length requirement
On Tue, 2012-12-11 at 14:01 -0500, Robert Moskowitz wrote: > On 12/11/2012 01:53 PM, Dan Williams wrote: > > On Tue, 2012-12-11 at 13:17 -0500, Robert Moskowitz wrote: > >> On 12/11/2012 10:02 AM, Dan Williams wrote: > >>> On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: > The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. > > First I was a major contributor to 802.11i and wrote the first paper on > the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your > typical end user having a complaint on client behaviour. > > Yesterday, I was at a major corporation for a meeting and the quest SSID > had a 6 digit all numeric passcode. NM would not let me connect; it > seem to insist that a passcode for WPA2-PSK be at least 8 characters > long. The meeting participants using Windows had no difficulty with > this 6 digit passcode and were able to get on the guest wireless network. > >>> If it's a 6 digit passcode, then it's not a valid WPA passphrase. > >> Um, I helped write that section of 802.11i. Of course now it is just > >> part of 802.11-2012: > >> > >> M.4 Suggested pass-phrase-to-PSK mapping > >> > >> The pass-phrase mapping defined in this subclause uses the PBKDF2 method > >> from PKCS #5 v2.0 [B53]. > >> > >> PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256) > >> > >> Here, the following assumptions apply: > >> — A pass-phrase is a sequence of between 8 and 63 ASCII-encoded > >> characters. The limit of 63 comes > >> from the desire to distinguish between a pass-phrase and a PSK displayed > >> as 64 hexadecimal > >> characters. > >> — Each character in the pass-phrase must have an encoding in the range > >> of 32 to 126 (decimal), > >> inclusive. > >> > >> So, yes, we wrote the standard for 8-63 characters. But there are > >> product out there that allow for smaller. Just bad implementations, but > >> the real world. > > And these devices pass WiFi Alliance certification? > > > Given who this company is, I suspect yes. I was just thinking; I can get > the BSSID and that will give us the MAC manufacture which is probably > the device manufacture :) > > But their security certification has always been weak to compliance. > ICSAlabs put in a bit back in the days, but we lost out as all we were > 'good' at was the security and did not have experience in RF certification. Note that wpa_supplicant does not allow passphrases with a shorter length than 8 characters: if (len < 8 || len > 63) { wpa_printf(MSG_ERROR, "Line %d: Invalid passphrase " "length %lu (expected: 8..63) '%s'.", line, (unsigned long) len, value); return -1; } If you plead your case to Jouni (the hostap/wpa_supplicant maintainer who also helps draft 802.11 standards), and he agrees to allow shorter-than-8-char passphrases, then I'll entertain lowering the limit in NetworkManager. Random aside: another problem we periodically have is the character encoding for hashing passphrases to the actual PSK. When entering the initial setup passphrase in a browser, and if the browser allows non-ASCII characters, it's entirely unknown (a) what encoding the browser is set to, and (b) how the software on the AP hashes the passphrase to the PSK. We've had problems with passphrases that contain umlauts, for example. When you're next at that location, if there's any chance you get get the actual hashed passphrase (ie 64 hex chars) from somebody, I'd love to see see how the shorter-than-8-char passphrase got hashed to a PSK; did it get padded with zeros or something? Or just hashed straight-up? Dan > > > > Dan > > > >>> If you're able to get a scan of that network, I'd be very curious to see > >>> what it's output is. > >>> > >>> It *may* be a WPS network, which is a method to set up a wifi connection > >>> somewhat like pairing a Bluetooth device. That allows all numeric PIN > >>> codes, and automatically determines the *actual* passphrase from a > >>> handshake that uses the PIN. > >> Nope, as there is more involved to use WPS. That does not work well at > >> all in a big office building in the meeting rooms in same. But for the > >> 'fun' of it, I will try it with WPS. > >> > On any SSID I set up, I will use a reasonably strong passcode (though I > would REALLY like to start using SAE in place of PSK!), but sometimes > you have NO control over what others do. I REALLY need an override on > the passcode length requirement; I will again be at that location for a > meeting Dec 19. > >>> Excellent, can you run: > >>> > >>> iw dev wlan0 scan trigger > >>> iw dev wlan0 scan dump > >>> > >>> and grab the output for any AP of that network. Feel free to out > >>> the MAC address and the SSID, since they aren't the interesting part. > >>> What we want to know is a block like this: > >>> > >>> WPS: * Version: 1.0 > >>>* Wi-Fi Protected Setup State: 2 (Configured)
Re: WPA-PSK password length requirement
On Tue, 11 Dec 2012 12:53:58 -0600 Dan Williams wrote: > And these devices pass WiFi Alliance certification? Since this is against "golden" devices instead of against a rigorous spec it doesn't actually guarantee that compliance means "does what the spec says it should". -- Brian Morrison ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On 12/11/2012 01:53 PM, Dan Williams wrote: On Tue, 2012-12-11 at 13:17 -0500, Robert Moskowitz wrote: On 12/11/2012 10:02 AM, Dan Williams wrote: On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. First I was a major contributor to 802.11i and wrote the first paper on the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your typical end user having a complaint on client behaviour. Yesterday, I was at a major corporation for a meeting and the quest SSID had a 6 digit all numeric passcode. NM would not let me connect; it seem to insist that a passcode for WPA2-PSK be at least 8 characters long. The meeting participants using Windows had no difficulty with this 6 digit passcode and were able to get on the guest wireless network. If it's a 6 digit passcode, then it's not a valid WPA passphrase. Um, I helped write that section of 802.11i. Of course now it is just part of 802.11-2012: M.4 Suggested pass-phrase-to-PSK mapping The pass-phrase mapping defined in this subclause uses the PBKDF2 method from PKCS #5 v2.0 [B53]. PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256) Here, the following assumptions apply: — A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal characters. — Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal), inclusive. So, yes, we wrote the standard for 8-63 characters. But there are product out there that allow for smaller. Just bad implementations, but the real world. And these devices pass WiFi Alliance certification? Given who this company is, I suspect yes. I was just thinking; I can get the BSSID and that will give us the MAC manufacture which is probably the device manufacture :) But their security certification has always been weak to compliance. ICSAlabs put in a bit back in the days, but we lost out as all we were 'good' at was the security and did not have experience in RF certification. Dan If you're able to get a scan of that network, I'd be very curious to see what it's output is. It *may* be a WPS network, which is a method to set up a wifi connection somewhat like pairing a Bluetooth device. That allows all numeric PIN codes, and automatically determines the *actual* passphrase from a handshake that uses the PIN. Nope, as there is more involved to use WPS. That does not work well at all in a big office building in the meeting rooms in same. But for the 'fun' of it, I will try it with WPS. On any SSID I set up, I will use a reasonably strong passcode (though I would REALLY like to start using SAE in place of PSK!), but sometimes you have NO control over what others do. I REALLY need an override on the passcode length requirement; I will again be at that location for a meeting Dec 19. Excellent, can you run: iw dev wlan0 scan trigger iw dev wlan0 scan dump and grab the output for any AP of that network. Feel free to out the MAC address and the SSID, since they aren't the interesting part. What we want to know is a block like this: WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f * Manufacturer: NETGEAR, Inc. * Model: WNDR3400v2 * Model Number: WNDR3400v2 * Serial Number: 01 * Primary Device Type: 6-0050f204-1 * Device name: WNDR3400v2 * Config methods: Label * RF Bands: 0x3 Will do this. For connectivity at the next meeting, I am working on getting Hotspot working on my new Galaxy phone... Dan I doubt I will find a way to complain to this company's senior management on their IT department's 'bad' policy. This setup is probably only intended to keep rifraf from trying to get to the NEXT level of access control (you then need an 8 hour user account for hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On Tue, 2012-12-11 at 13:17 -0500, Robert Moskowitz wrote: > On 12/11/2012 10:02 AM, Dan Williams wrote: > > On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: > >> The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. > >> > >> First I was a major contributor to 802.11i and wrote the first paper on > >> the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your > >> typical end user having a complaint on client behaviour. > >> > >> Yesterday, I was at a major corporation for a meeting and the quest SSID > >> had a 6 digit all numeric passcode. NM would not let me connect; it > >> seem to insist that a passcode for WPA2-PSK be at least 8 characters > >> long. The meeting participants using Windows had no difficulty with > >> this 6 digit passcode and were able to get on the guest wireless network. > > If it's a 6 digit passcode, then it's not a valid WPA passphrase. > > Um, I helped write that section of 802.11i. Of course now it is just > part of 802.11-2012: > > M.4 Suggested pass-phrase-to-PSK mapping > > The pass-phrase mapping defined in this subclause uses the PBKDF2 method > from PKCS #5 v2.0 [B53]. > > PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256) > > Here, the following assumptions apply: > — A pass-phrase is a sequence of between 8 and 63 ASCII-encoded > characters. The limit of 63 comes > from the desire to distinguish between a pass-phrase and a PSK displayed > as 64 hexadecimal > characters. > — Each character in the pass-phrase must have an encoding in the range > of 32 to 126 (decimal), > inclusive. > > So, yes, we wrote the standard for 8-63 characters. But there are > product out there that allow for smaller. Just bad implementations, but > the real world. And these devices pass WiFi Alliance certification? Dan > > If you're able to get a scan of that network, I'd be very curious to see > > what it's output is. > > > > It *may* be a WPS network, which is a method to set up a wifi connection > > somewhat like pairing a Bluetooth device. That allows all numeric PIN > > codes, and automatically determines the *actual* passphrase from a > > handshake that uses the PIN. > > Nope, as there is more involved to use WPS. That does not work well at > all in a big office building in the meeting rooms in same. But for the > 'fun' of it, I will try it with WPS. > > > > >> On any SSID I set up, I will use a reasonably strong passcode (though I > >> would REALLY like to start using SAE in place of PSK!), but sometimes > >> you have NO control over what others do. I REALLY need an override on > >> the passcode length requirement; I will again be at that location for a > >> meeting Dec 19. > > Excellent, can you run: > > > > iw dev wlan0 scan trigger > > iw dev wlan0 scan dump > > > > and grab the output for any AP of that network. Feel free to out > > the MAC address and the SSID, since they aren't the interesting part. > > What we want to know is a block like this: > > > > WPS: * Version: 1.0 > > * Wi-Fi Protected Setup State: 2 (Configured) > > * Response Type: 3 (AP) > > * UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f > > * Manufacturer: NETGEAR, Inc. > > * Model: WNDR3400v2 > > * Model Number: WNDR3400v2 > > * Serial Number: 01 > > * Primary Device Type: 6-0050f204-1 > > * Device name: WNDR3400v2 > > * Config methods: Label > > * RF Bands: 0x3 > > Will do this. For connectivity at the next meeting, I am working on > getting Hotspot working on my new Galaxy phone... > > > > Dan > > > >> I doubt I will find a way to complain to this company's senior > >> management on their IT department's 'bad' policy. This setup is > >> probably only intended to keep rifraf from trying to get to the NEXT > >> level of access control (you then need an 8 hour user account for > >> hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On 12/11/2012 10:02 AM, Dan Williams wrote: On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. First I was a major contributor to 802.11i and wrote the first paper on the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your typical end user having a complaint on client behaviour. Yesterday, I was at a major corporation for a meeting and the quest SSID had a 6 digit all numeric passcode. NM would not let me connect; it seem to insist that a passcode for WPA2-PSK be at least 8 characters long. The meeting participants using Windows had no difficulty with this 6 digit passcode and were able to get on the guest wireless network. If it's a 6 digit passcode, then it's not a valid WPA passphrase. Um, I helped write that section of 802.11i. Of course now it is just part of 802.11-2012: M.4 Suggested pass-phrase-to-PSK mapping The pass-phrase mapping defined in this subclause uses the PBKDF2 method from PKCS #5 v2.0 [B53]. PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256) Here, the following assumptions apply: — A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal characters. — Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal), inclusive. So, yes, we wrote the standard for 8-63 characters. But there are product out there that allow for smaller. Just bad implementations, but the real world. If you're able to get a scan of that network, I'd be very curious to see what it's output is. It *may* be a WPS network, which is a method to set up a wifi connection somewhat like pairing a Bluetooth device. That allows all numeric PIN codes, and automatically determines the *actual* passphrase from a handshake that uses the PIN. Nope, as there is more involved to use WPS. That does not work well at all in a big office building in the meeting rooms in same. But for the 'fun' of it, I will try it with WPS. On any SSID I set up, I will use a reasonably strong passcode (though I would REALLY like to start using SAE in place of PSK!), but sometimes you have NO control over what others do. I REALLY need an override on the passcode length requirement; I will again be at that location for a meeting Dec 19. Excellent, can you run: iw dev wlan0 scan trigger iw dev wlan0 scan dump and grab the output for any AP of that network. Feel free to out the MAC address and the SSID, since they aren't the interesting part. What we want to know is a block like this: WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f * Manufacturer: NETGEAR, Inc. * Model: WNDR3400v2 * Model Number: WNDR3400v2 * Serial Number: 01 * Primary Device Type: 6-0050f204-1 * Device name: WNDR3400v2 * Config methods: Label * RF Bands: 0x3 Will do this. For connectivity at the next meeting, I am working on getting Hotspot working on my new Galaxy phone... Dan I doubt I will find a way to complain to this company's senior management on their IT department's 'bad' policy. This setup is probably only intended to keep rifraf from trying to get to the NEXT level of access control (you then need an 8 hour user account for hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: > The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. > > First I was a major contributor to 802.11i and wrote the first paper on > the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your > typical end user having a complaint on client behaviour. > > Yesterday, I was at a major corporation for a meeting and the quest SSID > had a 6 digit all numeric passcode. NM would not let me connect; it > seem to insist that a passcode for WPA2-PSK be at least 8 characters > long. The meeting participants using Windows had no difficulty with > this 6 digit passcode and were able to get on the guest wireless network. If it's a 6 digit passcode, then it's not a valid WPA passphrase. If you're able to get a scan of that network, I'd be very curious to see what it's output is. It *may* be a WPS network, which is a method to set up a wifi connection somewhat like pairing a Bluetooth device. That allows all numeric PIN codes, and automatically determines the *actual* passphrase from a handshake that uses the PIN. > On any SSID I set up, I will use a reasonably strong passcode (though I > would REALLY like to start using SAE in place of PSK!), but sometimes > you have NO control over what others do. I REALLY need an override on > the passcode length requirement; I will again be at that location for a > meeting Dec 19. Excellent, can you run: iw dev wlan0 scan trigger iw dev wlan0 scan dump and grab the output for any AP of that network. Feel free to out the MAC address and the SSID, since they aren't the interesting part. What we want to know is a block like this: WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f * Manufacturer: NETGEAR, Inc. * Model: WNDR3400v2 * Model Number: WNDR3400v2 * Serial Number: 01 * Primary Device Type: 6-0050f204-1 * Device name: WNDR3400v2 * Config methods: Label * RF Bands: 0x3 Dan > I doubt I will find a way to complain to this company's senior > management on their IT department's 'bad' policy. This setup is > probably only intended to keep rifraf from trying to get to the NEXT > level of access control (you then need an 8 hour user account for > hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. > > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list