StockX was hacked, exposing millions of customers’ data

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)

https://www.quickenloans.com/about/partner-company "

Also, in general, for programming in the large, many experienced programmers, having worked on multiple large-scale software projects, tend to prefer statically-typed languages. We've found by experience that in such large-scale systems, major refactorings are much, much smoother and feasible in statically-typed languages (although unit and integration tests are certainly still needed). And a whole class of errors are eliminated.

I don't think RoR is trash, but if you were starting a large program that would be used across multiple departments whose in-house language was C#, it was probably the right call to suggest switching to C#.

Please note: I'm not a C# programmer, and have never done any work in C# (although I've worked many dynamically-typed and statically-typed languages, and have a clear preference for the latter for large-scale software projects). So this isn't something I have any personal investment in.

Finally, I do get it, working for these types of companies is misery for most programmers. I've worked in such companies. But in this case, the senior may have had a good point.

I’ve also had to explain why logging is a good idea and how to use SSH. What frustrates me isn’t that people don’t know these basics (nobody is born an expert), but that people get hired to do a job for which they lack core competencies. If your job is to fix engines and you don’t know what a spark plug does, you probably shouldn’t be fixing engines. This was at least an issue for me. I know people at Quicken proper who have told me even more ridiculous stories.

It’s a shame. Detroit’s got a lot going for it, but I think most of the tech companies there have some connection to Gilbert and Quicken, and no amount of coneys will get that taste out of my mouth.

My advice is to do what you gotta do to pay the bills, but don't delude yourself into thinking that a crazy sauce employer will change its ways because you try extra hard to change them when they resist your attempts to do so.

It's basically eBay, but focused specifically on limited release/high value fashion - sneakers, bags, streetwear, eatches, etc. Since the market rate for these items changes over time, the gimick (hence the name) is to track them like stocks.

Stockx basically facilitates the sale and exchange of items, taking a cut of the sale and verifying the integrity of the items.

The fact that the article says “believed to be” strongly suggests that things are not as simple as they’re “believed to be”, because if the passwords were easy to crack that’d be trivial to prove.

AFAIK the best current preimage attack against MD5 gives you a complexity of 2^123.4. Even if you had every computer in the world working on this you'd never succeed.

>One of the big issues is collisions. You might not find the original key, but you'd find something that hashed to the equivalent output.

This is false. There does not exist a feasible preimage attack against MD5.

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.

Did they ask you nicely (initially) to pick it up? What was the tone of your response? These are two missing clues on how this might have gotten started.