The Diablog™

You really should wrap that rascal.

For years, the closed padlock on our web browsers has identified when our data transmissions over the Internet are "secure." Every time you enter a login and password on the internet you should look for the same security.

By now, we all know the “safe” way to transmit sensitive data over the internet is via such secure pages encrypted using the HTTPS protocol (Wikipedia definition of HTTPS protocol). Cautious on-line shoppers check to be sure a page is secure before entering ecommerce data into a form. It's a good thing, too. Encryption of this nature is done at the "transport" layer which means that data is "wrapped" within an envelope into which others on the same network cannot see. Just as you wouldn't want to receive your credit card statement each month on a big post card, you've learned you should not post sensitive information without HTTPS because it is the equivilant of mailing a message without an envelope.

Most internet users have login credentials to many, many websites today. Many of these websites have little or nothing to do with ecommerce, and may include webmail, blog tools, forums, wikis, group sites, and content management systems. Every time you enter your login and password, you should first check to see that you are doing so over an HTTPS (secure) transaction. Why?

Consider the many places where we work today. Perhaps you check your mail or update your blog using a laptop at Starbucks. Maybe you login to a web application using your iPhone or other smart phone. And even our home broadband networks place us on a common network. If you are authenticating with remote services on such open networks without encryption, you're essentially putting your login and password on a post card and passing it around the room. There may not be financial data at risk, but do you really want someone elso knowing how to gain access to your email, blog, or website?

There's really no need for the risk. All it takes is a dedicated IP address and a cert. A certificate from a Certificate Authority (such as GeoTrust or Verisign) is appropriate for websites that require authentication for public visitors as such certificates provide reassurance that the server is who it presents itself to be. However, if the only users logging into a website are internal users, low-cost certificates or self-signed certificates are quite sufficient.

Developers should take the initiative to spread the word that credentialed access to any website should be secure. Additionally developers should ensure that all communication with a site authenticate securely, including ftp and telnet over ssh. Play it safe, wrap that rascal in HTTPS or the equivalent.

We're firm believers in security. Dialogs ships with automatic login redirects to an HTTPS connection for users trying to authenticate from a non-encripted page, and every Dialogs website we've provisioned in our own data center for years has had a dedicated IP address and a certificate to permit HTTPS communications.