Security

Secure backup using rsync and SSH

I just found this article in my unpublished posts… not sure why I didn’t publish it, but there we go.

How to automatically back up your computers with rsync – Lifehacker

I saw this article pop up in google reader on Thursday, and realised that it was actually a pretty good idea. My DreamHost account comes with 200GiB of disk space and 2TiB of bandwidth. Additionally, these both grow in size every week by 1GiB and 16GiB respectively, so I’m hardly even losing data by backing stuff up. You’ll also need some kind of linux server that you can upload to, you may want to consider creating a DreamHost account.

Unfortunately, it’s not really as easy as it looks if you use Windows. I wanted to back up the My Documents folder, which as you might be aware, is a “special folder” (along with My Music, Shared Documents, etc.). Special folders will contain a file called desktop.ini that contains information about the folder (its name and icon, for example). However, according to KB326549, Windows likes to do something a little… unorthodox with the folder permissions – Windows will only look for the desktop.ini file if the folder is marked as read-only. Actually setting the folder as read-only, though, doesn’t actually make the folder read-only: in its infinite wisdom, Windows typically ignores the flag.

So, you might be thinking: “Why does that matter?” right now. Well, in order to run rsync, you will need to install Cygwin, which is (more or less) something that lets you compile unix programs and run them on Windows. Before you run away at the mention of the word “compile”, don’t worry – Cygwin comes with many programs pre-compiled for you, rsync and ssh included. You can get Cygwin here. I think it’s a pretty handy way of backing my stuff up.

RFID tags

Prompted by: InfoWorld Video | InfoWorld | RSA IOActive

While I was aware of this issue before now, the video in the article prompted me to write something. As I’m also procrastinating, it seems like a good idea to me.

RFID tags are the bits inside those cool little cards or dongles that you can wave at a reader to let you into a building. They’re widely used on campus, and I’ve also seen them used in the more modern apartment buildings for the main door. Unfortunately, these aren’t quite as secure as everyone would like to think. The video shows a compact sniffer device that can be used to record the signal that an RFID tag sends out, then replicate it at a later point, alowing them to impersonate you.

Obviously, this situation could easily be resolved by having a challenge-response system: both the system and the card know the card’s “password” – the number that’s is hard-coded into it, the reader sends out a challenge string, the card encrypts the challenge with the password and transmits the result, the reader checks the result against the expected answer, and access is either granted or denied. Simple… unfortunately, not so.

In the majority of cases, the RFID tag is passive, meaning that it does not have its own power source, it gets its power from the signal it receives from the reader. Thus, it is difficult to integrate the encryption hardware without increasing power requirements. Other methods include a rolling response – the response changes with each access – and many others. Hopefully, though, we see one coming into mainstream usage soon, as I don’t think it will be long until these devices become readily available.

RSS with HTTP authentication

For those of you not familiar with RSS, I’ll describe it briefly; RSS is a particular format of XML document that is often used by sites to provide a “news feed” to subscribers, this news feed can then be read by an RSS feed aggregator, and new items on the site can easily be disseminated to describers.

HTTP, as most will recognise as the protocol we use to fetch resources when we browse the web, has some rudimentary built-in authentication facilities, and although the idea of using these with RSS is not new, it surprises me that the technique is not more widely used.

Advantages of using authentication with RSS feeds provide several possible applications: firstly, it allows sites to provide “members-only” content; secondly, it allows users of a site to select content based on their interests (provided the site had such functionality); thirdly, and of more import to sites than to users, it would allow targeted advertising to be delivered to users.

The easiest way to implement authenticated HTTP would be to respond with a 200 response upon receipt of either correct auth data, or no auth data. In the latter case, the server would send out the public RSS feed; in the latter, the server would obviously send out the private version. In the case of incorrect auth data being provided, the server responds with a 401 response, just like any other authenticated transaction.

The downside to the above method is that the user won’t be made aware if a personalised service is available. If we slightly fudge the meaning of the 401 response, we can do the following: on recepit of either incorrect auth data, or no auth data, the server responds with a 401, and the body of the document contains the public version of the feed. When the server receives correct auth data, the server sends the personalised data with a 200 response.

In this manner, the client knows if a personalised version is available, because it knows that it sent no auth data, but feed data has been received. Furthermore, it knows if personalisation is not available, since it will just receive the 200 reply if it doesn’t send any auth data.

I’m sure there are other methods of providing the same service, these just strike me as the most intuitive that don’t require separate URLs for subscribers and non-subscribers.