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.<p>For these banks, anything is okay, so long as the auditor okays it. And the auditors are on the payroll of the bank.<p>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.
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.
Who takes responsibility when a customer loses money because of bank's poor security?<p>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.<p>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.<p>This article seems to be based on the latter - <i>But for anyone with even a beginners knowledge of security, it’s bullshit.</i><p>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 <i>unable to connect to the site</i>. 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 <i>minimum possible as required</i>. 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.<p>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.<p>(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)
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).<p>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.<p>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 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.
If someone claims to support industry standards (or best practices), just ask <i>which</i> standard. Is it, for example NIST 800-63B ( <a href="https://pages.nist.gov/800-63-3/sp800-63b.html" rel="nofollow">https://pages.nist.gov/800-63-3/sp800-63b.html</a> )?<p>Of course, they aren't really following any standard or best practice -- but it will be tough to get them to admit that.
> It’s all about making money<p>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.<p>Example: aaaaaaaaaaaaB1! is a perfectly safe password.<p>Domain of characters: letters(26x2=52) + digits(10) + punctuation(32) = 52+10+32 = 94. Password length: 15. So, size of the password domain: 94¹⁵<p>The example password is not less safe than any other password in the same domain, but it is certainly much easier to remember.<p>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¹⁵.