Django User Group London Meeting

I attended yesterday’s DJUGL meeting, held at the Guardian in London. The evening consisted of three presentations with gaps for discussions and consumption of free beer and pizza. Entry was free and open to all with an interest in making Django better, though registration was strongly advised as the venue was almost full. The best way to find out more about upcoming meetings is probably through the London Django User Group Google newsgroup or the London Python Twitter stream.

The talks were quite inspiring. Nicholas Tollervey’s FluidDB talk had quite an interesting concept, though the company seemed to be at an early start-up phase and I will probably wait to see how it progresses before making my apps feed data to them. Toby White’s Solr talk was an insight into the techniques used by companies that have masses of data the wrangle into searchable formats. The Celery/RabbitMQ talk by Mat Clayton was the most familiar subject to me as I’d read articles on Celery before. It included some practical tips and lessons from their infrastructure experience. I can definately see how implementing a queuing system like this would be beneficial for parts of my apps that have to send emails and communicate with public web APIs.

Security measures for protecting web accounts

I though I would write some notes on website security today – specifically for account logins. So many sites these days require some sort of login. Even if there is no facility for users to register, most will require some sort of admin interface to a CMS for maintenance.

The dictionary/brute force attack is the simplest way somebody would try to gain access, and once they’ve gained access to your admin privileged account, they can do almost unrestricted amounts of damage. Once a cracker found the login page to your site they could quickly write a script which repeatedly enters usernames and passwords and submits the form. A script like this could make many attempts per seconds and will eventually get the correct combination, provided they do not get blocked in some way.

There are however a number of ways you can make it harder for a attacks to happen to your sites and your users.

Choosing safe passwords

Most brute force attack scripts will start off by going through the dictionary or a list of commonly used passwords (e.g. ‘password’, ’12345′, ‘letmein’, ‘querty’, ‘liverpool’ , more). Your admin password should use a combination of letters, numbers and symbols even if you can’t make your users do the same.

Obscuring the admin account

Use an obscure username for your admin account. Most web administration systems will initially create a user called ‘admin’ or ‘root’ with full access rights. A cracker will know this and will start off trying various passwords against the admin user account. Removing the default admin user or renaming it to something else will make the attempts useless – at least for a lot longer until they start trying other usernames.

Limiting login attempts

Limit the number of login attempts someone is allowed in a certain period of time. Surprisingly, many web login systems do not implement any such security. The principal is simple, when a predefined number of failed attempts have been attempted from a single IP address in a predefined period of time, further attempts are ignored. This works because it seriously slows down crackers so that, for example, instead of hundreds of attempts per minute, they are only allowed three.

You should check whether your current systems implement this feature. If you use a popular framework, somebody has probably already already written a plug-in, module or patch to fix this.

SSL/TLS encryption

Use SSL/TLS to encrypt the form data (HTTPS) There are many occasions, where a man-in-the-middle (MITM) attack could be performed to listen in on the username and password data you send when you log in to a web form. This is especially a risk if you are using public wi-fi or an internet connection in a hotel or cyber-cafe. This is very easy for the attacker to do if the connection is unencrypted. If you enable SSL/TLS on your webserver and the web form is submitting to a URL beginning with ‘https://’, it will be next to impossible for the attacker to gain the username or password.

The unfortunate issue with getting this set up is that the server requires a certificate to be installed. You can generate one of these yourself (self-signed), however, as it will not be signed by a certificate authority (CA) that browser manufacturers trust, your users will probably be put off by a big warning message.

The problem is that a certificate is doing two things – enabling encryption security and proving that a website belongs to who they say it does. We just want the security aspect, but you have to have both. You have to make the decision on whether your visitors are savvy enough to trust the certificate, or whether you pay for a trusted certificate. There are projects such as CAcert [http://www.cacert.org/] that are trying to get accepted as a trusted CA whilst signing your certificates for free. However, until they are supported in every major browser, I have decided to go ahead and purchase one. Thankfully they are a lot cheaper than they used to be, but it pays to shop around and also check the list of supported browsers. Some can be bought for around £15.

There is one other reason for not using self-signed certificates and why users should not blindly accept these when they visit. Since your CA in unknown, a man in the middle could watch out for unknown CAs and auto-generate another certificate on-the-fly then pass it on to the user. If the user accepted this certificate, the data would be encrypted to the MITM, then the MITM would re-encrypt it to the server, leaving the user unaware of anything unusual. For this reason I would suggest only using a self-signed certificate if you and your users’ browsers are setup to trust the correct certificate at the start, then you would be notified if it has been changed in between. You will probably want to generate a self-signed certificate with an expiry date very far into the future if you are going to use this approach.

Phishing attacks

Phishing is an alternative way for an attacker to gain access. It’s really hard to protect your users from phishing attacks but you should learn how to avoid falling into the trap yourself.

If your site becomes popular, it is likely scammers will duplicate your login page and host it on their server where it will collect all username/password combinations entered. They will then send out emails to your users telling them they need to log in for some reason or another, including a link to their cloned login page.

Users should be warned not to ever click links in emails and/or inspect domain/subdomains, but this requires some technical knowledge. Once a user tries to enter their login details, the scammer can now access their account for malicious purposes. Among the most serious of these attacks are the ones that pose as your online bank or building society.

If you are a site administrator, it is likely that scammers have created pages that look like all of the standard website maintenance panels. Imagine, you received an email that appeared to be from someone who maintains your server, telling you that you need to change your password. Would you blindly click the link and log in?

All change

OK, so I’ve neglected the blog a bit recently but hopefully I can be excused. I had three weeks of exams for my final year at University of Essex and dissertation presentation before that. The exams were over almost two weeks ago now and since then I have catching up with other work and starting a few of my own projects I have been thinking about lately.

I have been gennerally been working on the way I integrate websites for customers in future, and making my source code for web applications more structured and re-usable. There are several useful segments of code I have written over the years and I feel it would be beneficial to make them more generic so they can be added to new projects more easily and extended.

The management system I developed a few years ago for the family business website http://courchevel-1650.com has proven to be successfull and new features have been developed regularly. The system handles all the areas associated with renting out property to holiday makers, such as storing customer details, managing availability, updating the website and printing letters. With a proven system like this that does so much, I’m sure other businesses could make use of it so am making it more generic.

Aside from these I have several other ideas in the pipeline inspired from courses I took in ‘Image Processing’ and ‘Further Concepts in Databases’ but you’ll have to wait for further details at a later date. I also feel the urge to contribute source code to a few open source projects so expect to see developments in this area in future.

Easter vacation

Well, it’s the end of spring term at uni now and I’m back for the holiday staying with parents. The past few months have been pretty busy with assignments and dissertation (which I’ll post about at a later date). Here’s a list of what I’ll be up to until I return to uni for my final term.

• Keep an eye out for jobs.
• Work on my ‘Mobile Robots’ coursework, which involves programming Aria/Pioneer robots to manoeuvre a course with sensors.
• Prepare my presentation to demonstrate my dissertation project next term.
• Revise some course material for exams.
• Carry out some restoration work on Bertie (the Rover Mini shared my Jayne and myself).
• Get a week of snowboarding action in Courchevel, France.

I’ll probably be blogging about several of these, so stay tuned!