Vnc does this too with it's 8 characters. Stupid design decision.

Even more stupid though is their declaration that encryption is 'out of scope' and anyone wanting it should arrange it out of band (eg VPN or SSH forwarding). Seriously... :/

Well, given their track history, they are very correct on their recommendation to allow localhost connections only and tunnel any traffic through ssh. I mean, would you trust them to enforce the security of their server?

(It would be better if they only allowed pipeline connections and actually required that you run the data through ssh. But I bet they didn't notice people have all kinds of untrusted software running on localhost.)

I agree with that recommendation (it's absolutely not advisable to expose it to the internet even if it were encrypted) but that's where defense in depth comes in.

It's not supposed to be the only level of security but using unencrypted protocols in this day and age for something as sensitive as server control is unforgivable.

For example tunneling through SSH does make it possible for other people to sniff the traffic on either side if they are on localhost. Port forwarding is not a very safe tech since it doesn't allow to limit which user uses the port.

I do respect people that say "I don't know how and don't want to learn how to solve this hard problem, so I'm letting it explicitly unsolved", as long as that "explicitly" is part is real.

And yeah, I would probably use vnc if the protocol was over a pipeline, like scp or rsync. As it is now, it's a program to avoid.

Defense in depth is only useful for vulnerabilities that you can't solve to a satisfactory level. You should be able to publish a high-quality access server on the internet without any loss of security.

Paypal did the silent truncation to me at 20 characters once, what a nightmare. I can't even remember how I figured it out, probably some other poor soul left a breadcrumb for me.