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.
> ... 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.
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.
"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.
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.
Not doing anything also risks fucking up something in the process: customers' money because of the lack of security.
But assuming that staying within "accepted standards" for secutiry indemnifies the bank, it's obvious that they shouldn't care about lost savings.
In case shit hits the fan, they would be covered, and it's the problem of the customer.
I'd like to be proven wrong here - that banks take responsibility for behind-the-curve security practices.
> Not doing anything also risks fucking up something in the process: customers' money because of the lack of security.
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.
To be fair, some of them are morons. There are morons at any organization of sufficient size.
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.
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.
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.
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.
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)
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.
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.
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:
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.
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.
>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.
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.
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.
Also to pile on - running that way is a clear violation of that government's policies, and they have blatantly lied about other security issues to other (customer) government agencies that are trying to do the right thing. It's not just a matter of choosing cost savings over security, it's also about breaking the law.
Well, to be fair, short length limitations are odd in that if the password is put through a KDF, the output is always the same length, so it shouldn’t really matter how long the user’s password is.
it shouldn’t really matter how long the user’s password is
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.
If the password length limit is about memorability, it's pretty weird that their password guidelines suggest starting with a 57-character passphrase and then doing a bunch of difficult to remember obfuscations.
The author does not make a claim that credentials are stored in the clear. The author only says that he cannot think of a good reason for the limitation and asks for help from readers in explaining why this limitation exists. He says that the only reasons he can think of are similar to storing passwords in plaintext, but makes no claim that these are the actual reasons.
Even if they’re not, Yahoo used MD5, and LinkedIn used SHA-1. With the latest version of Hashcat, some cloud GPUs, and a little money, it wouldn’t take much to crack.
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.
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.
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!
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/. 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.
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.
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¹⁵.
> Why would the attacker assume that the pattern /[a-z]+[A-Z][0-9][:punct:]/ would be any more likely that any other pattern?
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.
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.
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.