2. Only in the UTF-32 encoding, which no one uses, are all characters represented by 4 bytes.
Most sites today use UTF-8 where most characters on a standard keyboard are 1 byte, and almost all characters from any language take 3 bytes.
3. Even 19 characters is a lot better than 12.
If that kind of hashing algorithm is a must, why not use first X bytes of the password input?
My point is that throwing a "password too long" error, especially for 32 characters or less, feels like a wrong approach to me; no matter the circumstances or the amount of backward compatibility that has to be kept.
I assume “problematic” here means “difficult but possible”. If problems arise then I guess it’s a matter of priorities; but I think that not inconveniencing the user with password length limits should be high priority.
https://en.wikipedia.org/wiki/LM_hash
Save-ya-a-click: basically what jfrunyon describes, along with a whole lot of other insecurity goodness (and to be fair, LANMan was a long time ago).