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.

- 3 comments by 1 or more people Not publicly viewable

  1. I suppose you could change it so in the same way banks use where by you only enter particular characters of your password, this would help avoid any keylogging software – at least in the short term and then just make sure that the passwords are changed often or after a certain number of logins or something (though dunno how practical this would be obviously) as I know changing passwords is a pain.

    09 Mar 2006, 20:59

  2. There's a difference in approach between the kind of access-based authentication that is appropriate for most current systems at warwick, and the transaction-based authentication for which "variable security" works well. Banks in Germany use this "variable" security as a kind of two-factor auth, you can log in to your account with a password but to make significant changes or transfer money you need a one-time "TAN" code that they give you a sheet full of.

    I think that two-factor authentication is the way that things will go. I've seen smart cards used in a large corporate computing environment, and it really works. The downside is that you need smartcard readers on all your hardware…
    The token generators seem to work well as well, I've not used one myself but they seem to be a good way to allow two-factor auth from anywhere. I'm not sure that they're that expensive, I believe that they are credit-card sized now…

    09 Mar 2006, 22:22

  3. Gareth

    I read this with interest especially the SMail & forced password changing parts. SMail uses your NDS password but it is not single sign on which is very frustrating for student use. If you are in a work area machine and want to write on your blog or forums and check your email you have to enter your password three times (even if you can do this in 2 or 3 minutes).

    Additionally, for students who want to quickly check their email on a work area machine quickly, you have to enter your password twice. To make the computers become available as quickly as possible, it would be great if the 'Logon Script' also automatically logged you into the Warwick Web resources and saving you having to enter it in again. Not only would this speed up how long it takes to check your email but is far more secure. With the way the work area machines have been set up for students, it would be very easy to get a key logger to obtain a students logon and password as 95% of students check their email first. Also, if the only time you have to enter your password is on the work area login, this is secure from key loggers. This was a problem we had at school.

    It is also not uncommon for students to share their passwords when doing group project work or laboratory work as there are no central file storage areas to support this hence making passwords secure until they are shared. Here students have documents and data files in excess of 10mb as these canít be shared easily via email. Additionally, passwords are also shared amongst students during vacations if one student doesn't have internet access at home and is away from university for three months over the summer and they need to check if anything of urgency has arrived. It is much easier to phone up your friend than trying to find a computer at the local library.

    Also, being forced to change your password is great but as it was seen recently you have to be notified about this when you log into a web resource otherwise passwords have to be reset. If this was to be implemented, the password reset would need to be available online 24/7 but have to be a bit more high tech than Date of Birth and university number. I would also recommend that a kiosk where your university card can be swiped needs to be available in the Student work areas. The recent problem with compromised passwords was one example where due to the queues, students started sharing passwords because they needed to access resources which were protected but couldnít because their passwords had expired. Not turning up for a lecture with the lecture notes already printed was something students didnít want to do.

    Just my thoughts on the issue.

    10 Mar 2006, 10:23

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

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