StockX was hacked, exposing millions of customers’ data

We know people reuse passwords. This is a non-negotiable threat model for any user-facing system. Given this, one should make password-decryption as hard as possible. MD5 is just not good enough by any standard, in 2019.

We used to joke that working in security was always chasing "zero". If you've done your job perfectly, an attack isn't successful, just like every other day. If they had stored passwords properly and had the various other layers worked out, the attempt on the environment might not even have been seen[0]. It's an easy thing to put off when all you're looking at is today's balance sheet. For months/years[1], the site hummed along without a breach[2].

Now you're the head of security, you make a whole bunch of points about the risks discovered within all of the systems. The person who holds the purse strings reads each risk (in a vacuum, of course) and sees each individual risk as minor, plus that new feature will bring in revenue while spending money on security only causes a fuzzy category of "cost avoidance". Forget about the fact that convincing the low-level non-technical purchasing manager is going to be a whole lot easier than when he/she takes that same justification to a C-Level executive.

When the problem isn't understood, it looks a lot like a choice between spending money to reduce a risk (that the audience is going to under-estimate) versus spending money to give customers a new feature. Do customers want security? Sure, they say they do, but most of your users use the same password everywhere despite years of being told not to. They think that breaches are routine and that if their account is breached that it's probably not going to matter[3]. It all speaks to an expectation of security (a baseline, a 'zero'). It's somewhat ironic that users take security as seriously as typical developers/maintainers.

And then there's the core problem of securing a system. It's a problem who's solution has a variable half-life. To prevent a hack, you have to be right 100% of the time, to be a successful hacker, you have to be right once. There is no limit to the amount of money (good money after bad) that you can spend securing your systems and you can spend all of it on that and still fail. It's been my experience that when defining success is difficult, and the amount of money that is required to be spent to achieve success has a large range, the amount of money spent will be the lowest amount suggested by the first person who can convince management that their solution is "good enough"[4]. It's also easy to look at logs, see a bunch of dropped packets/thwarted attacks and jump to the wrong conclusion that "our defenses are working just fine as they are[5]" rather than "wow, we're under constant attack, unrelenting attack!" Of course, if your physical home was attacked as much as your web application, you're more likely to put up a stone wall/fence rather than be thankful that nobody has figured out the out to breach the 5-tumbler dead bolt that anyone with an internet connection can learn how to breach.

All of that said, it hurts to write this. I'm from the metro Detroit area. StockX recruits like crazy over here and as a result I have a number of friends who work at the company. At least of the people I know, they've got some great developers over there[6] -- we've all had more than a few hundred conversations about best practices around password handling (frequently centered around "don't if you don't have to").

[0] Sure, they could be logging every dropped packet, but even then.

[1] Not sure how long StockX has been around but they employ a lot of my friends.

[2] As far as anyone knows. It sounds like the breach was discovered not by internal monitoring but by the existence of credentials for sale.

[3] I've had my account credentials published several times, I've had my SSN published publicly on a web site (in 1998). I'm actually surprised I have had little in the way of attempts on my credit.

[4] We salted our hash and have appropriate ACLs set up on the database. Our application firewall prevents all but our corporate IP and the web host from attaching to the database. Sure, there's a lot of IP addresses that exit that proxy. We also use MD5, but the salt protects us from rainbow tables and the other protections should add enough layers to the onion. I mean, after all, an attacker will just move on to an easier target when they hit (pick one of the three defenses).

[5] That ranks right up there with "That's what we have business insurance for!"

[6] Can't pick on them too much; all of them are recent hires and would have been unlikely to have the authority to do much about it (or even the knowledge of the code-base required to identify that anything had to be done)

What now? What do MD5 collisions have to do with passwords?