Fix 64 character WPA2 PSK password.

[BotoX]

See: https://github.com/esp8266/Arduino/issues/1921 and https://github.com/esp8266/Arduino/commit/1b8f6d2e8e2dc7008660732b96197fd1ae1a1439

[zgoda]

I've been there.

https://stackoverflow.com/a/21554182/12138

[slaff]

@BotoX Please, fix the issue that Codacy is reporting.

[slaff]

@zgoda @ADiea Any comments from your side before I merge this PR?

[zgoda]

This change does not fix any problem because there is still 63 characters limit in SDK for both AP and station. Did anybody made a test how the application on esp behaves if wifi has 64 characters passphrase? Will it connect at all?

[BotoX]

It works fine for me in station mode, my home network access point is using a 64 character passphrase. I did not try to create an access point on the ESP with 64 character passphrase however.

[zgoda]

Ok, none of my access points I have at home allows passphrases longer than 63 chars so I have no chance to test this.

[ADiea]

To me still not clear what happens here if you use the 64th position for passphrase and no space left for zero ending the string. Maybe the sdk has special way of reading from this array?

[zgoda]

Tape side A: ESP8266 core for Arduino gets this wrong, against IEEE 802.11 spec and against vendor published SDK. Tape side B: we want compatibility with ESP8266 core for Arduino.

My guess is SDK just copies array using memcpy, not string with strcpy - all implementations of PBKDF2 I know of use byte arrays, not strings so this assumption seems plausible. Things may work by accident for border case of 64 byte passphrase, until somebody decides to make string from byte array somewhere in AP software effectively replacing last byte with zero and then things will go boom. So as with all network related programming I'd go traditional route of "be relaxed when receiving and strict when sending". If my assumption about SDK is right then SDK does this exactly.