RE: Feasibility of authentication without transcribing

Hi Lisa,

> For example, https://ecas.ec.europa.eu/cas/login?loginRequestId allows you to choose between a using a long password , their app with a pin, their app with a QR code (conferment alternative) mobile phone with sms, mobile phone with token (conferment alternative) , token (conferment alternative)

Ok, I’ve created an account there to try it and get the experience.

The first thing that occurs to me is that we need a registration exception, as it requires a long password, and a 4 digit pin to setup the mobile app, and/or an 8 character code for setting up SMS.

If you are signed out (or use a new browser, different computer etc) then you are required to sign in with your password before the mobile app works. I assume this is to prevent certain types of remote attack, as having a cookie in your browser from a previous successful login means you can start off semi-trusted.

However, it also means that this is not a conformant interface all the time (as I understand it). I assume you can change password via an email loop, but it won’t let me do that for another 24 hours (perhaps because it has just been setup?). These might be unusual circumstances, but they still count, it does not always conform to the SC.

The other part of feasibility is that the alternatives this example provides require either:


  *   Creating and maintaining a mobile app (presumably more than one, iOS & Android), which also needs to be very secure, well beyond most companies means.

  *   Paying for an SMS gateway, not to mention setting that up. However, SMS might not be considered secure enough for some uses anyway (once ‘best practice’ catches up with the reality of the open SMS protocol, see previous links).

  *   Having a back-end token infrastructure. I couldn’t see how to get that setup, but presumably the user needs to order one from the organisation. I also assume that needs to be a USB device that puts the number straight in, rather than you transcribing it?
NB: Once WebAuth is available this one probably isn’t needed anymore.

None of these are something you can require of every site with a login, they are reasonably large scale infrastructure projects.

That is reasonable for a cross-EU single sign-on, but just from our client base I can think of several charities and smaller organisations (e.g. who run forums) for whom this would be totally infeasible. Even for some larger organisations, this is the type of thing that doubles a project budget, rather than just adding a ‘little extra’ for accessibility.

Until the WebAuth API is available across several browsers and there are common, tested libraries available for websites to use (because you really don’t want to get login security wrong), I don’t think it is feasible.

I’m sorry. I get the need, and the solutions are not far off, but they are not ready yet.

On the other hand, I think the age of the password is coming to an end. There are enough hacks of sites (as Alex mentioned) that having trusted tokens (passwords) is becoming infeasible as a general strategy. Several companies are working on it, trying to rebalance the convenience vs security aspect of logins. I think market factors will swing this one anyway, we don’t need an accessibility criteria for it.

-Alastair

PS. I just noticed a huge hole in the exception: “Authentication process involves basic personal identification information to which the user has easy access, such as name, address, email address”
So if the authentication process includes your email address, it is ok to require a password?
Suggest for future:
“Authentication process can use basic personal identification information to which the user”