Markanjio (atys)
Well, client haves "Edit Account" button and that one worked for me. At first glance it leads to this URL.You can still login to the billing account with your old password and change both your password and email there.
Yep, HTTPS should be used (and forced) for the forum, but also for the API, the game login-system (yes, it uses HTTP), etc.
No, HTTPS isn't crap. A properly configured HTTP server will protect the communication in a very effective way. The only "bad" thing about it is inherent to the X.509 certificates which have to be trusted by CAs (which is a problem);
DNS security is crap as well. It is not going to work. Think about one simple fact: we can't stop use of classic DNS in foreseeable future. This means MITM can try to downgrade it to "usual" DNS and hijack it. I do not see how you can completely prevent it without breaking compatibility with classic DNS or app-level hacks with some a priori knowledge. Not to mention DNS is centralised (==easy to hijack if you've got some power).
And then any CA can issue certificate for literally anything. Some CAs were already abusing this fact by issuing wildcard certificates to sniff SSL traffic by intrusion detection systems and authorities. Then there were some hackers (ComodoHacker, etc). Theoretically app can remember fingerprint of certificate used to talk to server before and alert user if it changes. Yet very few apps implement this technique. Not even browsers. I only seen it in Pidgin. Which is noteworthy, but its literally single program on the planet I've seen which actually cares about unexpected changes to server certificate.
So basically IMO you can't expect adequate security from SSL or TLS if you're average Joe or app dev who want "secure connection". And thinking you're secure when you're not is really bad. However, sending password as clear text over air, etc could be even worse. And while you can implement something better in game client, it's not like if you can fix all browsers on the planet. So yep, we have this crap and it is not easy to fix.
That's a problem from crypt(3) with DES: it considers only the first 8 bytes of the password.