Banks Enforcing Lower Security for Profit
aaronm.net
aaronm.net
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.
Well, if they weren't going to bother patching anything anyways, there's really no point in running a vulnerability scan, I suppose.
... versus ...
"We knew we were vulnerable but just didn't bother patching"
Note that the only definition of "counterproductive" here ( https://www.merriam-webster.com/dictionary/counterproductive ) is "tending to hinder the attainment of a desired goal".
> Yes ... They’re not morons.
That seems debatable.
I wasn't on the teams handling security, account login / access, etc so I can't speak to specific implementations (nor would I), but the folks I interacted with were super sharp.
Salted? Just once? Or through something like bcrypt or scrypt? Because just salting nowadays is pretty much useless.
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.
I'd like to be proven wrong here - that banks take responsibility for behind-the-curve security practices.
Sure, but the cost of dealing with a few customers worth of problems is substantially lower than the entire org grinding to a halt because the infrastructure doesn't work anymore.
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.
The bank.
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.
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)
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.
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.
This is a HSM for people like me a few minutes ago:
[1] https://en.m.wikipedia.org/wiki/Hardware_security_module
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.
It doesn't, which is by password rules are usually driven by two factors. The first is an attempt to increase entropy (eg must have a number and a capital letter), and the second is trying to ensure memorability (eg a length limit). Neither of these have anything to do with the database schema.
Password rules don't tell you anything about how the password is stored.
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.
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.
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.
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.
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.
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!
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/. 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.
Of course, they aren't really following any standard or best practice -- but it will be tough to get them to admit that.
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.
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¹⁵.
No need to assume —— large free and open corpora of real user passwords exist. If it is actually more likely to be used by humans, then it’s more likely to be cracked.
9999.9999+aaaa.aaaa+B
It is not particularly hard to remember, while it forces the attacker to enumerate 94²¹ possibilities.