Approaches to improving mobile authentication

One of the aims of the MACON project was to develop a bookmarklet that would allow users to authenticate securely without having to enter their full Open University password every time they wanted to access a mobile e-resource.

OU students are asked to choose a password containing at least eight characters, with a combination of upper and lower case letters, numbers and keyboard symbols such as @ # $ % ^ & * ( ) _ +.  These passwords can be difficult to enter on small touchscreen keypads because

  • there is a higher chance of selecting the wrong key and the characters that have been typed are hidden, so you may not realise you’ve missed a key
  • the numbers and symbols are on second or third layers of keyboard which can make some symbols more difficult to find

To make authentication easier we had hoped to allow mobile users to register a PIN against their normal username and password, but after investigating various methods of doing this and the associated risks we found that it couldn’t be done without either storing credentials on the mobile device, which would contravene our licence agreements, or storing credentials in a database which could leave users vulnerable to password theft.

Part of the problem is that the Open University (OU) doesn’t support an authentication API as it is not considered sufficiently secure so the only way to log in is through the existing web interface.

The project team also considered creating a secondary EZproxy® instance which would allow users to authenticate through a character field with a requirement to enter specific characters from a dynamically generated grid (in a similar manner to the OU’s VPN) plus a PIN.

In future we hope that the university will provide an app which will allow users to sign in once to use all Open University mobile websites or apps in the same way that signing in to their student portal (or the intranet for staff) currently allows them to access all OU systems on a PC.

Image showing mobile resources list

OU library mobile resources page

The compromise we reached for the project is to provide a list of all the databases we subscribe to which have mobile web interfaces using EZproxy links. This means that when library users open a link they are prompted to authenticate through the OU’s login page before being redirected to the selected database site. As we use single sign on this prevents them being asked for Athens or Shibboleth credentials which they don’t know. The EZproxy links can be bookmarked so that users don’t have to go through the library website to reach their preferred database.

About Keren Mills

Macon project manager (@mirya on Twitter)
This entry was posted in Mobile bookmarklet tool and tagged . Bookmark the permalink.

2 Responses to Approaches to improving mobile authentication

  1. Caleb Racey says:

    Interesting approach. I’d never heard of password storing on the client device invalidating licence agreements. Most software (disappointingly) doesn’t care about strength of authentication, I’m assuming it must be for ejournals and/or SaaS services? Even when we specifically prevented password storing on web login people could (and did) get round it with their own javascript password auto fill in. We have kerberos based single sign on to shibboleth (i.e. SPNEGO single sign on) for desktop users. For mobile users we allow password saving (via mobile client detection) for the shibboleth login servers on the device. We are happy to chat about it if you find the approach interesting

  2. Keren Mills says:

    Thanks for your comments Caleb. I don’t know the details of our licence agreements, but I was advised by our Content and Licencing team that storing credentials on the device is prohibited. I imagine our students do allow their browsers to store their passwords, but we can’t actively encourage them to do so.
    We use single sign on so users only ever need to know their university username and password. For access to library resources we’re still primarily using Athens rather than Shibboleth, although the users never know their Athens credentials. We’d definitely be interested to hear more about your approach.

Comments are closed.