Spread Betting Websites and Security Controls

Summary

Should spread betting websites be using two factor authentication and shorter session timeouts?

Background

The spread betting company, Spreadex, recently sued a customer in a London court for £50,000 which the customer had lost through trades in Spreadex. The customer claimed that the transactions had been made by his girlfriend's young son. The boy had access to the laptop to play games over a number of days, and seems to have initiated the transactions which caused the losses.

Interestingly, the court found for the customer on the basis that he couldn't be expected to read through all the pages of terms and conditions and, thus, the contract was unfair. We'll see if Spreadex appeals.

The Security Angle

However from a security perspective it throws up a number of interesting issues.

The first point to make is that spread betting websites involves money. As the court case shows, a customer can make or lose a significant amount of money on the website. When hard cash is involved, you really need to think about the security mechanisms.  This applies to both the punter and the website.

The consumer needs to be careful about the environment where he uses the application. If he uses the PC to make bets worth thousands of pounds then you have to question whether the PC can also be used as a general toy.

Website Security

But the focus of this blog is on website security. Given the value and classification of data that spread betting sites process then the types of security controls build into the application are important. So here are a number of thoughts:

Is single factor authentication sufficient to protect these financial transactions? Most online banking websites use some form of two-factor authentication to authorise transactions. Like online banks, the spread betting application involves significant transactions. Should they not consider using two factor authentication also? No doubt this would be an expensive undertaking and could well be overkill. Another option would be forcing the user to reenter their password when a transaction is initiated. This would probably have prevented this incident.

Timeouts are also an important security mechanism. After a period of inactivity the application session should timeout. The next time the customer uses the application, he should be forced to logon again. Absolute timeouts force a session to terminate after a defined period of time, regardless of whether the user has been active or not. Could shorter timeouts have helped in this situation?

Now, these type of security mechanisms hit directly into the usability/security conundrum. The more security controls you have, the more user unfriendly the application  becomes. So it can be a difficult balancing act.

Bottom line is that you need to consider your security requirements at the start of any development project. A threat analysis should not only cover direct threats against your application, but  also cover threats which happen on the end-user environment.

Useful Links:

• The Register: Online bookie can't scoop £50k losses made by 5-year-old 
• Metro: Boy, 5, made £50,000 loss on spread-betting website

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot