Redhatter’s Web Blog

I just had a rather amusing email… two in fact, come right out of the blue. Not from a relative or friend… but from a webapp.

A few years ago, I developed a very simple and crude webapp called LANPlanner. It was dodgy, it had lots of rough edges, it was coded in about 15 minutes flat in PHP and MySQL… I suspect there are probably some SQL injection bugs somewhere in it, as I was still quite a novice at that time.

Just a moment ago, I got the following email (names censored to protect the guilty)

Date: Sun, 25 Mar 2007 23:14:33 +1000
Subject: Daily Confirmation Status for event "Bradley Lan"
To: user@host.com.au
From: LanPlanner Service at localhost
Cc: XXXX@longlandclan.hopto.org (my email address)

Hi Some One,
This is the current RSVP status for "Bradley Lan".

-------------------- Confirmed as comming:

-------------------- Unconfirmed:

- Some One  is bringing 1 person/people.  (09:52 remaining to confirm)
- Some One  is bringing 1 person/people.  (09:59 remaining to confirm)

I’m amased there are people still using this webapp. E.T. phone home indeed.

Hi All…

I know many of you are in the web development and security arenas… I figured I’d throw this idea up for everyone to have a look at.

Authenticating users on a website can be quite a challenge at times.  Sometimes, HTTP Basic authentication is all that’s required, re-sending the password with each request.  But the problem with this; is that someone can intercept the username and password, thus knows everything needed to establish a new session.

HTTP Digest authentication is good; but MD5 isn’t as strong as other hashing algorithms available, and more importantly, it assumes the server knows the exact password.  But what if you’re hashing the password?  Also, this doesn’t necessarily solve the issue of session hijacking.

Thus what I have come up with, is “Challenge-Response Digest Authentication”.  My rationale for this method of authentication and session management is as follows:

1. Remove the need for the cleartext password to be stored or transmitted.  Using CRDA, only the hash of the password needs to be stored.
2. The remote user still needs to demonstrate knowledge of the password (or rather, its hash)
3. Various aspects of the client, such as the IP address and user agent, are used when generating the hash, making session hijacking more difficult.

So, how does this actually work?  Well, in a web application scenario, it requires JavaScript on the client side to implement the hashing algorithm (in my case, I’ve settled on SHA1).  The initial authentication phase works as follows:

1. Remote client makes a request to log in by requesting the login form.
2. The server generates a session ID, which is the hash of the following (in this order):
   • IP Address of client (from the server’s perspective)
   • Client User Agent
   • A random salt string
3. The server responds by sending back the requested form; Included on the page in the JavaScript code, are values for a random salt and the IP address of the client.  A cookie containing the session ID could also be included — or on more advanced clients, could be determined by the client.
4. On submitting the form, client side JavaScript takes the information provided, and generates a hash of the following data (in this order):
   • IP Address of client
   • User Agent in use
   • The random salt given
   • The username
   • The hash of the password

   The cookie generated earlier is passed back to the server as well so it can look up the salt value.

5. The server receives the session ID (via cookie) as well as the username and response (via HTTP POST), looks up the salt for that session ID, then checks the following:
   • The session ID is valid for the given IP and user agent
   • The response is valid

If successful, the server generates a random nonce value, and passes this back to the client.  The session key to be used from this point forward, is the hash of the following information:

• IP Address
• User Agent
• Random Salt
• Nonce value

The nonce is then updated at regular intervals.  On an intelligent client, the raw nonce value could be passed back right at the start, and stored — the client incrementing it when told by the server.  On a simpler client, the key may get passed back and forward.

For each request after this initial authentication step, a cookie should be passed to the server containing the following string: “SessionID:SessionKey”.

Anyways… those are my ideas.  I know there are problems with this; most notably, is the effectiveness of hashing when you hash something twice.  I know that SHA1 is less effective in this instance — but the question is, how much less effective?  I figure it’s not really enough to be worried about, but then again, I know there are people who work in this field, and thus will know more about it than me.

I’m still tinkering at this stage, I’ve got a small proof-of-concept webapp going that utilises this scheme at a basic level, and I’ll keep poking at it for now, but I’d be interested in hearing other people’s thoughts on whether this would be effective against preventing session hijacking and keeping a site secure.

Financial types wonder why we simple folk find the stock market confusing… Well… it’s little wonder when organisations like Kitco make confusing statements like this…

Hmmm… yes fellas, make up your minds.

Hi,

As promised, some stages compiled for MIPS-I have been released.  These stages should be appropriate for almost all little-endian MIPS hardware equipped with a decent amount of memory (128MB or more).  This should make things a little easier for those wishing to install Gentoo on MIPS32 hardware such as AMD Alchemy development boards.

Note, anything kernel or bootloader related, we can’t help with.  It’s assumed you know what you’re doing as far as actually preparing a bootable kernel and configuring your firmware to boot Gentoo.

Next on the list, is to look into µClibc stages for Cobalt — which will hopefully be used to produce updated netboot images for Cobalt.  So yeah, I’ve been absent for the last week or so, de-stressing and getting uni sorted out.  In short, it’s all system’s go now.

Hi All…

At the moment, stresses are running high.  Exactly why, I’m not sure, but it seems everyone is on edge.  And I don’t just mean the Gentoo Development community — I mean elsewhere too.  Everyone seems to be edgy for reasons I cannot fathom.

I’m not going to speculate about what could be causing this stress… I know in my case, the tense atmosphere has had an impact.  I’m nowhere near the point of doing anything irrational like suicide (I know this will create more problems than it will solve), but I am noticing that I’m not in my usual “stable” mental state.  I think in my case, there are a few factors in play…

• At university, I’m doing a subject entitled “Core Project Initiation”, which heavily depends on groupwork.  We have to form groups of 5 people or so, choose a project, find a project supervisor (typically other lecturers at QUT), then work towards implementing a prototype.  The first assessment item, is due this Friday, and more or less requires the group to be formed.  After having two attempts at forming a group fail, I’ve been in contact with the lecturers and am in urgent need to get into a group.  Basically, if by Wednesday, I’m not in a group — I’ll pull out of the subject, it’s just not going to be viable for me to continue.
• Last semester was rather stressful, having had two major stuffups by the university (in one case, a lost exam paper; in a second, a breech of examination procedure), and winding up failing a telecommunications subject for seemingly unknown reasons.  A total lack of feedback was a big factor — there was nothing to suggest I was offtrack, yet, I got a 2 (7-point scale) as my grade for the subject in question.
• I’m still looking around for work.  I’m quite conscious that I’m basically living out of my father’s back pocket — have been for some time now.  This has been playing on my mind a lot lately.  I know that without any work, I can forget passing my degree, I can forget moving out of home at some point.  And luxuries like attending LCA2008 are definitely out of the question.  I’ve applied to several positions over the last few months without success.
• The weather has been rather hot and humid lately, enough to shorten the fuses of most people.  Add to that the fact that Brisbane (like much of Australia) is in drought, and that the dam levels are dropping to alarmingly low levels.
• Then there’s the censorship debate that’s been raging on for the past fortnight on both gentoo-dev and gentoo-core.

Some of these problems are aggrivated by communications issues stemming from my Asperger’s Syndrome.  Stress is not something I handle well, with depression being quite common in such circumstances.  I’m in the happy position that I haven’t needed any medication to keep things under control however — I intend to keep things that way if I can.  Right now, I’ve just detected abnormalities in my behaviour, and thus know something is up.
At this point, I’m certainly not planning on resigning from Gentoo.  My builds for MIPS1 (little endian) are progressing, having just started Stage 2 this evening.  There’s no major issues to deal with at this time, and I hope to have these out soon.  I’ve also picked a fight with µClibc trying to bash out updated stages — managed to mess something up rather badly there, but I’ll hopefully get that straightened out and have some netboot images for you.

Presently, I’ve got stuff in my personal life that needs my attention first.  Thus, I’ll be “away” for the next fortnight whilst things settle down locally.  I’ll be contactable by email, and may be on IRC sporadically — but I don’t expect to be doing a hell of a lot.  I need some time to reduce some of the external pressure, get myself mentally ontrack again.  Hopefully when I return, not only will things have calmed down around here, but people within Gentoo, and perhaps others globally, might have settled down too.

In short, I’ll be around, just laying low for a while.