It's a trade off between that and allowing some random stranger to transfer your money if you get up and forget to lock your computer. Our first alpha didn't have the auto-logout and by far the most common piece of feedback we got was that we needed it.

It isn't just if you step away from a computer. A session token that never expires is as good as a password, but with weaker protection.

If I intercept a session token via a proxy, network dump, XSS or browser bug I can use it and replay it at any time in the form it was intercepted.

Passwords get sent once and are usually protected and encrypted or hashed on the server. Session tokens are not, hence why they need to be temporary.

Holding everything else constant, shorter session tokens reduce one avenue of exploitation, yes.

But everything else isn't constant: shorter sessions mean more password-typing-transactions, and especially into older tabs that have a "logout successful for your protection" message. That increases the risk of a successful phish, including by the same vulnerabilities you fear could compromise a session token. And practically, the problem with a password compromise is that it gives access to a indefinite stream of new session tokens.

So there's a balance between session-token-risks and login-transaction-risks. I doubt 15 minutes is the optimal tradeoff time -- I'm sure it isn't for me, with my habits on my own computers, and I haven't seen any rigorous evidence it's the right level for the banking masses. Its maddening uniformity across the industry "smells like" an arbitrary check-box from some regulatory document somewhere.

What's the alternative?

Online-services such as iCloud, Facebook, GMail, etc. don't auto-logout but they also have designed endpoints in which you need to re-authenticate (when changing the password, address info, anything dealing with authentication processes, generally) while still logged in.

How would this work for banks? Besides reauthenticating when changing critical account info, should someone be forced to reauthenticate when they make a transfer? Or a transfer of a certain amount of money?

While banking software is very sophisticated, my impression is that that's in the transactional system. My impression from using three different banks to manage my funds is that bank corporations are entirely less sophisticated in the user interface arena.

I think many people at HN remember American Express's debug mode snafu: http://techcrunch.com/2011/10/06/zero-day-vulnerability-on-a...

And I remember when their antiquated system couldn't handle anything more sophisticated than 8 character case insensitive passwords.

I much prefer that banks, for the time being, play it safe with the auto-logout.

The alternative is longer timeouts, perhaps even indefinite when requested and for low-risk (view-only) activities.

If I say something is my secured home computer and I want a longer session, give me a few hours. And if you need to re-auth me "for my protection", do it when I try to do something fishy, like a transfer-out-of-bank or atypical-bill-pay... not just check my balance/ledger for whether a transaction has come through.

The error is the assumption that this does "play it safe": I'm unaware of any study that this decreases account misuse. And if login-phishing is a major (if not the largest) risk, then training someone to constantly expect some random tab to have a "timed out for your protection" screen, needing re-login, just gives phishers another hook where a user's guard is slightly lower.

>How would this work for banks? Besides reauthenticating when changing critical account info, should someone be forced to reauthenticate when they make a transfer? Or a transfer of a certain amount of money?

My bank does this. It also allows batching transfers, so you only have to reauthenticate once.