Live data from Hacker News

Hackers who broke into Equifax exploited a flaw in open-source server software

qz.com

71–80 of 84 posts

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#71
post #7

Earlier quoted context omitted.

Why do you hope that? Do you want them to be liable? If it was a zero-day then they legitimately may not be at fault.

Forget about the zero-day for a minute. They should be liable for poor storage practices around sensitive PII. Take for example SSN. With SHA2, there is no good reason for them to be stored in plaintext. If you don't need it, don't store it. For SSN, you just need a function (SHA256+Salt) that would give you a one way mechanism of Creating an identifier that masks the original in an irreversible way. The prevalence a…

If you're just hashing with SHA2 and a salt, an attacker with a run-of-the-mill GPU could crack any given hashing quite quickly. It might still take quite a bit of time to get all 143 million, but that's fine. Sell off the score in blocks of 10,000 and let the customer know they have to reverse the hashes themselves.

BCrypt with lots of rounds would be best.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#72
post #22
post #13

Earlier quoted context omitted.

> points away from a world where a hundred million people's private information is unavoidably vulnerable Regardless of this specific situation, we already live in this world. We all just need to get used to it.

So if someone takes this data and just keeps the whole dataset exposed publicly on a tor site, is that pretty much the end of data breaches? Like, some random website: "we just got hacked, all you pii was taken, but don't worry nothing thats not already available in that public database" other than new credit card #'s it'd be basically pointless right?

The fact that the pii existed is more systemic. We use social security numbers to verify identity and have a unique way of identify people across systems. If our current system of doing this (i.e. SSNs) are no longer reliable we will have to come up with something to replace it. If what we use to replace it is as brittle of a solution we will run into a similar problem down the road.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#73

Earlier quoted context omitted.

If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable. In either case, it's a very small amount of evidence anyway, but in that respect at least, hoping it wasn't a zero-day makes sense.

If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable. Working in the security industry quickly cures you of this illusion. It is unavoidably vulnerable in most cases. If someone wants to pop your network, they can usually find a way. The most clever code won't prevent someone from strolling in and p…

Let's not confuse physical access to getting it over the internet.

If they stayed old-school and had their computers inaccessible except to their own people, you'd have to make phone calls, fax, and mail to do anything with them. That would be less efficient - more costly - but it would prevent the possibility of a remote attack compromising huge amounts of data.

If we move up in abstraction, if these companies didn't exist and collect all the data the danger would be completely eliminated. OTOH the banks and lenders who use their services would have to find other ways to estimate credit-worthiness and that would again... cost more.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#74
post #71

Earlier quoted context omitted.

Forget about the zero-day for a minute. They should be liable for poor storage practices around sensitive PII. Take for example SSN. With SHA2, there is no good reason for them to be stored in plaintext. If you don't need it, don't store it. For SSN, you just need a function (SHA256+Salt) that would give you a one way mechanism of Creating an identifier that masks the original in an irreversible way. The prevalence a…

If you're just hashing with SHA2 and a salt, an attacker with a run-of-the-mill GPU could crack any given hashing quite quickly. It might still take quite a bit of time to get all 143 million, but that's fine. Sell off the score in blocks of 10,000 and let the customer know they have to reverse the hashes themselves. BCrypt with lots of rounds would be best.

Yes. You're correct of course. We should be treating these like passwords, except that they can't be rotated...

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#75
post #7

Earlier quoted context omitted.

Why do you hope that? Do you want them to be liable? If it was a zero-day then they legitimately may not be at fault.

Forget about the zero-day for a minute. They should be liable for poor storage practices around sensitive PII. Take for example SSN. With SHA2, there is no good reason for them to be stored in plaintext. If you don't need it, don't store it. For SSN, you just need a function (SHA256+Salt) that would give you a one way mechanism of Creating an identifier that masks the original in an irreversible way. The prevalence a…

It is an identifier. It isn't really a problem to use it that way.

The problems all come from using it for authentication.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#76

Earlier quoted context omitted.

If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable. In either case, it's a very small amount of evidence anyway, but in that respect at least, hoping it wasn't a zero-day makes sense.

If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable. Working in the security industry quickly cures you of this illusion. It is unavoidably vulnerable in most cases. If someone wants to pop your network, they can usually find a way. The most clever code won't prevent someone from strolling in and p…

Yeah, I know and I agree. That's where the "very small amount of evidence" comes into play. A slightly better point is how this acts as evidence for how unavoidably vulnerable we are.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#77
post #55
post #43

I find the title irritating, as it seems to impugn open source software as a category. Why is the licensing model even relevant? A better phrasing would be something like "...flaw in a popular web framework" or "...flaw in Apache Struts."

> Why is the licensing model even relevant? Licensing model directly affects the availability of source code, and this technically facilitates exploit discovery.

That's a very dubious claim, as it depends on the largely debunked idea of "security through obscurity." Bruce Schneier: https://www.schneier.com/crypto-gram/archives/2002/0515.html...

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#78
post #77
post #55

Earlier quoted context omitted.

> Why is the licensing model even relevant? Licensing model directly affects the availability of source code, and this technically facilitates exploit discovery.

That's a very dubious claim, as it depends on the largely debunked idea of "security through obscurity." Bruce Schneier: https://www.schneier.com/crypto-gram/archives/2002/0515.html...

I am not saying that closed-source software is more secure. I am saying finding exploits when the source code is available is definitely easier.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#79

Earlier quoted context omitted.

Forget about the zero-day for a minute. They should be liable for poor storage practices around sensitive PII. Take for example SSN. With SHA2, there is no good reason for them to be stored in plaintext. If you don't need it, don't store it. For SSN, you just need a function (SHA256+Salt) that would give you a one way mechanism of Creating an identifier that masks the original in an irreversible way. The prevalence a…

It is an identifier. It isn't really a problem to use it that way. The problems all come from using it for authentication.

I should have made that more clear in my statement. The thing that makes me paranoid is it's use as an authentication method by my bank, et al.

With this disclosure, much of what banks and others use to authenticate my identity is now out in the open.

Re: Hackers who broke into Equifax exploited a flaw in open-source server software

#80
post #78
post #77

Earlier quoted context omitted.

That's a very dubious claim, as it depends on the largely debunked idea of "security through obscurity." Bruce Schneier: https://www.schneier.com/crypto-gram/archives/2002/0515.html...

I am not saying that closed-source software is more secure. I am saying finding exploits when the source code is available is definitely easier.

Ah. Yes, I suppose. As it is easier to find exploits in service of closing them as well as in using them (security researchers seem to mostly come down on the side that this averages out as more secure). If that's what you meant, I apologise for the misinterpretation. This particular article doesn't make that point, though, so I remain with the feeling that mentioning the license model in the title is irrelevant and a bit misleading.
Post reply on HN