Nothing Is Secure By Default

My recent experiences in setting up another server and site have served as a reminder that, on the net, it seems like nothing is secure by default. FTP sends your credentials over the wire in plain text. Telnet, of course, isn’t secure for the same reasons. Most ISP mail providers don’t use SSL or secure authentication for their POP3/IMAP connections, which, again, means that your login credentials are insecure. Some web content management systems (like Drupal, by default) don’t deal with passwords in a non-SSL environment as securely as they should. (Using a challenge-response authentication mechanism is better than nothing, if you can’t use SSL.) Web publishing protocols like the Blogger, WordPress, and other APIs tend to send your password over the wire as plain text, as well — and if you’re using a connection such as a public wifi hotspot, you are definitely vulnerable. (It looks like the Atom Publishing Protocol may help resolve this issue, but this isn’t a viable option yet.)

Now, thankfully, there are secure alternatives for most of the activities described in the last paragraph. For example, you can use FTPS or SFTP to transfer files securely, or SSH as a replacement for Telnet (and as a way to tunnel almost anything securely). You can find plugins for insecure content management systems to make them more secure, or simply administer them via HTTPS.

However, when you don’t control the server-side of the equation, your options may be limited. My mail account with my ISP, for example, can only be accessed securely via their web mail interface — they don’t appear to support any of the standard POP3/IMAP security mechanisms, which is disappointing.

The most unfortunate thing about this situation is that you need to go to quite a bit of trouble to set all of these secure alternatives up, and it’s more effort than most users will put up with. It’s also not obvious that things are insecure in many cases — while web users are probably used to the “lock” graphic indicating a secure web page, there’s no similar convention for other programs like FTP and e-mail clients, and no warnings about insecure transfers. Unfortunately, it’s going to take some kind of massive industry-wide effort to really effect any change or move to secure protocols. The insecure defaults are deeply entrenched — so much so that it would be really difficult to get people to “fix” something that, to them, isn’t “broken.”

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.