Devthought

This post has a twofold goal. Make users aware of the implications of non-secure login forms is one. The other and most important one, given the nature of this blog’s audience, is make website makers and webmasters aware of this problem, and how easy they can solve it.

I’ll also examine the alternative of implementing OpenID as the sole login provider of a website, and how it becomes the most suitable option for the majority of scenarios today.

An introduction

In this article we’ll consider a login form or website non-secure when sensitive data (for example, but not limited to, emails, passwords, private messages, credit cards information) is transmitted across a digital network without a strong encryption mechanism in place. In the majority of cases, this means transmitting data from one end to the other in Plaintext, using the HTTP protocol instead of HTTPS.

A reality check: for users

One of the first concerns for users of non-secure websites should be network sniffing. With an utility such as Wireshark (formerly known as ethereal), an attacker can easily intercept and read packages that contain plaintext data.

This could be anything from chat conversations, or that password you’re sending to a non-SSL site. When you sign up for a website that doesn’t implement https remember to use a new, unique and discardable password. Never use the same password more than once!

A reality check: for webmasters

With open wireless telecommunication becoming more popular every day, network eavesdropping gets easier and more appealing for attackers. Websites that do not protect their users data will become easy targets for electronic identity theft and other opportunistic crimes.

Most login forms we find today offer no SSL support for sensitive data transmissions. Just browse to your favorite startup or Twitter mashup to see how much they protect your information. Even extremely popular websites such as Digg, Slashdot, StumbleUpon, Hi5, Reddit, Justin.TV, Washington Post, Forbes, Xanga fail to protect your authentication information.

All it takes to fix your login forms is to add support for the HTTPS protocol to your web server of choice. Most popular web hosting providers already support it, yet few people take advantage of it.

One of the reasons people are reluctant to build-in SSL is the requirement of a certificate signed by a trusted authority. But it’s a really small price, that pays back with a lot of benefits for your organization.

The JavaScript alternative

You can make your non-secure forms a little more secure by creating a SHA1 hash before the form is sent, instead of sending the plaintext password.

However, this technique, which is implemented by vBulletin for example, has its downsides:

• Only makes it more secure for Javascript-enabled user agents
• It’s not an encryption method, so it’ll only be useful for login forms, and not for emails, private messages, credit cards, etc

The OpenID Alternative

The OpenID Authentication 2.0 specification takes into consideration the security threats described previously, and the suggested solution is evident:

While the protocol does not require SSL be used, its use is strongly RECOMMENDED. Current best practices dictate that an OP SHOULD use SSL, with a certificate signed by a trusted authority, to secure its Endpoint URL as well as the interactions with the end user’s User-Agent.

While it’s clear that SSL is optional in the authentication transactions, the following sentence is of interest to us:

Following its own security policies, a Relying Party MAY choose to not complete, or even begin, a transaction if SSL is not being correctly used at these various endpoints.

If OpenID is implemented, it’s almost guaranteed for the website owner that the user’s login information will be protected. The main reason is that the majority of popular OpenID providers respect the security considerations listed in the specification. The attacker can still intercept authentication data if you don’t have SSL in the callback page that OpenId forwards the user to, but all he could potentially get is a random token and not the password itself.

Conclusion

The potential security issues of websites form authentication are varied, and encryption is only a tiny part of the solution. Securing users login should be one of the top priorities in web makers agendas. People value the data and history they’ve created in the websites they like, and it can be pretty disappointing to lose it all because the creator decided it was worth investing more time in refining the website’s gradient backgrounds rather than implementing SSL.