OFFICIAL NEWS

Well, client haves "Edit Account" button and that one worked for me. At first glance it leads to this URL.
Not sure it should be forced but at least it should be offered by default to minimize leaks due to sniffing in networks (especially open wi-fi).
The problem is really multi-fold. First of all, SSL and TLS are horribly over-engineered, use ton of legacy crap and offer load of options (including insecure stuff). This makes libs complicated. This makes APIs complicated. This makes usage complicated. As the result it is really hard to use SSL or TLS properly. This dooms us to face countless bugs in libs. Heartbleed being most famous ofc and it should not exist here in 1st place. Not even as bug in lib, but as protocol feature. Overcomplicated protocol doomed to have ton of implementation bugs. Then there is legacy stuff, different lib defaults and so on. Do you know what encryption algo is being used when you call lib do do SSL for you? Ahh, it requires some extra expertise in area? While most app devs can't distinguish des from rc4. Now you can guess how secure it would be in practice. Half of "secured" programs using SSL do not even bother self to check certificate fingerprint and if it changed since last time and ignore all errors. Needless to say, MITM can just replace cert and nobody will notice anything half of time. You'll have "secure" connection ... to wrong server.

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.
crypt() password scheme is ancient/defective. Linux and most BSDs moved away to better password schemes ages ago. IMO best thing you can try as password hashing these days is something like scrypt or Catena. Catena can be interesting as hash because it can require client to do relatively heavy proof-of-work computation without forcing server to do the same. This way hash is resource heavy to bruteforce (both over network and locally), parallel bruteforce turns out to be memory hog/asic unfriendly, however, server can quickly check if client's response is valid or not as it only does last phase in split computation. Local bruteforce takes both computations and so you can't quickly bruteforce password -> hash match. User would not mind 1 second delay at login. However bruteforce speed = 1 password per second could make h@x0rz unhappy about it :)