
Banks Enforcing Lower Security for Profit - matthberg
https://www.aaronm.net/banks-enforcing-low-security/
======
bradknowles
It can be quite terrifying to consult for some banks. That’s when you get to
see how bad things really are in the industry, and how common some bad
practices are.

For these banks, anything is okay, so long as the auditor okays it. And the
auditors are on the payroll of the bank.

In one case, they wanted OS patching to be done no more than yearly, and they
didn’t want the OSSEC tools to be run to tell them if there were any
vulnerabilities unless they were planning on doing OS patching. But the
auditor had okayed it, so that was that.

~~~
jlgaddis
> _... they didn’t want the OSSEC tools to be run to tell them if there were
> any vulnerabilities unless they were planning on doing OS patching. But the
> auditor had okayed it, so that was that._

Well, if they weren't going to bother patching anything anyways, there's
really no point in running a vulnerability scan, I suppose.

~~~
adrianN
In fact it's probably counterproductive as then you _know_ that there are
vulnerabilities and might have more liability for not patching them than if
you didn't look in the first place.

~~~
confounded
Why is that counter-productive?

~~~
jlgaddis
_" We didn't know we were vulnerable"_

... versus ...

 _" We knew we were vulnerable but just didn't bother patching"_

~~~
confounded
How does this reduce productivity?

~~~
thaumasiotes
"Counterproductive" is a normal English word unrelated to "productivity".
Taking an action is counterproductive if it leaves you worse off than you
would have been if you hadn't done it.

Note that the _only_ definition of "counterproductive" here (
[https://www.merriam-
webster.com/dictionary/counterproductive](https://www.merriam-
webster.com/dictionary/counterproductive) ) is "tending to hinder the
attainment of a desired goal".

------
shove
I’ve worked for Fidelity and while there’s a grain of truth here, this is
mostly horseshit and conjecture. Upgrading SQL or whatever isn’t going to
happen without a very good reason because you risk fucking something up in the
process. Enterprise orgs can’t move fast and break things. By definition that
means they’re permanently behind the curve.

~~~
loeg
Ah, this would be the same Fidelity that within the last five years limited
users to 12 character passwords?

~~~
shove
Yes, and yes passwords are encrypted / salted. They’re not morons.

~~~
greenhouse_gas
Encrypted? You mean reversible encryption. I hope not.

Salted? Just once? Or through something like bcrypt or scrypt? Because just
salting nowadays is pretty much useless.

~~~
mfjordvald
You're misunderstanding the terms a bit. Salting is only done once because
it's a random string you apply to the users password so that if two users use
the same password they do not result in the same hash. This is primarily meant
to combat pre-generated rainbow tables and forcing each password to be broken
individually.

You're thinking of multiple rounds of hashing, designed to increase the
computation cost of the hashing. For example Bcrypt has a built in cost
factor. While this is definitely important it's not quite the same as salting.

------
rhn_mk1
Who takes responsibility when a customer loses money because of bank's poor
security?

Postbank.de uses a 6-character pasword (!), and they seem to rely on 2 factor
authentication for actually moving money. I assume my transaction history is
public.

I'd like to know what incentive besides regulation do banks have in order to
keep peoples' accounts private.

~~~
iamthirsty
Banks don’t have any incentive to do anything that doesn’t make them money
_except_ for regulation.

~~~
sgroppino
And competition.

------
thisisit
Most of the time I check if these articles chastising a particular industry
are written after some consulting experience or is it just hubris.

This article seems to be based on the latter - _But for anyone with even a
beginners knowledge of security, it’s bullshit._

To avoid a rant, let me give an example about a social networking site. Back
in 2015 with the announcement of SHA1 vulnerability, the company started
systematically replacing stuff with SHA2. The issue came - some users in APAC
region were on old mini browsers and _unable to connect to the site_. Given
the SHA2 was still 2 years away the company shaped the traffic to accommodate
SHA1 users. So the company was doing, as mentioned by the author _minimum
possible as required_. But to accommodate all users, there was no other
choice.

~~~
daveFNbuck
Is anything specifically in this article bullshit? Would it be impossible to
support 16-character passwords or prevent logins with old credentials?

------
viraptor
ING Australia: You can set a pin. As in a 4-digit pin. There is no password.
And you can lock anyone out with 3 wrong tries.

But the saving accounts have the highest interest, no atm fees, and it's been
featured in the barefoot investor, so loads of people will use them.

(your pin never saves to a password manager though, because they use a virtual
keypad that mixes up the key positions and the you cannot auto-fill that
entry)

~~~
ajdlinux
Westpac - 6 char alphanumeric password, with stupid virtual keypad.

CommBank - at least last time I had an account with them, I'm fairly sure
their passwords were case-insensitive - which can be done while still using
hashed passwords, but it's not an encouraging sign.

------
raesene2
For uk banking systems it is very likely that the passwords are stored
symmetrically encrypted with the key stored in an HSM (based on my experience
working as an IT security consultant in UK banks).

Whilst limiting passwords isn’t good, with storage in that way i’m nt sure I
see many viable attacks on a 12 char random password.

Online brute force will hit the lockout on the site, and even assuming you
could get access to the server hosting the encrypted passwords and HSM you
cant decrypt the passwords (unless they have made some horrific setup errors),
so the only offline attack is to try and brute force the encryption key, which
is unlikely to be easy.

~~~
pmontra
I'm not familiar with HSM [1] but is any internal attack possible, like
bribing an employee or getting a trojan on somebody's computer inside the
bank?

This is a HSM for people like me a few minutes ago:

[1]
[https://en.m.wikipedia.org/wiki/Hardware_security_module](https://en.m.wikipedia.org/wiki/Hardware_security_module)

~~~
raesene9
So obviously in cases of personnel threats you need different controls.

On HSM setups I've seen the keys are under dual-control (i.e. two different
people have half the key and in the event that it needs re-entered, both have
to enter their keys independently), along with other general controls (hiring
background checks etc)

That's not to say it's impossible, just there are controls in place.

Now in all this I'm not trying to suggest that bank security is perfect, it's
obviously not, but that particular concerns about password strength and
threats of attack on this could be misplaced, due to lack of understanding of
the controls in place.

------
dboreham
I think this article is complete nonsense. The author presents no evidence to
support the claim that credentials are stored in the clear.

~~~
throwaway92782
What sucks is how hard it is to do anything when you're on the inside and know
just how dangerous the systems are, and management has no interest in fixing
things.

A former employer of mine is a government agency with millions of accounts,
with SSN and every kind of PII imaginable, they have actually been breached
(millions of SSNs lost) ... and they still don't hash passwords.

Would love to out them, but the management is vindictive as hell so I can't
come up with a good way to out the place without great risk to myself.

I'm sure many have been in this situation - we need a safe way for people like
us to speak up before breaches happen.

~~~
AnIdiotOnTheNet
>A former employer of mine is a government agency with millions of accounts,
with SSN and every kind of PII imaginable, they have actually been breached
(millions of SSNs lost) ... and they still don't hash passwords.

So the costs of the breach haven't been high enough to provoke action, which
means they're probably making the right decision if one assumes that hashing
the passwords would require a significant modification of their software,
infrastructure, or processes.

~~~
throwaway92782
Guessing you'd feel differently if it was you, or a family member, who had
their identity breached along with information about every bad situation in
your life.

And no, the costs aren't high to change it. The code to do it has been done
for a long time. It got mired in political grandstanding, and that's it.

~~~
AnIdiotOnTheNet
Of course I'd probably feel more strongly if I were affected, but that's true
of any policy isn't it? That has nothing to do with the correctness of the
decision.

I think we should end mortgage tax deductions. Most homeowners would disagree.
The fact that they are personally negatively affected is irrelevant to whether
or not ending mortgage tax deductions should be done.

------
roman_savchuk
I'm sorry if it's dumb question, but how could one perform dictionary attack
without having access to the hash table? From the login page? Unlikely, it
will lock itself after a few unsuccesful attempts. Yet article implies that if
password is weak everything else doesn't matter.

~~~
k4ch0w
Bro, totally not a dumb question.

From an Attacker's point of view, yes logging in from the same IP against the
same account will get you banned fairly quickly. People put up their best
defenses on the most obvious endpoint, which is why a good attacker quickly
tries something else. However, two possible routes to circumvent this are

1\. Find a vulnerable API call/Webportal on the bank's other sites that don't
have IP banning but require authentication. This happens much more than you'd
realize.

2\. A distributed attack, either with a large proxy network or if you have a
botnet, in which you bruteforce the credentials with different time
intervals/simulated human behavior to not lock out the account.

~~~
sgt101
1\. seems like someone is really screwing up with an API like this.

2\. Ok, for a three word combo with I think >40000^3 =64 billion possibles, so
to have a 50% chance of cracking a password you need 32 billion goes, with a
human speed api you're talking 5 seconds per go (mean, and probably you'd get
caught on this rate) so 1 million bots (and I think the bank would be
suspicious if it saw 1 million different IP's trying one account- would need
32 * 5000 seconds.. 2 days to get one account. Doesn't feel remotely feasible!

~~~
k4ch0w
1\. It happens more than you'd think. Some legacy system is still up and they
are connected to the same credential store. You find a hole and get into their
internal network and some random webportal that no one maintains still has
access to the database.

2\. Yes, so this one is more like you are shooting with a shotgun from a long
long range and hoping to hit. You can improve the accuracy by using a password
dump on your target. People have a common pattern that they use with their
passwords. You can either find one that is still being used or try to find a
couple they have used and create a new one. Great site to demonstrate the
power of a password dump is
[https://haveibeenpwned.com/](https://haveibeenpwned.com/). So in some cases
it is possible, but as someone who professionally red teams, I wouldn't
bruteforce past a certain time period before trying something else.

------
pjsg
If someone claims to support industry standards (or best practices), just ask
_which_ standard. Is it, for example NIST 800-63B (
[https://pages.nist.gov/800-63-3/sp800-63b.html](https://pages.nist.gov/800-63-3/sp800-63b.html)
)?

Of course, they aren't really following any standard or best practice -- but
it will be tough to get them to admit that.

------
homero
Vanguard had a tiny size limit for the longest time

------
b0rsuk
XKCD - Password Strength (a.k.a. correct horse battery staple)

[https://www.xkcd.com/936/](https://www.xkcd.com/936/)

------
thinkloop
> It’s all about making money

Hacked customer accounts likely costs banks lots of money to deal with -
certainly more than the extra few bytes of disk space to store longer
passwords. This is a simple case of legacy cruft or ineptitude.

~~~
lhopki01
Yes legacy cruft which would cost money to fix. It is completely about money.
Not the cost of storage but the cost of paying people to fix it.

------
nemesis_abc
Why "avoid repetition"? Entropy does not matter in passwords.

Example: aaaaaaaaaaaaB1! is a perfectly safe password.

Domain of characters: letters(26x2=52) + digits(10) + punctuation(32) =
52+10+32 = 94. Password length: 15. So, size of the password domain: 94¹⁵

The example password is not less safe than any other password in the same
domain, but it is certainly much easier to remember.

Why would the attacker assume that the pattern /[a-z]+[A-Z][0-9][:punct:]/
would be any more likely that any other pattern? Therefore, the attacker
cannot assume a pattern for non-dictionary passwords. He will only be able to
enumerate them using brute force, which is utterly unrealistic for a set with
a cardinality of 94¹⁵.

~~~
lhopki01
To prevent dictionary attacks. Any decent password cracker will use a
dictionary before trying brute force attacks.

~~~
nemesis_abc
The example password is unlikely to be in the dictionary. I just made it up on
the fly. Another example would be:

9999.9999+aaaa.aaaa+B

It is not particularly hard to remember, while it forces the attacker to
enumerate 94²¹ possibilities.

~~~
daveFNbuck
If an attacker obtains a few of your passwords, they can infer some things
about how you're generating them and bring down the number of possibilities
closer to the entropy of your method. If you use a high-entropy generation
algorithm, no such attack is possible regardless of the information gained by
the attacker.

