I was fortunate in the early days of FanConcert development to have ready-to-use login and authentication code for Ruby on Rails called the Salted Hash Login Generator.

At the time I wasn't comfortable enough with Ruby or Rails to attempt that sort of thing, yet it's one of the first pieces of code a personalized website like FanConcert needs to function. I'm grateful for this code but I think it's time to move on from it.

Another side benefit of using that pre-made login code is that usability weakness are obvious from the feedback I've been getting. I'm going to attack these points in this blog post, as well as go over the general login and authentication situation on FanConcert. From now on I'll refer to login and authentication as just "login".

When looking at authentication and calculating risk, it's good to examine worst case scenarios. In the event of a full security breach on FanConcert, how severe will the break-in be? What kind of information will be revealed?

FanConcert will not be storing credit card numbers for recurring subscription payments, for example. A third-party service like PayPal, which has a pretty good security reputation, could handle that. Most of the information on FanConcert will be personal, like the users first and last name (which are optional) and the user's global location.

I don't see any reason why FanConcert would need to store full addresses (right now it's only as specific as city) but users could enter extremely accurate GPS latitude and longitude values to describe their locations. In some situations this could easily reveal the user's exact address (a house) but others not quite so easily (an apartment).

Even taking that into consideration, I see the consequences of full disclosure of a user's information to be relatively moderate. There could also be other sensitive personal information in users' profiles or preferences in the future that could change this.

The choice of security measures is based on not only the consequences of disclosure but the threat of an attack. Together they give an idea of the possible risk that the site may be attacked.

The threat of an attack can be based on the attractiveness of the target. People could target a website for financial gain or just to disrupt a popular site. FanConcert is neither popular nor can be exploited for financial gain, other than maybe free access to the site.

When and if FanConcert operates as a web service, higher security may be needed to ensure that users cannot use the web service more frequently than they have paid for, or that the site cannot be attacked and the exploited for free data.

Passwords are not stored on FanConcert, only a hash of the password. When you enter your password to log in, that password is hashed as well and compared against the stored hashed password to determine if they match. Not even I can see people's passwords when I browse the database, only the hashed passwords.

Yes, these hashes can be broken by methods such as brute force calculation. The amount of calculation required to break it depends on the number of bytes in the hashed values. When the benefit of a FanConcert break-in is so low, why would anyone go to the trouble? Still, it's an aspect of the overall risk I need to keep in mind.

FanConcert does not use a secure connection for passwords, like SSL, so passwords are sent "in the clear" on the back of an HTTP POST. For that reason it would obviously be vulnerable to people snooping on the connection. Some investigation into SSL and https:// would be prudent.

Given that the overall risk seems relatviely low, a hashed-password/session/cookie-based approach like the one I'm presently using seems to be enough security for now. The main problems concern the usability of the login portion of FanConcert.

Geez, where to start with the problems of FanConcert's current login system? I found the Salted Hash Login Generator produced rather ugly pages, rife with spelling mistakes and usability problems. The good news is that the code appears to be technically sound and well unit-tested. It's a good starting point for some iterative improvements.

I need to remove the dependency on the translation library completely. Given that FanConcert will use a custom approach to translation, the dependency on an unnecessary library (and others it in turn depends on) only serves to complicate the login code, especially in the views where every translatable title or phrase is a method call to a helper function off in another file.

I need to fix the confirmation email problems. First of all, it's not obvious that users must confirm their account before they can log in. I've added an FAQ entry to FanConcert's sign in page but I can do a better job conveying that.

The confirmation email is important so that malicious users can't 1) open many accounts at once and 2) can't open more than one account with the same email address. It's rudamentary but it prevents some basic problems. More can be done here to prevent mass signups, including the use of captcha tests, which are becoming more common on the web.

A big problem with the confirmation email is that the URL is long and sometimes breaks over two lines depending on the email client. This is an absolutely unnecessary and inexcusable usability problem and should be fixed.

Another problem is that some web email providers think the confirmation email is junk mail. I can't do much about this but I can tell the user to check their junk email folder for the confirmation email.

However that doesn't help if the email is filtered out completely and deleted and not included in their junk mail folder. Some FanConcert users have reported not receiving confirmation emails at all, and I suspect this is what has happened. A user should be able to ask FanConcert to resend the confirmation email, though that won't help if it's just filtered out again.

Travis pointed out that I can make it easier to change forgotten passwords by allowing security questions such as "what is your mother's maiden name?". Currently the only way to recover a forgotten password is to have an email sent to you, which provides a link with a hash in its querystring to change your password. Because the old password is stored as a hashed value, it's not possible to send the user their existing password so they must change it.

Security questions, if made poorly, can be a security risk for users but there are two factors that make me feel better about them: firstly, as I mentioned above there is little to lose in the event of a break-in and secondly, the user makes his own security questions and should take some responsibility for their quality. If a user makes a security question that is easy for other people to answer, that is largely their own fault. Should I allow that or make the user select from a list of questions I think are more secure? It's a fair question, I've seen both approaches used on the web.

The user's login should be remembered between sessions for a fixed period, like two weeks. This is a common usability feature and again, is reasonable based on the fact that the consequences of disclosure are low. This was actually working on FanConcert until I started using the database to store session values, at which point it broke. I'm still investigating why.

To accomplish that feature, a key is stored as a browser cookie and when the user returns to FanConcert the key is used to authenticate the user instead of having them log in again. Any user with this cookie key could impersonate another user but that requires access to the cookie and therefor the machine it is stored on. Again, this is the type of security users should be expected to take some responsibility for -- but I could warn people about the dangers and provide an option on login NOT to remember the password between sessions, a common feature of web-based email.

Other improvements include consistency of terminology (pick either "log in" or "sign in" and stick to it), readable URLs, good overall usability, navigation, attractiveness and integration with the rest of the site.

Login will also be indirectly connected to the subscription payment system but only in terms of where the user can navigate to and what functions are available to them. I'm pretty sure they will remain relatively uncoupled. Payment is a whole other ball of yarn!