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.