your session has expired: the sorry state of web session timeouts

I used to work in a team managing an authentication infrastructure.  It was based on Kerberos.  We went with the default session length of 10 hours.  The idea behind this default was: it's long enough for a work day including breaks, plus a bit.  When stuff stops working because the user has been logged out, they are free to log in again if they really want, but maybe they also appreciate the reminder, that it's time to go home.

The world of web site timeouts, for online banking, or anything finance related, is different.  It's a race to the bottom.  How quickly can you kick someone off the service, and still have them sometimes to achieve the thing they logged in to do?  Because it might not be them!  So better limit the time the not-them has to do stuff.  Or maybe the them lets a not-them take over their session part way through.  So better log them out just in case.

This is all the wrong approach to authentication.  Authentication should give a strong guarantee between two parties, that they are dealing with the other party for real.  Once that is established, it is destructive to start second-guessing it, and deciding that actually it's no good.

Imagine going for a meeting at a business's invitation.  You show id at reception.  You meet your counterpart and go to a meeting room.  Then, every 300 seconds, your counterpart decides to treat you like a stranger again, calling security, and kicking you out.  Why do things online in the equivalent way?

One reason is the custodian liability problem.  Financial services are done as custodian services.  If the custodian releases the assets they're looking after to the wrong party, are they liable?  Reasonably, that could depend on what led to it.  In a workable world, an authentication procedure is designed with a clear division of the responsibilities between the parties, and a trail is recorded at each authentication, and during service use, so that the cause of any bogus authentications can probably be established.  If the user lost control of their device, or exposed their credentials, they have to take the loss.  If it was the custodian service provider's fault, they are liable.

The current world is nothing like that.  Authentication processes are ridiculous from the outset.  No one has control of their own devices.  To the nearest percent, zero percent of people have control of their own smartphones, because that's how they're designed.  To the nearest percent, either zero or one percent of people have control of their own laptop and desktop computers.  You can't build anything on this base, except shitfrastructure.

If a customer gives their logged-in laptop to someone else, and the someone else accesses a logged-in session to steal something, and the session was 25 minutes old at the time, there is going to be a lawyer who argues it.  Never mind that it was the customer's fault: the question will be "would this have been able to happen if the timeout was 15 minutes"?  Well, would it?  And so on, then, all the way to just above zero.

The "logic" is unstoppable.  The only way to have sensible custodian service timeouts is with enabling regulation clearly delineating responsibilities, and therefore liability, and disallowing lawyery arguments like the above.  But that would have to use a strong technical basis for authentication, and the world lacks that.  As well, the world won't be getting that.  So we will continue to live in a world of very short timeouts for anything custodian.

 

Bad timeouts are, of course, just a small part of the much bigger problem of bad authentication.