Tuesday Top Tip - Slow Password Hashing

Like Slow Cooking, Slow Password hashing seems to be in vogue at the moment, using hashing algorithms such as bcrypt or PBKDF2. Troy Hunt has a mega in-depth look at the subject on his blog,  with an emphasis on asp.net. This comes after recent incidents such as with LinkedIn and eHarmony.

So the general recommendation would seem to be that for new projects you should consider using a slow password hashing algorithm to protect your users' passwords. I say "consider using" because there is a performance overhead associated with using these approaches which you need to be aware of.

However.....

It's also worth remembering that if you end up in a situation where you are praying that a slow hashing algorithm will protect passwords and save you, then you have other BIGGER problems.

To get at your well hashed passwords in the first place, an attacker will likely have hacked your database anyway and gotten at the other information held in the database: names, addresses etc. This is the bigger issue. Somehow, hackers get access to the LinkedIn password table in the first place.

So before embarking on a major exercise to introduce slow password hashing, it's worth spending time ensuring that the baddies can't get at the password table in the first place. 

Useful Links

• Troy Hunt: Our password hashing has no clothes  
• 365 days of Slow Cooking
• BBC:LinkedIn passwords leaked by hackers
• CNET: Analysis: eHarmony had several password security fails

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

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

Data Deletion and DFDs

The Information Commissioner's Office (ICO) in the UK just handed out a £325,000 fine to  Brighton and Sussex University Hospitals NHS Trust after decommissioned hard drives were sold on eBay. Basically drives containing very sensitive information which were meant to have been destroyed, somehow found their way onto eBay. The NHS trust is appealing the decision.

When creating your Data Flow Diagrams (DFDs) you should also think about secure deletion of data from devices when they have reached the end of their life. In addition to asking how data is stored on devices, you should also ask what happens to these devices (hard drives etc.) when they have reached the end of their life.

Make sure to have proper procedures in place to prevent this kind of thing happening.



Useful Links

• ICO hands out biggest ever fine to 'surprised' NHS Trust 
• ICO Notice (PDF)

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