The security of my bank is pretty good, any account management action (password reset, card pin change, mailing address, email, name, etc.) requires physical presence in the closest branch. Not any arbitrary branch, the closest. With my passport. Not some bill or mail on my address. My passport.
The password reset will then setup a new password with 12 characters, number and specials included. This password is then sent via german postal service to my house, I can't pick it up on my local branch or have it told to me. Send via mail. Period.
The letter advices me to change the password to something secure immediately and destroy the letter securely afterwards. The banking website enforces this and you cannot change your password to any temporary password that your account previously had. (So if someone intercepted the letter, you would either notice or it would be useless)
The only downside is they have an ancient COBOL mainframe doing the accounts, so they're case insensitive and encoded in ECBDIC, although they are properly hashed using bcrypt, there is an upper limit of 24 characters because it still passes through there.
So I would say my bank is banking on the customer picking a good enough password and hoping they can replace the COBOL mainframe at some point.
They could just swap out the authentication mechanism instead of the entire COBOL stack. I don't really know why you wouldn't just run the auth bits in some other language. The programs that calculate your monthly interest on your mortgage doesn't exactly have to have to be able to handle your login credentials.
AFAIK it's because their entire system is rather legacy, so over the years they tacked on fixes while "the replacement will be done soon(TM)".
Banks do have some problem with these sorts of projects, so I think they're trying to build something that will last as long as the COBOL system at less cost.
Requiring a physical presence at a single branch doesn’t sound like good security to me. It does sound effective at preventing unauthorized access, but good security must also be good about allowing authorized access. Otherwise, the best bank security would involve encasing your money in concrete and sinking it to the bottom of the ocean.
It's not a very long date, you show up, show passport/id-card and they'll authorize you getting a new password send. And while you're there you can write out any SEPA transactions you need done onto paper and submit manually (almost any bank still has a special mailbox for manual submission).
To log in to an account for my Irish bank, AIB, you just need:
* A theoretically-secret 8-decimal-digit id
* Three digits from a secret 5-decimal-digit PIN
For many years all new online credentials were assigned an 8-decimal-digit id of the form: ddmmyynn where ddmmyy was the account holder birth date and nn was a sequence number.
I don't know how many accounts still have these birth-date-style ids but I have good reason to believe it is a great many.
You have a good point, though I _presume_ the challenge for the three digits of the PIN is made in tandem with the challenge for three characters from the password (making the cracking easy but not perhaps totally hilarious).
Were this not the case, I would have claimed that the number of combinations was 10^3 + k^3 rather than 10^3 x k^3.
If the challenge is indeed made in tandem then the PIN is essentially just a mandatory 4-digit prefix to the password. Still, the fact that only three characters of each part is requested is essentially fatal to the security any hashing scheme, as you say.
Even though this is not as ridiculous as hashing the four PIN challenges independently, which would be crackable with a lookup of amusingly-small size 1000, it still only needs a lookup of size about 700^3 =~ 350 million.
This might be roughly the threshold to annoy rather than to amuse?
I'm getting rather ridiculous myself at this stage but THEORETICALLY, if the hashes were all done including a long enough salt that was stored independently of the hashes then I believe there would be genuine significant security improvement to hashing.
Getting even more exotic, if the salt were also ENORMOUS, then it could make computing the required ~350 million hashes rather a costly endeavour (even in the event that the salt was obtained together with the hashed challenges).
In the Netherlands, most banks use a system that depends on the security of the chip-debit card, and a specific hardware device that each customer gets sent.
In my case (rabobank), whenever the bank needs authentication (i.e. when logging in, transfering money, or changing details) they present me with a QR-like code. I then use their supplied hardware [1]. This requires I enter my card and enter my PIN.
I can then scan the QR-ish code with a camera built into the device.
The device then prompts me with what I am doing. Something like "You are sending € X to account Y " or "Login into account Z". Upon clicking confirm, it outputs a numerical code I have to enter into the website.
I really love this system, I like it the best of all dutch systems I know.
One bank I know of (ANB-amro) has a similar hardware device, without using the QR codes, but numbers you enter. They also provide a USB connection so you don't need to enter numerical codes twice.
Another bank I know of uses standard password and SMS 2-factor authentication.
The mobile app for rabobank is quite a bit worse though. You need the scanner once to set up a PIN on the device. With that PIN, you can immediately login and see all account details. Moreover, small amounts to accounts you've previously sent money too can be sent using only that PIN.
The idea being that these are your 'friends' and it is nice to pay your friends quickly.
There is even a setting that will allow you to send amounts below a threshold (I think €100) to any account using only that PIN.
Luckly, you can turn that off, and it takes the scanner to turn it back on. However, you cannot turn of the transfer to 'friends' unless you simply refuse to install the app.
In Germany, we have the same system (Tan Generator, https://en.wikipedia.org/wiki/Transaction_authentication_num...). Actually, some banks provide Mobile TANs but we all know that this is eyewash with smartphones, whereas a Tan generator is an independent offline device.
However, there are also a number of loopholes. I can make a batch transfer of an arbitrary amount of money to a number of recipients with only a single TAN and this is not well integrated into the TAN generator device.
I use one of those (it looks like this[0]) and am quite happy with it, especially compare to my Swedish bank account that uses a similar device (DigiPass [1]) but all the numbers have to be entered manually.
I basically got the first device. Very cheap and easy to use (unless you got your monitor out of arms reach, in this case I have to move the blinkenlicht to a monitor I can reach)
I would much prefer to just have a username and password. Now I need to carry two devices (scanner and chip) and enter my PIN every single time I want to do anything. This gives it a huge amount of exposure for shoulder surfing, especially since this scanner thing has touch buttons (how are you ever going to enter anything on a touchscreen-like device without looking at it? The old device had buttons which you could press under the table or so).
This system is good for most people, but not for everyone. What I mind is the inflexibility.
- Log in: Two factor authentication based on chip card / chip card reader [1] with 4 digit PIN attached to card.
- 3 wrong PIN attempts blocks card, and requires phone unlock - The 'call' is secured by asking you the typical weak questions that are easily guessed
- each transaction requires using the same device to generate an 8 digit electronic signature
You could argue the 'security questions' part is weak, but I guess in the context of the process (buying you another 3 attempts)it's an ok'ish trade-off.
We have come a long way since the first 'Phone Banking' where all that was needed to access the account and make whatever transaction was punching in a 4 digit 'password' on a tone-dial.
Discord has stronger authentication methods than any of the 8 or so financial institutions I have accounts with.
All 8+ do their auth quite differently yet they're all broken and they all fall back on SSN. Why hasn't this industry standardized around one process that is actually effective?
Recently I made an account with Fidelity brokerage. Username maxes at 12 chars or something, password at 20. Not the worst, but then I had to get phone support and to authenticate over the phone you need to enter either your username or SSN on the keypad, and then the password on the keypad. The charspace of both the username and password have thus been reduced to 0-9 and * for all specials.
Another institution is for my employee share purchase plan. The phone support can initiate sells and transfers I'm pretty sure, yet their only auth is for my full name, employee number, and birthday. My employee number is literally printed on my laptop and some other stuff next to my full name, my birthday easily googleable with my name.
Can somebody explain why there should be any limit on passwords? I understand there has to be some limit, but why not make it an arbitrarily large number? Like 1000 characters?
I asked my bank about this and they forwarded my question to their security department and the reply was "don't worry - you aren't responsible for fraudulent transactions".
Since I've been getting support so much lately with a few institutions, I've been asking them questions like that as well. They all serve up that same answer.
For me, and I'd guess a lot of other people, I don't care if the money can _eventually_ be returned, I'm concerned for the day that my life savings goes missing and I have to spend days or weeks stressed to shit about when or if I'll get it back, meanwhile not sure if I can pay rent.
...or pay the bills. If you're late on your credit card/loan/mortgage payments, that shit gets on your credit report. Good luck clearing that up. I'm doubtful that "my bank has bad security, so someone stole all my money" will get you much sympathy.
There's no reasonable limit if the password is being properly hashed. Just whatever fits in a request, really.
My fear and supposition is that someone's storing the password in cleartext in some ancient SQL database somewhere, or blindly working from design specs that assume that.
There are some alternate, more charitable explanations, mostly to do with UI or UX, but none of those are particularly more encouraging.
All or most Finnish banks use an ~8 digit account ID and a 4-6 digit one-time password from a slip of paper that has 80 to 300 of them. Some have a separate PIN/password too.
For confirming large transactions (>5000 or 10000 eur) there's a separate phone call or SMA verification.
Nowadays there's apps for 2FA instead of always requiring the use of a one-time password. My corporate bank account still uses the paper backed one-time passwords though.
In Sweden the standard is something called BankID, which is basically a digitally bank issued id that ties into 2FA and works kind of like the Blizzard authenticator or the Googla Auth app, but I'm not sure about the solutions for people without smartphones. It's becoming kind of big here and is regarded as the most secure solution. The startup I'm at now use it for logging into both the admin dashboard and the customer pages.
The user fills in his SSN to our form, we push a request to bankid, they send a request to the users phone, user types a min 6 digit code which is posted to bankid, bankid tells us to go ahead with the login. For iPhone X there's even support for skipping the code and using FaceId.
(Disclaimer: I'm the co-founder of Narmi which provides online banking, mobile banking, and banking APIs to banks and credit unions in the United States)
For anyone interested, Associated Bank (mentioned in the article) is using Fiserv's Corillian [1] product.
The U.S. financial ecosystem is quite different than others around the world. Despite the asset base being consolidated heavily with a handful of institutions, there are still over 11,000 banks and credit unions around the country. Of those 11,000, I would estimate that less than 5% have any significant in house engineering teams (and that is a generous estimate). The rest rely entirely on third parties to run the technology and software that makes a bank a bank. The market is dominated by Fiserv, FIS and Jack Henry & Associates as the article mentions, but there is also a long tail of providers.
Very few bank and credit union executives understand the basics of cybersecurity. The vast majority of CEOs come from some type of lending centric leadership position since that has been the main source of revenue traditionally.
Unabashed plug: If you know a credit union or bank that is need of a better digital banking experience, I would greatly appreciate the plug/intro for Narmi.
Off topic, your screen shots look pretty but kinda funny: one is advertising TouchID integration on an iPhone X.
That said, quick glance at your website and Narmi looks good! Good luck to you, and I hope your product does well but also encourages the rest of the market to adopt some things like stronger auth.
(Disclaimer: Founder of another Banking Tech Company - Akouba - we have a commercial lending platform for banks).
Echoing the sentiments above - the current state of banking & security is quite appalling. Because of the outsourcing mentioned above, most bank leadership is so limited in their understanding of technology that they struggle to make decisions weighing tradeoffs of security vs functionality.
We've also seen the problem of new tech co's who are built questionable stacks with little thought given to the security aspect.
Hoya - would be great to connect and hear more about the solution and your experiences. Shoot me a message (nick@<our domain>).
36 comments
[ 4.0 ms ] story [ 86.2 ms ] threadThe password reset will then setup a new password with 12 characters, number and specials included. This password is then sent via german postal service to my house, I can't pick it up on my local branch or have it told to me. Send via mail. Period.
The letter advices me to change the password to something secure immediately and destroy the letter securely afterwards. The banking website enforces this and you cannot change your password to any temporary password that your account previously had. (So if someone intercepted the letter, you would either notice or it would be useless)
The only downside is they have an ancient COBOL mainframe doing the accounts, so they're case insensitive and encoded in ECBDIC, although they are properly hashed using bcrypt, there is an upper limit of 24 characters because it still passes through there.
So I would say my bank is banking on the customer picking a good enough password and hoping they can replace the COBOL mainframe at some point.
Banks do have some problem with these sorts of projects, so I think they're trying to build something that will last as long as the COBOL system at less cost.
I don't know how many accounts still have these birth-date-style ids but I have good reason to believe it is a great many.
So my username is not all that hard to bruteforce, and the pin/password must be stored unhashed (or variations/combinations hashed).
Super secure.
They probably do store the unhashed pin/password rather than the quadratically-many 4 x N\choose 3 combinations.
Still, at least an account with known username is guarded with a secret from a space of size 10^3 x k^3, for k =~ 70 or so.
With AIB, that space has size 1000 and for a time, they were revealing a little account information when provided only with the user id: http://olivernash.org/2015/11/18/security-theatre-at-allied-...
Were this not the case, I would have claimed that the number of combinations was 10^3 + k^3 rather than 10^3 x k^3.
If the challenge is indeed made in tandem then the PIN is essentially just a mandatory 4-digit prefix to the password. Still, the fact that only three characters of each part is requested is essentially fatal to the security any hashing scheme, as you say.
Even though this is not as ridiculous as hashing the four PIN challenges independently, which would be crackable with a lookup of amusingly-small size 1000, it still only needs a lookup of size about 700^3 =~ 350 million.
This might be roughly the threshold to annoy rather than to amuse?
Getting even more exotic, if the salt were also ENORMOUS, then it could make computing the required ~350 million hashes rather a costly endeavour (even in the event that the salt was obtained together with the hashed challenges).
Anyway.
In my case (rabobank), whenever the bank needs authentication (i.e. when logging in, transfering money, or changing details) they present me with a QR-like code. I then use their supplied hardware [1]. This requires I enter my card and enter my PIN. I can then scan the QR-ish code with a camera built into the device.
The device then prompts me with what I am doing. Something like "You are sending € X to account Y " or "Login into account Z". Upon clicking confirm, it outputs a numerical code I have to enter into the website.
I really love this system, I like it the best of all dutch systems I know. One bank I know of (ANB-amro) has a similar hardware device, without using the QR codes, but numbers you enter. They also provide a USB connection so you don't need to enter numerical codes twice. Another bank I know of uses standard password and SMS 2-factor authentication.
The mobile app for rabobank is quite a bit worse though. You need the scanner once to set up a PIN on the device. With that PIN, you can immediately login and see all account details. Moreover, small amounts to accounts you've previously sent money too can be sent using only that PIN. The idea being that these are your 'friends' and it is nice to pay your friends quickly. There is even a setting that will allow you to send amounts below a threshold (I think €100) to any account using only that PIN. Luckly, you can turn that off, and it takes the scanner to turn it back on. However, you cannot turn of the transfer to 'friends' unless you simply refuse to install the app.
[1] dutch wikipedia link: https://nl.wikipedia.org/wiki/Rabo_Scanner
However, there are also a number of loopholes. I can make a batch transfer of an arbitrary amount of money to a number of recipients with only a single TAN and this is not well integrated into the TAN generator device.
IMO it's the best option if you don't want to use HBCI and Co.
[0]: https://i.ebayimg.com/images/g/gtoAAOSw5zNalXj7/s-l300.jpg
[1]: https://img3.mp-farm.com/3458223.jpg?w=500&h=375&v=3
https://en.wikipedia.org/wiki/Chip_Authentication_Program
I would much prefer to just have a username and password. Now I need to carry two devices (scanner and chip) and enter my PIN every single time I want to do anything. This gives it a huge amount of exposure for shoulder surfing, especially since this scanner thing has touch buttons (how are you ever going to enter anything on a touchscreen-like device without looking at it? The old device had buttons which you could press under the table or so).
This system is good for most people, but not for everyone. What I mind is the inflexibility.
- Log in: Two factor authentication based on chip card / chip card reader [1] with 4 digit PIN attached to card.
- 3 wrong PIN attempts blocks card, and requires phone unlock - The 'call' is secured by asking you the typical weak questions that are easily guessed
- each transaction requires using the same device to generate an 8 digit electronic signature
You could argue the 'security questions' part is weak, but I guess in the context of the process (buying you another 3 attempts)it's an ok'ish trade-off.
We have come a long way since the first 'Phone Banking' where all that was needed to access the account and make whatever transaction was punching in a 4 digit 'password' on a tone-dial.
[1] http://c621460.r60.cf3.rackcdn.com/Kaartlezer---kaart.jpg
All 8+ do their auth quite differently yet they're all broken and they all fall back on SSN. Why hasn't this industry standardized around one process that is actually effective?
Recently I made an account with Fidelity brokerage. Username maxes at 12 chars or something, password at 20. Not the worst, but then I had to get phone support and to authenticate over the phone you need to enter either your username or SSN on the keypad, and then the password on the keypad. The charspace of both the username and password have thus been reduced to 0-9 and * for all specials.
Another institution is for my employee share purchase plan. The phone support can initiate sells and transfers I'm pretty sure, yet their only auth is for my full name, employee number, and birthday. My employee number is literally printed on my laptop and some other stuff next to my full name, my birthday easily googleable with my name.
I asked my bank about this and they forwarded my question to their security department and the reply was "don't worry - you aren't responsible for fraudulent transactions".
For me, and I'd guess a lot of other people, I don't care if the money can _eventually_ be returned, I'm concerned for the day that my life savings goes missing and I have to spend days or weeks stressed to shit about when or if I'll get it back, meanwhile not sure if I can pay rent.
My fear and supposition is that someone's storing the password in cleartext in some ancient SQL database somewhere, or blindly working from design specs that assume that.
There are some alternate, more charitable explanations, mostly to do with UI or UX, but none of those are particularly more encouraging.
For confirming large transactions (>5000 or 10000 eur) there's a separate phone call or SMA verification.
Nowadays there's apps for 2FA instead of always requiring the use of a one-time password. My corporate bank account still uses the paper backed one-time passwords though.
The user fills in his SSN to our form, we push a request to bankid, they send a request to the users phone, user types a min 6 digit code which is posted to bankid, bankid tells us to go ahead with the login. For iPhone X there's even support for skipping the code and using FaceId.
For anyone interested, Associated Bank (mentioned in the article) is using Fiserv's Corillian [1] product.
The U.S. financial ecosystem is quite different than others around the world. Despite the asset base being consolidated heavily with a handful of institutions, there are still over 11,000 banks and credit unions around the country. Of those 11,000, I would estimate that less than 5% have any significant in house engineering teams (and that is a generous estimate). The rest rely entirely on third parties to run the technology and software that makes a bank a bank. The market is dominated by Fiserv, FIS and Jack Henry & Associates as the article mentions, but there is also a long tail of providers.
Very few bank and credit union executives understand the basics of cybersecurity. The vast majority of CEOs come from some type of lending centric leadership position since that has been the main source of revenue traditionally.
Unabashed plug: If you know a credit union or bank that is need of a better digital banking experience, I would greatly appreciate the plug/intro for Narmi.
[1] https://www.fiserv.com/customer-channel-management/online-ba...
That said, quick glance at your website and Narmi looks good! Good luck to you, and I hope your product does well but also encourages the rest of the market to adopt some things like stronger auth.
Echoing the sentiments above - the current state of banking & security is quite appalling. Because of the outsourcing mentioned above, most bank leadership is so limited in their understanding of technology that they struggle to make decisions weighing tradeoffs of security vs functionality.
We've also seen the problem of new tech co's who are built questionable stacks with little thought given to the security aspect.
Hoya - would be great to connect and hear more about the solution and your experiences. Shoot me a message (nick@<our domain>).