4 ms·

Relatedly I discovered that a credit freeze with Equifax means exactly nothing. Apparently all it takes to lift a freeze with them is your name, address, SSN,

Relatedly I discovered that a credit freeze with Equifax means exactly nothing. Apparently all it takes to lift a freeze with them is your name, address, SSN, and phone number. They do not ask for the pin that was setup. They don't do any other verification. That's all you need. At least, that was the case when I did a temporary lift the other day. Imagine my horror when I sat there, pin in hand ready to punch it in, only to be presented with the successful lift screen already... > He believed Equifax suffered a cybersecurity breach because of a “sophisticated” and “highly motivated” adversary. Given my experience above, I very much doubt there was any sophistication required. You can probably go to Equifax's admin page and just punch in the name of the CEO, telephone and address for Equifax's HQ, and be on your merry way.

g051051 7y ago
This is the best, least biased write-up of the breach that I've seen. It's still fairly damning, but the upshot is that it took a very serious second attack team to actually capitalize on the flaws that were present: https://www.bloomberg.com/news/features/2017-09-29/the-equifax-hack-has-all-the-hallmarks-of-state-sponsored-pros https://www.bloomberg.com/news/features/2017-09-29/the-equif...
- x0x0 7y ago
  Or it's a pile of nonsense from a company desperate to deflect blame. How could poor poor Equifax defend itself against foreign governments? The reality is Equifax are lazy stupid idiots who * couldn't patch well known holes in infra for months (note that a 2 engineer startup could do better by eg running rails and checking bundler-audit on every deploy); * disabled their IDP because they didn't keep a cert up-to-date; * didn't notice their disabled IDP FOR 10 MONTHS because lazy stupid incompetent; * strongly appear to have no internal access controls, so regular app users in the db could exfiltrate the entire DB without creating any internal alerts In contrast to the self-serving nonsense in the Bloomberg article, there was nothing sophisticated here. These people couldn't get the most basic things right, all part of the most very basic security posture: patch known holes. Regularly verify such patching. Run an IDP. Verify the IDP is running. Have controls around odd behavior or bulk queries for the DB users running on your front-end boxes.
  - g051051 7y ago
    > Or it's a pile of nonsense from a company desperate to deflect blame. How could poor poor Equifax defend itself against foreign governments? Bloomberg has plenty of criticism, they just don't wrap it in the shrill click-bait headlines of other "news" outlets. > note that a 2 engineer startup could do better by eg running rails and checking bundler-audit on every deploy) On systems a fraction of the size, with a fraction of the traffic, and not under a constant withering assault from hackers.
    - x0x0 7y ago
      the point -- which I believe you deliberately missed -- is the tools are available from the very beginning to know if you are shipping code with known CVEs. It's easily available. I'm not sure why you're invested in pretending this is super hard, or that it isn't extremely easy to do correctly if it is a company priority to do so. As their scale, it's also straightforward to build and maintain the list of sites you're running, what's running them, and the versions of libs in place. Particularly because you can have dedicated engineering for the above. It really comes down to whether it's a corporate priority or not.
      - g051051 7y ago
        > I'm not sure why you're invested in pretending this is super hard, or that it isn't extremely easy to do correctly if it is a company priority to do so. The enormous amounts of money and time that companies spend on this problem, and still not get it right, disproves your assertion of simplicity.
        x0x0 7y ago
        And yet there's lots of examples of companies that aren't trivially breached, and can promptly roll patches for CVEs.
        g051051 7y ago
        And just as many that are breached in spite of their best efforts. Perfect security is impossible.
deleted 7y ago
[deleted]
techslave 7y ago
we’re you logged into your “my equifax” (or whatever) account? if so that’s true. krebs blogged on this soon after the breach. if you just mean in some kind of “cold” browser, eg incognito mode, that wasn’t my experience.

g051051 7y ago

This is the best, least biased write-up of the breach that I've seen. It's still fairly damning, but the upshot is that it took a very serious second attack team to actually capitalize on the flaws that were present: https://www.bloomberg.com/news/features/2017-09-29/the-equifax-hack-has-all-the-hallmarks-of-state-sponsored-pros https://www.bloomberg.com/news/features/2017-09-29/the-equif...

x0x0 7y ago
Or it's a pile of nonsense from a company desperate to deflect blame. How could poor poor Equifax defend itself against foreign governments? The reality is Equifax are lazy stupid idiots who * couldn't patch well known holes in infra for months (note that a 2 engineer startup could do better by eg running rails and checking bundler-audit on every deploy); * disabled their IDP because they didn't keep a cert up-to-date; * didn't notice their disabled IDP FOR 10 MONTHS because lazy stupid incompetent; * strongly appear to have no internal access controls, so regular app users in the db could exfiltrate the entire DB without creating any internal alerts In contrast to the self-serving nonsense in the Bloomberg article, there was nothing sophisticated here. These people couldn't get the most basic things right, all part of the most very basic security posture: patch known holes. Regularly verify such patching. Run an IDP. Verify the IDP is running. Have controls around odd behavior or bulk queries for the DB users running on your front-end boxes.
- g051051 7y ago
  > Or it's a pile of nonsense from a company desperate to deflect blame. How could poor poor Equifax defend itself against foreign governments? Bloomberg has plenty of criticism, they just don't wrap it in the shrill click-bait headlines of other "news" outlets. > note that a 2 engineer startup could do better by eg running rails and checking bundler-audit on every deploy) On systems a fraction of the size, with a fraction of the traffic, and not under a constant withering assault from hackers.
  - x0x0 7y ago
    the point -- which I believe you deliberately missed -- is the tools are available from the very beginning to know if you are shipping code with known CVEs. It's easily available. I'm not sure why you're invested in pretending this is super hard, or that it isn't extremely easy to do correctly if it is a company priority to do so. As their scale, it's also straightforward to build and maintain the list of sites you're running, what's running them, and the versions of libs in place. Particularly because you can have dedicated engineering for the above. It really comes down to whether it's a corporate priority or not.
    - g051051 7y ago
      > I'm not sure why you're invested in pretending this is super hard, or that it isn't extremely easy to do correctly if it is a company priority to do so. The enormous amounts of money and time that companies spend on this problem, and still not get it right, disproves your assertion of simplicity.
      - x0x0 7y ago
        And yet there's lots of examples of companies that aren't trivially breached, and can promptly roll patches for CVEs.
        g051051 7y ago
        And just as many that are breached in spite of their best efforts. Perfect security is impossible.

deleted 7y ago

[deleted]

techslave 7y ago

we’re you logged into your “my equifax” (or whatever) account? if so that’s true. krebs blogged on this soon after the breach. if you just mean in some kind of “cold” browser, eg incognito mode, that wasn’t my experience.