A look into sessions and security

“Final” Part: Eternal sessions of the clueless user

Er Galvao Abbott
The White Hat ElePHPant
4 min readAug 4, 2017

--

In the fourth article of this series we talked about how to use a score-based approach to minimize false occurrences. Now it’s time to talk about… time.

Before we begin: A bit of history on eternal sessions

It’s no secret that companies like Google, Facebook and Twitter (just to name a few) are trend setters in the industry, for better or for worse.
A long time ago, trend setting companies changed the security landscape drastically by introducing/popularizing two concepts:

  1. The extinction of the username: The e-mail address, a public, well known detail about the user, began to be used as a user’s identity (More on this on a future article);
  2. What I call “eternal session”, but is often referred as “permanent session” or “one-time authentication”: Once you authenticate to the application on a device you never have to do it again.

Let me be clear: There’s absolutely no problem with either idea per se. Our industry should — as often as possible — try out new concepts, open the dialogue, debate pros and cons and then decide wether or not to adopt them. The problem is our industry seems to always rush to the adoption part as quickly as possible, often ignoring any of those pesky, time consuming intermediary steps.

Some companies resisted/still reist the idea (the first case I remember being Yahoo!, which at the time used 14-day sessions, which while not perfect is still better than “forever”), but the problem remains. Since making the user comfortable is the goal here (more on this below), the “Industry Giants”, the ones the user deals with every day, perpetuate the practice.

The problem with eternal sessions

The main problem with eternal sessions is, simply put, that they tie a user to a device. This might seem logical, since the user do own the device in question, but the issue comes when someone else gains control of the device.

What makes the issue so complicated is that it involves much more human aspects than technological ones:

  1. The issue is often explored on infidelity/privacy anecdotes and jokes, which frequently lead to the terrible concept of “why worrying if you have nothing to hide”;
  2. A foul use of someone else’s device is often perceived as improbable or easily fixed;
  3. The potential damage of a hijacked device is often dismissed as minimal;
  4. The ever so common concept that the user must be as comfortable as possible, no matter the risks;
  5. The “solution” (in-my-never-humble-opinion) requiring time, dedication, patience and effort, values that are more and more rare nowadays.

But… What about 2FA or <insert-your-solution-here>?

Of course there’s nothing wrong with 2FA, quite the opposite: everyone should use it and I strongly promote it as anyone involved in the security scenario should, but I believe the problem runs deeper than that.

Also, 2FA is one more “lock to be picked”, one more technological solution that, while strong and praised, doesn’t treat the “real problem”, so to speak.

Let’s talk about a solution

In my point of view the problem is, once again, centered on human issues, such as habits — which are always hard to change — and mainly education. Security is not only a serious issue, it’s something every segment of the industry should be informed about and focused on improving. Contrary to this idea, though, the userbase of an application is usually the segment which is left in the dark.

We assume our users want comfort and ease of use over anything else, but we don’t ask and we don’t offer them anything to clarify this assumption, no choice, no information. It’s like we’re saying to them “Here: assume our company is savvy enough to keep you safe”. Problem is no one talks about how much this trust that we demand of our userbase is affected with security-related issues being portrayed by the media almost on a daily basis. The only lesson a user may learn is that maybe we’re not that savvy; maybe there’s something deeply wrong; maybe we shouldn’t be trusted so blindly. How could we expect them to learn anything else if we don’t make any effort to teach them anything else?

We must stop infantilizing our userbase. They need to be educated and informed on how serious and complex security is and how much risk are they taking when they check the little “Remember me” checkbox. They need to know the tradeoff between their comfort and their digital security. Most of all, they need to have the choice — many applications don’t even offer that — to put their comfort in first place, as long as they have some knowledge of what that entails.

Giving them a choice is specially important because it shifts the responsibility to their side. Once again, treat the user as an adult, not a child: “You want this? OK, you’ve got it, but know what you’re getting and know what you’re gaining and losing”.

So, what should I do?

Well, it’s a fact that nowadays the user has assimilated the concept of comfort and cutting this off “cold turkey” would be tough. I propose a middle ground that benefits everyone: Make the user session last two weeks tops. Also, try to educate the user, give them information, tell them why your company is doing that.

The main issue, as I’ve stated, is that the user must begin to understand — even if on a basic level — what they are gaining/losing by accepting less comfort. Turn a negative concept into a positive one, make them know their security is being improved.

So, I finally reached the “end” of this series (the subject and the disussion are really endless). This particular article was by far the hardest one, since it deals with less (none?) technological issues. I hope you’ve enjoyed this as much as I did.

Thank you and see you soon! =)

--

--

Er Galvao Abbott
The White Hat ElePHPant

Brazilian programmer and web app security advisor; Zend Framework Evangelist.