Re: WPA-PSK password length requirement

[Dan Williams <dcbw redhat com>]

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 XXXX 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.
> 
>