5 ms·

“Bank has idiotic ideas about security” is as surprising as “sun rises at predicted time.” Something about the industry seems to push paranoid incompetence in s

“Bank has idiotic ideas about security” is as surprising as “sun rises at predicted time.” Something about the industry seems to push paranoid incompetence in security.

moviuro 7y ago
Currently at a bank's security team, here's what I gathered so far that explains (but doesn't excuse) the current state of affairs: - there are millions of customers who hate having to use their brains (or get their phone to receive a 2FA code); - a kilometer of requirements from whatever Central Bank, local policies and ad-hoc decisions; - (too) limited budget to build and run whatever service (cost of SMS 2FA for millions .vs. cost of some limited fraud); - very, very bad dev education, and general disdain for security. We do have a guide for them (the "secure development handbook"), and all our code audits reveal that it wasn't followed in all places; - outdated perception of security issues (screengrabbers are still a threat to tackle, according to some).
- mikeash 7y ago
  Thank you for sharing an inside view!
- zzzcpan 7y ago
  I guess it depends on the country and the bank. My bank, for example, does mandatory 2FA for 15+ years and uses some anomaly based approach to decide how aggressively to ask for 2FA, like if you send money somewhere unusual, it does phone call 2FA, instead of an SMS, and if you just pay your usual bills from the same IP address and the same PC it doesn't even ask for 2FA at all. It also has other optional security features like white lists for IP subnets, internet-only credit cards, etc.
  - zAy0LfpBZLC8mAC 7y ago
    That sounds terrible. I mean, I assume they don't assume liability for bad decisions? If "the PC" or "the IP address" was not contractually agreed to be an authentication factor (that you thus should protect from unauthorized use), it's a terrible idea to use them for authentication, while also (presumably) putting all liability on the customer.
    - GuB-42 7y ago
      In France, and I believe it is the case in many countries, in case the customer wants to roll back a transaction, the bank has to give the money back, unless it can prove that the transaction was legitimate. So basically, they can't put liability on the customer unless 2FA is used. The second factor is usually the credit card PIN. Banks have to maintain a balance between convenience and risk of fraud.
      - zAy0LfpBZLC8mAC 7y ago
        > unless it can prove that the transaction was legitimate. And what is the standard of evidence for that? > So basically, they can't put liability on the customer unless 2FA is used. The second factor is usually the credit card PIN. That doesn't sound like a second factor? Or are you talking about POS transactions? > Banks have to maintain a balance between convenience and risk of fraud. Really, they don't. The bank should never decide to take on risks for me. There is nothing wrong with offering a feature where the customer can select to allow certain transactions without 2FA. There is everything wrong with forcing that feature on customers.
    - zzzcpan 7y ago
      Why would that be a terrible idea? If someone has unauthorized access to my PC and knows my password from the account, he can log in and pay my bills and only the usual amounts, as paying too much would trigger 2FA.
      - zAy0LfpBZLC8mAC 7y ago
        Because there is a risk associated with it that you didn't agree to.
  - moviuro 7y ago
    I'm fiercly in favor of 2FA, and with DSP2[0] coming soon(TM), I have been pushing for sane 2FA at my place, in some select projects where it can be done with as little friction as possible. I'm very interested in your bank and how they do it, I'll see if voice 2FA is something feasible at my place. Could you share the bank's name though? Management likes to have solid evidence that someone else is already doing it when the security team proposes "weird solutions". [0] https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en https://ec.europa.eu/info/law/payment-services-psd-2-directi... , https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32015L2366 https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32...
- Apofis 7y ago
  This is unintentionally hilarious.
- rambojazz 7y ago
  > screengrabbers are still a threat to tackle, according to some I might be one of those "some". Why do you say that screengrabbers are not a threat to consider? There are hundreds of cases that I can think of where they can be a security issue.
vxNsr 7y ago
The most confusing thing is that a lot of banks (paypal included) still don't let you use "special chars" in your password. Or they will allow it but only for a very limited set that they don't tell you.
- mikeash 7y ago
  This one seems almost sensible to me. They probably have some ridiculous 1960s-era mainframe on the backend and it’s cheaper to keep it running than to redo it all.
  - cr0sh 7y ago
    It's more likely that the code and whatever was used for the DB dates from the 1960s-70s (likely a mixture of COBOL, JCL, and who knows what else), and has fixed-width columns for the data fields, with the password configured to something small. I'd say most if not all of this code is probably running on some IBM mainframe from the 1980s or 90s - possibly later - and likely in some kind of emulation or backwards compatibility mode (so something from the 80s/90s would likely allow for running S/360 stuff, and so forth). The actual hardware, though, has either been scrapped or is in a museum somewhere. There are very, very few instances of organizations still running "ancient" hardware (though the few that are tend to be known by the mainframe collecting community from what I understand).
- moviuro 7y ago
  That's not true about Paypal though: "Use lower case, upper case, a number, and a special character [like ~!@#$%^&*()_+=?><.,/]." [0] And even if the character subset is quite small (26 lower case, 26 upper case, 10 digits), it's still good enough if it's completely random and never leaked once. Just max out the password length (start at 32 char) and back track from there. [0] https://www.paypal.com/us/smarthelp/article/Tips-for-creating-a-secure-password-FAQ3152 https://www.paypal.com/us/smarthelp/article/Tips-for-creatin...
  - 0xffff2 7y ago
    I find this to be a recurring theme when banking security comes up. Every time I've ever been in a position to check, the specific claims made by HN comments about lackluster bank security practices have not been true. I assume they must have been true at one point, but commenters don't check that they are still true before commenting.

“Bank has idiotic ideas about security” is as surprising as “sun rises at predicted time.” Something about the industry seems to push paranoid incompetence in security.

moviuro 7y ago

Currently at a bank's security team, here's what I gathered so far that explains (but doesn't excuse) the current state of affairs: - there are millions of customers who hate having to use their brains (or get their phone to receive a 2FA code); - a kilometer of requirements from whatever Central Bank, local policies and ad-hoc decisions; - (too) limited budget to build and run whatever service (cost of SMS 2FA for millions .vs. cost of some limited fraud); - very, very bad dev education, and general disdain for security. We do have a guide for them (the "secure development handbook"), and all our code audits reveal that it wasn't followed in all places; - outdated perception of security issues (screengrabbers are still a threat to tackle, according to some).

mikeash 7y ago
Thank you for sharing an inside view!
zzzcpan 7y ago
I guess it depends on the country and the bank. My bank, for example, does mandatory 2FA for 15+ years and uses some anomaly based approach to decide how aggressively to ask for 2FA, like if you send money somewhere unusual, it does phone call 2FA, instead of an SMS, and if you just pay your usual bills from the same IP address and the same PC it doesn't even ask for 2FA at all. It also has other optional security features like white lists for IP subnets, internet-only credit cards, etc.
- zAy0LfpBZLC8mAC 7y ago
  That sounds terrible. I mean, I assume they don't assume liability for bad decisions? If "the PC" or "the IP address" was not contractually agreed to be an authentication factor (that you thus should protect from unauthorized use), it's a terrible idea to use them for authentication, while also (presumably) putting all liability on the customer.
  - GuB-42 7y ago
    In France, and I believe it is the case in many countries, in case the customer wants to roll back a transaction, the bank has to give the money back, unless it can prove that the transaction was legitimate. So basically, they can't put liability on the customer unless 2FA is used. The second factor is usually the credit card PIN. Banks have to maintain a balance between convenience and risk of fraud.
    - zAy0LfpBZLC8mAC 7y ago
      > unless it can prove that the transaction was legitimate. And what is the standard of evidence for that? > So basically, they can't put liability on the customer unless 2FA is used. The second factor is usually the credit card PIN. That doesn't sound like a second factor? Or are you talking about POS transactions? > Banks have to maintain a balance between convenience and risk of fraud. Really, they don't. The bank should never decide to take on risks for me. There is nothing wrong with offering a feature where the customer can select to allow certain transactions without 2FA. There is everything wrong with forcing that feature on customers.
  - zzzcpan 7y ago
    Why would that be a terrible idea? If someone has unauthorized access to my PC and knows my password from the account, he can log in and pay my bills and only the usual amounts, as paying too much would trigger 2FA.
    - zAy0LfpBZLC8mAC 7y ago
      Because there is a risk associated with it that you didn't agree to.
- moviuro 7y ago
  I'm fiercly in favor of 2FA, and with DSP2[0] coming soon(TM), I have been pushing for sane 2FA at my place, in some select projects where it can be done with as little friction as possible. I'm very interested in your bank and how they do it, I'll see if voice 2FA is something feasible at my place. Could you share the bank's name though? Management likes to have solid evidence that someone else is already doing it when the security team proposes "weird solutions". [0] https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en https://ec.europa.eu/info/law/payment-services-psd-2-directi... , https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32015L2366 https://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32...
Apofis 7y ago
This is unintentionally hilarious.
rambojazz 7y ago
> screengrabbers are still a threat to tackle, according to some I might be one of those "some". Why do you say that screengrabbers are not a threat to consider? There are hundreds of cases that I can think of where they can be a security issue.

vxNsr 7y ago

The most confusing thing is that a lot of banks (paypal included) still don't let you use "special chars" in your password. Or they will allow it but only for a very limited set that they don't tell you.

mikeash 7y ago
This one seems almost sensible to me. They probably have some ridiculous 1960s-era mainframe on the backend and it’s cheaper to keep it running than to redo it all.
- cr0sh 7y ago
  It's more likely that the code and whatever was used for the DB dates from the 1960s-70s (likely a mixture of COBOL, JCL, and who knows what else), and has fixed-width columns for the data fields, with the password configured to something small. I'd say most if not all of this code is probably running on some IBM mainframe from the 1980s or 90s - possibly later - and likely in some kind of emulation or backwards compatibility mode (so something from the 80s/90s would likely allow for running S/360 stuff, and so forth). The actual hardware, though, has either been scrapped or is in a museum somewhere. There are very, very few instances of organizations still running "ancient" hardware (though the few that are tend to be known by the mainframe collecting community from what I understand).
moviuro 7y ago
That's not true about Paypal though: "Use lower case, upper case, a number, and a special character [like ~!@#$%^&*()_+=?><.,/]." [0] And even if the character subset is quite small (26 lower case, 26 upper case, 10 digits), it's still good enough if it's completely random and never leaked once. Just max out the password length (start at 32 char) and back track from there. [0] https://www.paypal.com/us/smarthelp/article/Tips-for-creating-a-secure-password-FAQ3152 https://www.paypal.com/us/smarthelp/article/Tips-for-creatin...
- 0xffff2 7y ago
  I find this to be a recurring theme when banking security comes up. Every time I've ever been in a position to check, the specific claims made by HN comments about lackluster bank security practices have not been true. I assume they must have been true at one point, but commenters don't check that they are still true before commenting.