I don't think is necessarily the case. You can take security seriously, but there are limits, and you have to balance the effort with the willingness of someone breaching your safeguards.
I would use a bicycle as an example. You can buy whatever lock you want, it can be broken by someone. The better the lock, the less people can get through it or are less inclined to do so anyway. You can pay a security guard to look after your bike, but at some point, if your bicycle is really valuable, one guard can be bribed (or killed), and so on, and so on.
In summary, just because they were "hacked" does not mean they are not taking security seriously.
Back then, when they enforced a maximum 16 character password, I saw enough security. Are they storing them in plaintext or what? Btw, I think they increased the limit to 32 now
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).
To some extent though it does mean they were not taking security seriously _enough_. In your example, they misjudged whether they needed a guard or not.
[EDIT] Actually, I realized it's not about taking it seriously, but executing it efficiently.
It appears that the only companies capable of being secure are Google and Apple. Aside them everyone is getting hacked every other day.
Companies that torch through millions of dollars of VC money need a nice ransomeware kick in the ass to set up a MongoDB password, and will proactively ignore S3 warnings to not make something public, so what do you expect?
Of course you can make your employees' lives worse by siloing them off, enforcing all sorts of security policies and so on. It's just not worth it in this case. So the source code of some video games got leaked... big deal. What are hackers going to do with it, make their own version of Battlefield and FIFA? Write snarky comments on how crappy the code is? Maybe they'll develop cheats, but that can also be done without the source code.
Whitelisting also won't protect you from exploits in the software itself. If some non-technical user gets compromised and starts sending out malicious PDFs, you better make sure every single installation of Acrobat is up-to-date. If you get hit by a 0-day in Outlook - good luck.
Now perhaps in this case people were just sloppy, but again, if you want to rule out exfiltration of data - as opposed to just making it less likely - you need a completely different approach and it'll cost you.