So normally I look at the deep problems, the protocol-layer. The encryption protocols, the page architecture. Once in a while I delight in spotting something so “layer 0”, any layperson can appreciate it’s impact directly. Case in point, a very basic way of protecting your banking clients, even when they are done visiting your site – using idle time logouts. It seems that the Royal Bank was the only bank to “make the grade” when it comes to this one basic security configuration. Logging out idle users should be done actively, not passively.
May You Truly Live in Idle Times
Used in all ways, from DEC in the 80’s to modern web browsers, the idle timeout was factory-built to ensure that your unused session could not be intercepted and disturbed. Back then, at the coffee-break physical level, you wouldn’t want to find that someone had interrupted or viewed your work or modified your terminal. Now, it’s to ensure data integrity and curtail authorisation bypass. After leaving something alone for a while, a computer should not let you continue your session without authenticating again.
Different Idle Times for Different Reasons
- web
- terminals
- protocol handling (tcp vs. udp timeout)
- License expiration
- Bank Account Unclaimed Balances “Lost Money”
- The stop-engine grip on your favourite lawn mower
Logging Out Behind the Scene vs. Active Logout Redirection.
So idle times are a choice. They must balance between the need for security with the pain for their clients. Reasonably, there lives a direct correlation between online bank churn and idle timeout, in seconds.
There’s a dimension now required of the choice. The first binary switch of whether it was implemented or not. The second decision point is ACTIVE LOGOUT through idle or PASSIVE LOGOUT. The defacto position for asyncronous communications is passive.
Passive Logout
Passive logout assumes that the client is still using their stale view, or has disappeared altogether. In this case, there is no active feedback to indicate that the user’s session has expired. The view is not destroyed or changed, and the logout is silent.
The next interaction (pressing a button, clicking a hyperlink) along the same session is interrupted with a “sorry, log in again” message.
The real problem here is that the transaction of truly logging out, destroying a view, depends on my making an active decision to do so.
It was my first presentation, and my 100 windows from the previous late night’s last minute change cram were all still open. There, in front of 15 people, my complete financial picture was absorbed and instantly my credibility amongst my peers {{ did something to alter it }}
Said someone , somewhere
If a bank was truly committed to protecting their banking in all aspects of their customer’s lives, they would consider and implement a simple technical solution (one line of code) to move a view to a state of low-security along with the other backend work that goes into logging out a user (apache, nginx mechanisms, web framework mechanisms, Page Expiry HTML headers).
Active Logout – Hurray!
As in the first view, a session times out in some way.
However…
This logout happened a long time ago in the bank’s backend, but just to be sure, Royal Bank forwarded me off to a notification page. They even did the favour of invoking a proper SIGNOUT request, just in case there’s dependent processes waiting for signalling to shut down their pipe for me, as well.
Way to go Royal Bank. This is the proper way to find you’ve inadvertently left a tab open with your banking.
Signout-Requests May Have a Different Function than Idle Timeouts in the Backend
Hold on here. Maybe there’s a chance then, that logically if a SIGNOUT command exists, that the function must encompass at least a return to indicate to the user that they’ve signed out. Is there then, also a chance that issueing a SIGNOUT command might invoke the signout process from an idle-timer process in the backend(a different invocation method?)
?
Is there a way to continue “portions” of the communication with the bank servers even after a web-server “idle” timer has prevented from navigating their UX? Take for example, AJAX or JQuery to different, purposed, servers you maintain in the domain that serves to build a web-experience. Are those discontiguous processes reliant upon their own timeouts, or are issued and relayed commands issuing the destruction of a type of backend session?
Look, this is not likely the case. Right banking industry? I mean, of course your webservers are sending state information to all the other service components… or even better, from a AAA outward to the web server…
I’m only speculating that the period of time, in order to fully be logged out from a system and all it’s supporting backends, has greater likelihood of being examined for weakness during passive-logouts. They are a fuzzy-phased aggregate of dis-contiguous and isolated backend processes that may allow for limited additional use beyond their web-page counterpart. This is an example of timing-attack thinking.
I’d have to recommend then, that all banks purposely forward their clients at the end of a top-down idle timer. The simplest method of doing so is redirection-after-idle to a purpose-built logout page. Just like Royal.
Psst, this was discussed only based on a chrome browser on Win10 PC. I advocate for the active-logout-by-idle-timer mechanism, but i’m sure the interpretations of the why are defensible by any particular bank. Right?
RiPPUL CyberSecurity BLOG 