Live data from Hacker News

Equifax securities fraud class action [pdf]

securities.stanford.edu

31–40 of 227 posts

Re: Equifax securities fraud class action [pdf]

#31
Something similar occurred at a previous employer. They were counting on the admin port being blocked on the firewall. This was 15 years ago but even nowadays network guys tend to manage firewalls with spreadsheets and manual updates rather than something like Chef so it’s unsurprising that it got missed or overwritten in an upgrade or something.

Re: Equifax securities fraud class action [pdf]

#33
post #28

I’m genuinely curious how this happens. I remember my first job in the industry, just out of university. I knew nothing about security, but still wouldn’t have done that. My first gig was in a credit union software company, and the security standards were nonexistent, yet we still had more reasonable passwords than this (which sounds like an installation default).

Usually they rely on some other mechanism for security. Like you can only access the portal admin page from the intranet or a few IP addresses. That has failed, not the fact that they didn't change the password.

Security only really works in layers. So yes, the password should have been changed too.

Re: Equifax securities fraud class action [pdf]

#35
These security nightmares begs the question: Why don't databases use asymmetric keys and authenticate & authorize access? Why are we still reliant on password based authentication? If it's simply the question of key management and distribution, that's a solved problem.

Re: Equifax securities fraud class action [pdf]

#37
Where was that database located? If I had a database in an offline computer with that username and password, it wouldn't be a problem. I'm not saying this is the case, but perhaps it had a whitelist of hosts that could connect to it, which were "properly" protected?

Re: Equifax securities fraud class action [pdf]

#38
post #29

I'm using that headline as our thought of the day in group chat at work. Because that is just egregious and negligent. Nobody thought to raise that? to anyone? Although I can understand. I have several people who now call themselves DevOps on a project who have practically zero experience with systems operations _or_ development, and have done some utterly incomprehensibly stupid things. It doesn't matter how fancy y…

It happens quite a lot - nowadays services are deployed into the cloud where people are more security concious but when people deploy on-prem they are often more negligent

Interesting point. Does having physical access to the hardware make people feel overly secure?

Re: Equifax securities fraud class action [pdf]

#40

I'm using that headline as our thought of the day in group chat at work. Because that is just egregious and negligent. Nobody thought to raise that? to anyone? Although I can understand. I have several people who now call themselves DevOps on a project who have practically zero experience with systems operations _or_ development, and have done some utterly incomprehensibly stupid things. It doesn't matter how fancy y…

It happens pretty often. $thing is installed, individual user accounts are created, and the default login is forgotten about. Nobody uses it, so nobody noticed it.

Another variation is not even knowing default accounts exist. i.e. where there is a CLI command to add a new user, which was done during install.

This obviously isn't always the case - but it happens a lot.

Post reply on HN