Hacker News new | past | comments | ask | show | jobs | submit login

The article fails to recognize the value of the "security images" to the banks. The banks have used these images to satisfy the requirements of the FFIEC guidance "Authentication in an Internet Banking Environment"[1].

Any complaints about the value of the security images should not be addressed to banks. You should direct your complaints to the FFIEC and/or to your banks regulator (OTS, OCC or NCUA).

[1] http://www.ffiec.gov/pdf/Auth-ITS-Final%206-22-11%20%28FFIEC...




Great, they're probably responsible for this too. Every time you try and use a new tab or navigation (back, forward, refresh) on my banks website, you get kicked out to the main page. It's like someone has never heard of form keys.

http://i.imgur.com/erm0faA.png


Are they the people to blame for the 15-minute bank login timeouts everywhere, too?

Because I can't think of a more frustrating and anti-security policy that claims to be "for your security".

(By requiring many more repeated logins, the risk rises that I'll slip one time and not carefully check that the DNS/SSL info is correct.)


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.


Interesting, I've always wondered why so many banks use this system online instead of something more robust like two-step auth.


The only reason the banks use these systems to begin with is the FFIEC guidance. These "improvements" were not voluntarily put in place by forward thinking bankers, they had to because their regulators told them to. So it is all about the cost of the system. Before anyone says Chase/HSBC makes X billion dollars profit keep in mind that these regulations also apply to smaller community banks with 5 Billion in holdings.

Keep this in mind when you assess any of these systems; the authentication systems are not put in place to manage customer risk, they are put into place to manage regulatory risk.


When I signed up for USAA, by default they had a silly authentication system based on "security questions". I was very disappointed until I found out that they support several mechanisms, and allow you to disable the ones you won't use. Hence, I use the one where I combine my password with a token generated by a mobile app. Maybe other banks have alternate authentication mechanisms stashed away as well?


They do. Bank of America, which to my knowledge is the largest bank that still uses the "security image", also allows users to enable 2-factor authentication via SMS.


Not just via SMS, but you can also purchase a token card called a SafePass.


I've only seen two step used to validate the user to the server. Are there sites that use two step to verify the server to the client?


Not a lot of information regarding security images in there and not all banks use them. BofA does, but not Chase. Therefore I have to assume its some lame compliance committee within the bank determining usage.


You are safe assuming that risk managment at banks is not implemented uniformly across the industry.

Were you expecting it to say "security images are required"?


I skimmed the PDF and didn't see what you're referring to; however, I did see it explicitly point out the ineffectiveness of "security" questions.


This all started with the first supplement the FFIEC put out regarding authentication in an internet environment in 2005[1]. This initial supplement was put out to clarify what was expected of banks especially with regards to the FFIEC examination handbooks regarding e-banking[2] and information security[3]. (This all began with 12CFR30B[4][5])

Are you familiar with reading federal regulator-ese? They do not ever come out and make blanket statements such as use XYZ, ensure X bit keys and so on. The entire process is based on the banks and the examiner's interpretation of the bank's risk profile. If you are interested in learning more about this reading some of the banking industry press coverage at the time may be easier to digest.

[1] http://www.ffiec.gov/bsa_aml_infobase/documents/new_5_2007/O...

[2] http://ithandbook.ffiec.gov/it-booklets/e-banking.aspx

[3] http://ithandbook.ffiec.gov/it-booklets/information-security...

[4] http://ithandbook.ffiec.gov/media/21989/occ-12cfr30-safe_sou...

[5] I say 12cfr30b because that is what got the ball rolling for OCC regulated banks and at the time I worked for an OCC regulated bank. Depending on who the regulator (OTS, NCUA, etc) is the "ball rolling document" will be different.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: