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

Tuesday Top Tip - EU Cookie Directive Deadline in the UK Fast Approaching

If you are in the UK, you have four days to become (finally) compliant with the EU cookie directive. The (real) deadline is May 26th 2012. A year ago, the Information Commissioner gave you a year to comply. So what to do?

Approach 1 - Information Commissioner's Office - ICO

A relatively simple approach is to copy the approach taken by the Information Commissioner's office (ICO) itself. Go to the ICO  website and you will see the following at the top of the page.

You can click on the "I accept cookies..." button to accept cookies. If you don't click, each time you go to the site you will see that message. If you do click, then you won't see it again.

Approach 2 - BT

A more comprehensive approach comes from BT. When you go to the BT website, you will be prompted with the following window

 

If you click on the Change settings, you are presented with the following which allows you to set the level of cookies that you will accept using a drag bar. You then choose Save and Close.

So those are two approaches. The ICO one is more simple and might be easier to implement in the short term. The BT approach is more elegant but would take longer to implement.


Useful Links

• ICO Website 
• ICO Cookie Guidance
• BT Website
• Wall Street Journal: U.K. Cookie Crackdown Begins
• The Register: ICO: Managed to comply with Cookies Law? Go help the other kids 

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

Tuesday Top Tip - John Melton's Year of Security (for Java)

If you haven't come across it yet, you should head over and have a look at John Melton's Year of Security For Java series. Each week he covers a different security topic.

While the series is aimed at Java, a lot of the entries so far are general and apply to any environment.

Useful Links

• Year of Security For Java 

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

Tuesday Top Tip - Qualys SSL Labs

If you are configuring SSL on your website or online application (and you should be these days), use the resources over at Qualys SSL Labs.

The SSL/TLS Deployment Best Practices gives good advice. Read this before your purchase your SSL certificate and follow its advice. For example, it talks about how to use SSL properly in your application design, what key length to use etc.

What I particularly like is the SSL Server Test facility. After you have configured your SSL certificate, go to the SSL Server Test page.  Enter your URL in the Domain Name field (but make sure to check the "Do not show the results on the boards" box). Click the Submit button and SSL Server Test will analyze your SSL configuration.

This takes a few minutes, but will give you a result. You should be looking to get an A. It will tell you of any problems in your SSL configuration. Fix those and resubmit.

Keep repeating until SSL Server Test gives you an A....and then you can feel smug.

Useful Qualys Links:

• Qualys SSL Labs 
• SSL TLS Deployment Best Practices (PDF)
• SSL Server Test

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

Tuesday Top Tip and SSL

Another Tuesday Top Tip.

If you say in your privacy policy or statement that the security of your users is of the highest importance;  that you will meet and exceed all security best practices, legislative requirements and any other "good security thing" that you can think off, can you at least make sure that you use SSL.

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

Tuesday Top Tip - Penetration Testing

Most companies use application penetration testing towards the end of the development life cycle in order to identify security vulnerabilities. This can be a problem - especially if you had not thought about security earlier in the development process.

What do you do if the pen test throws up major security issues?

If it's late in the development cycle, then these issues will be expensive to address. So you are more inclined to ignore them. That could leave you vulnerable.

Have you been in a position where a serious SQL injection vulnerability has been discovered two days before product launch? What to do? You know it would have been fairly simple to address if it had been discovered a lot earlier - but now it's not so simple.

So here are some Tuesday Top Tips:

1. You should think of application pen testing as a way to confirm that all your planned security measures have been implemented properly during the earlier development phases.
2. Try to do some pen testing as early as possible in the development. If you discover issues, they should be less expensive to address - and you can integrate the lessons learned into the rest of the development.

All this assumes that you have integrated security into the development lifecycle.

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