Re: WPA2 password problem

[Stuart Gathman <stuart gathman org>]

On 09/17/2010 04:27 AM, Marc Herbert wrote:
>    
> > My current paranoid theory is that the M$ setup CD configures the
> > WPA2 with a binary key, derived from the passphrase by a proprietary
> > password hash that only Windows uses.  In several days of googling
> > this problem, I've seen several claims that M$ has 2 password hashes
> > that it tries with WPA2 (thus enabling Windows to also work with
> > standard APs).  M$ had an excuse for that with WEP, since it hadn't
> > been standardized yet, but not with WPA2.
> >      
> Interesting... It should be possible to prove this "two hash
> functions" theory from packet captures: some of them should show TWO
> connection attempts, the first attempt _failing_ with the mismatched
> hash function. Note that I said "some captures": the first hash
> function tried by Windows could well be the correct one by chance and
> then you will not see anything unusual. Then you need to capture
> against the other AP style.
>
> Another way to prove this two hash functions theory would be to try
> and fail to decrypt traffic with your problematic AP. Aircrack-ng has
> normally zero problem decrypting a WPA capture as long as: 1. you give
> it the key, and 2. the capture includes the initial handshake. So
> seeing aircrack-ng fail would strongly support your theory. Warning: this
> tool has a lot of quirks, so first make sure you can make it work on
> your system by decrypting at least _another_, non-problematic WPA
> capture.
>
> Please keep us updated.
>
> Note: as a lesser sin, maybe Windows just implemented some hash before
> the WPA standard was completed and then left it there. Just a wild
> guess...
>    
I didn't see this in time, and now I have to reset the unit and 
configure through web interface so it works.  However, the setup CD 
reproduces the Windows only key.