All entries for March 2006

March 30, 2006

Password resets in NDS

One of the simplest aspects of increasing security of user accounts and passwords is allowing people to easily and securely change their password whenever they want.

I would not be surprised if the majority of people never changed any passwords once they have been set. In this day and age with everyone registering for so many websites, how you can keep up with regular password changes. Most people just don't see the point, they figure their password is already secure and why would anyone want to hack their account anyway?

As I've mentioned before, we don't quite have Single Sign On at the University because there are still a few places that don't tie into our central NDS LDAP directory. However, for most people that NDS password does cover a lot of things. This is good…and bad. If that password gets compromised then the attacker is going to get into a lot of things. But, if you've only got one password to remember, there would be less resistence to changing it.

At the moment you have to login to our Novell Portal (Insite) to change your password on the web (you can also change it on the managed desktop or via the service desk). However, a lot of people login via the SSO screen that secures things like SiteBuilder, Forums, Blogs, etc… If we had a change password gadget there then it would be much more visible and easy for users to change. Question is…how to do it? Our handy friends at WBS helped us out there with a chunk of code that they use.

env.put("", user);
env.put("", pass);
LdapContext ldapContext = (LdapContext) getLdapCtxFactory().getInitialContext((Hashtable) env);

ModificationItem removeItem = new ModificationItem(DirContext.REMOVE_ATTRIBUTE,new BasicAttribute("userPassword",pass));
ModificationItem replaceItem = new ModificationItem(DirContext.ADD_ATTRIBUTE,new BasicAttribute("userPassword",newPassword));

ldapContext.modifyAttributes(user,new ModificationItem[] {removeItem,replaceItem});

The trick is that you have to bind as the user who is changing their password and then you must do a remove of the password attribute followed by adding the attribute back again (you can't just do a replace). This works a treat, but it only allows users to change their passwords when they already know them. It does not provide a "I've forgotten my password" facility. This is a lot harder as it means that some web app must have admin access to everyones passwords…so for now we are holding off on that one, but it is something that would be very valuable in the future as I can only imagine how many service desk calls a year we get about forgotten passwords.

Update: Having just looked at our service desk call logging system (HEAT), I see that in the last 2 weeks of term 12% of service desk calls were about forgotten passwords in some shape or form. Obviously an online password reset/forgotten password service would not get all of these, you would hope it could significantly reduce the workload of the service desk.

March 22, 2006

Client side woes

I spend most of my time programming server side stuff and don't really have to spend long knocking out a bit of HTML/CSS here and there.

However, we have recently got a bit more adventurous in terms of what we do on the client side so I've had to spend a bit more time on that side of things. My most recent and fiddly job was doing a nice DHTML/AJAX user and group finder for SiteBuilder (our CMS).

We have recently had designed a lovely new look and feel for the editing side of SiteBuilder2. One of the first screens for a proper make over is the permissions screen. Part of that is getting this new user and group picker working. Traditionally we did this with a good old fashioned popup window and javascript to populate the fields back again.

SiteBuilder Permissions screen

Now with our emphasis on smoother client side operations, I've done it with AJAX and a floating DHTML window.

SiteBuilder Permissions screen with AJAX

The popup is still a bit ugly as it's awaiting a new skin, but it functions well. However, my journey to this point has been a painful one.

  1. Getting my head around the Prototype library has taken a while, but now I have, I am pretty pleased with it
  2. Getting the CSS working for this popup when it can be positioned either above or below the little icon depending on what screen you're on and positioning arrows is nasty nasty work
  3. My crappy windows Apache 1.3 has been rubbish lately and complaining lots about (Resource deadlock avoided: mod_rewrite: failed to lock file descriptor) so I've finally upgraded to Apache 2 and all is well again
  4. I've moaned for ages about how hard it is to debug CSS problems in IE, but have just discovered that they do in fact have quite a nice DOM inspector very similar to the Firefox one. IE Developer Toolbar although you can't actually edit CSS live with it :(
  5. It is harder than it should be to do AJAX within AJAX. By this I mean that the popup has 4 tabs, each of which is loaded on demand from a different server side controller. Then, on 2 of those tabs, there is a search which shows results in a "find as you type" kind of way in another AJAX results box beneath the search boxes. Phew…nasty. The problem is the way javascript functions are registered with the browser, you have to pre-register all your javascript functions in the main page and can only call functions from returned AJAX content but can't create new functions :(

However, all the above trials were overcome and we now have quite a neat little user and group picker so that our users can really easily assign permissions to individual users or groups of users as defined in our WebGroups system. Yay for us.

March 16, 2006

Alliance & Leicester online banking

Follow-up to Is one password enough with Single Sign On? from Kieran's blog

Interestingly, just after writing about different levels of security, my bank has gone and changed their online banking system.

Alliance & Leicester online banking demos

They have put in two new measures.

1) The first measure is to be a bit more sure that you are who you say you are when logging in. The first time you register, the take a look at what they call "Your computer characteristics" (basically probably your IP address and browser agent). They then use this to let you in with just a customer number and PIN from known computers, but ask you something else like your mother maiden name or place of birth as another security question before letting you in.

2) The second measure is to let the customer know for sure what site they are logging into. This is for people who fall for the fake bank emails they get. Basically, the first time you register you are shown a random, but distinctive image and are asked to enter a phrase as well. These are then show to you after you enter your customer id but before you enter your PIN. The idea being that if you login and don't recognise your own image and passphrase, then don't enter your final PIN as you might be on a fake site. To be honest I'm not sure how much this is going to help as the kind of people who fall for these fake emails and sites are probably also fooled by something like just saying. "Your previous image has no expired, please pick a new image and pass phrase." Oh well.

March 09, 2006

Is one password enough with Single Sign On?

When you login to your managed desktop machine, SiteBuilder, Warwick Blogs or any number of university systems, chances are that you will are using a single username and password. And that's great most of the time.

Using Warwick's Novel Directory Server (NDS) as the master source for people's usernames and passwords means that we can authenticate to lots of stuff from this single secure source. Not everything uses this one username and password as your GroupWise/SMail/Unix logins can have different passwords.

Single password vs Multiple passwords.

  • Only one password to remember, making you more likely to make it complex and hard to guess
  • Having just one password for everything makes it less hassle to change a bad/compromised/old password without having to worry about which systems this particular password is for
  • One central system for logging authentication activity, making it easier to spot and challenge suspicious activity


  • That one super secure password gets stolen and everything is open for abuse, not just one or two systems
  • All it takes is one place where you need to login insecurely and all your secure logins are vulnerable

We have recently started moving every online login from lots of individual screens within each web application to a system whereby everyone just gets redirected off to a centralised login screen. We can then concentrate on making this one place more secure rather than worrying about all the little places where people try to do authentication.

Along the theme of the problem of losing that one secure password is the idea of temporary credentials or varying levels of security depending on the activity trying to be performed or the behaviour of the user who is trying to login.

For a number of years companies have been using token generators to authenticate people. These are basically hardware devices that generate a one-off key that can prove your identity. Unfortunately these are expensive and could easily be lost or stolen.

Another method that some banks are talking about using (I'm not sure if they already have got these methods deployed) variable security. Let's say you were logging into Warwick Blogs first thing in the morning and were doing it from your residences room. SSO might check your IP against your login history and if you enter your username and password at your usual typing speed/style then it'll let you straight in. However, if you later in the day went to view a page in SiteBuilder, you'd still be logged in and all would be fine. However, if you then went to change your student records in some way, we might decide to request stronger authentication. At this stage you'd get prompted for your password again and also an extra PIN or perhaps the name of your first school.

This solution means you still just have one password, but also have some additional data that you'd get asked for when doing sensitive activities or if you were logging in from say a different country…or rather a hacker was trying to login as you from another country.

In the context of Warwick Blogs you might want to subscribe to an RSS feed. Unfortunately we do not provide a local RSS reading application that respects permissions. So if your RSS feed contains a few restricted entries, you'd not see them in a public RSS feed that got read by somewhere like bloglines. You could use HTTP Basic Auth over SSL to authenticate with your username and password to get that feed. However, that would mean leaving your one and only password in some untrusted external application. It might be nice in this case if we could generate you a temporary password that you could use that would only work for this service and would in no way compromise your main password.

Anyway…this is all just random off the top of my head stuff. It may well be that these features are overkill, but as more and more is done over the web at Warwick we need to make sure we know who's doing it.

March 01, 2006

Case Network Start

Writing about web page

I follow Jeremy Smith's blog quite closely as the IT people at CASE are quite similar to us at Warwick. They have got quite a lot of interesting systems such as blogs and wikis and SSO, etc…

Jeremy recently linked to their Start page which is a central page that provides links to services and aggregations from various services. It is basically a portal at the end of the day but a nice one :)

This is just the kind of thing we could/should have at Warwick as they have also obviously recently got into the whole new wave of Javascript/DHTML/Ajax as you can edit the layout of the portal with nice drag and drop effects. Of course how you edit these things is not what's important.

What is important is that we now have enough content from many different sources at Warwick that we can start making these kind of portal pages useful. When my.insite first appeared we just didn't have the content to make it much more than a useful entry point for file storage and email. We now have lots and lots of great services and content that ITS and others have built over the last 2 or 3 years. I don't think my.insite is the right place for these services, but there has to be an easier way to help our users find all this great stuff than just trawling through the quite boring and text heavy ITS website.

When we did the publicty for Warwick Blogs we got the word out really well, but there is no really easy way for staff and students to get information about all of our services in a similar way. Of course we can't do big publicity campaigns for everything, but we could do just one more big push for a great central aggregator and link page (we could call that a portal I guess).

March 2006

Mo Tu We Th Fr Sa Su
Feb |  Today  | Apr
      1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31      


Search this blog

Most recent comments

  • One thing that was glossed over is that if you use Spring, there is a filter you can put in your XML… by Mathew Mannion on this entry
  • You are my hero. by Mathew Mannion on this entry
  • And may all your chickens come home to roost – in a nice fluffy organic, non–supermarket farmed kind… by Julie Moreton on this entry
  • Good luck I hope that you enjoy the new job! by on this entry
  • Good luck Kieran. :) by on this entry


Not signed in
Sign in

Powered by BlogBuilder