Re: WPA-PSK password length requirement

[Dan Williams <dcbw redhat com>]

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