I very nearly worked there in their engineering department, but once I got through the initial HR interview into the technical stuff, there were so many red flags that I got outta there as soon as I could. A few higher level people who were all let go with me ended up going there, and having met up with them a few times, I've heard some absolute horror stories about everything ranging from dev workload, to security,…
> there were so many red flags that I got outta there as soon as I could
Instead of joining the bashing party and lieu of making a broad statement why don't you detail what some of those red flags were?
Look up benchmarks for cracking MD5 hashes. You can crack an MD5 hash of an average length password (and StockX only requires an 8 character password), even with a salt , within seconds with a single consumer grade GPU. A hacker group with any serious setup for hash cracking has almost certainly already cracked most, if not all, of these hashes.
This is endemic to the FoC. When your entire team is recent boot camp grads, this is the end result. The engineering culture is a joke. (Source: former employee.)
What is "FoC"?
I think its "family of companies" which StockX is a part of.
> The stolen data contained names, email addresses, scrambled password (believed to be hashed with the MD5 algorithm and salted) This is absolutely atrocious if this is the case. MD5, even with a salt, can be cracked in a matter of seconds even with the most basic hardware. MD5 hasn't been an acceptable password hashing algorithm for at least a decade now, and StockX was created in 2015, long after the creators shoul…
> hashed with MD5, might as well be considered to have been stored in plaintext.
Somewhere I used to work (now-defunct) stored DES-encrypted passwords with the key one column over in the database.
This is every day now, right? Is anyone tracking those regularly? Less the passwords (haveibeenpwd does that well) than the executives? Does anyone loose their job over this? What does the email asking the engineer who rung the alarm to get lost read like?
Well the reporting of the breaches is more strange than the fact they happened. A platform like StockX should be a continual breach, because the information will let you make advantageous trades and time series against the customers. Its pretty dumb to even announce a past tense on this as if it was a single event.
> The stolen data contained names, email addresses, scrambled password (believed to be hashed with the MD5 algorithm and salted) This is absolutely atrocious if this is the case. MD5, even with a salt, can be cracked in a matter of seconds even with the most basic hardware. MD5 hasn't been an acceptable password hashing algorithm for at least a decade now, and StockX was created in 2015, long after the creators shoul…
Sounds alarming, but not true. If you don’t know the salt, you are not cracking an MD5 password on basic hardware . You are probably not cracking the password in any reasonable time, period. And when you have a unique salt per user, that’s basically game over.
That's 7.2 billion hashes per second per single Radeon GPU for md5. For 8 character password with numbers and letters that's 8.5 hours max and 4.25h on average.. The numbers only got better since then, I expect it's at least halved for this year's hardware. (edit: 1080ti does 32GHps, so yeah... make that 1h on average https://www.servethehome.com/password-cracking-with-8x-nvidi... )
Assumptions, not specified in the article:
- The salt is stored with the hash (this is a standard approach)
- It's only a trivial implementation with a single round of MD5. If they used multiple rounds or PBKDF1, then the hash choice doesn't matter as much.
Look up benchmarks for cracking MD5 hashes. You can crack an MD5 hash of an average length password (and StockX only requires an 8 character password), even with a salt , within seconds with a single consumer grade GPU. A hacker group with any serious setup for hash cracking has almost certainly already cracked most, if not all, of these hashes.
Unless you presume that you know the salt your comment is utter nonsense. 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.
> The stolen data contained names, email addresses, scrambled password (believed to be hashed with the MD5 algorithm and salted), and other profile information — such as shoe size and trading currency. The data also included the user’s device type, such as Android or iPhone, and the software version. The serious tone of this article made me double check if this was April 1st when I read this paragraph. The stolen dat…
We need to start charging companies with criminal negligence if they are not using secure password hashing algorithms. People reuse passwords and this leak puts other companies at risk.
they should be sued based on the number of breached records, period. let their insurance company dictate what hash algorithm to use. Damages would be automatically awarded to plaintiffs based on what data was breached. Just like a car accident: you destroyed my rear bumper, tail light, and window, the damages were $3200. Pay up.
Discussions regarding use of MD5 hashing is missing the point, Capital One and Equifax had plain text data exposed. The hashing strategy is irrelevant.
"Discussing one company's bad security is irrelevant because a totally separate company had even worse security"?
I very nearly worked there in their engineering department, but once I got through the initial HR interview into the technical stuff, there were so many red flags that I got outta there as soon as I could. A few higher level people who were all let go with me ended up going there, and having met up with them a few times, I've heard some absolute horror stories about everything ranging from dev workload, to security,…
I had a similar experience, but I made the mistake of taking the job. I spent several months in denial about how smart people who act so... not smart. At one point, I asked the CTO for guidance on how to work with the team architect whose feelings I kept hurting. For example, I wrote a constructor for a class, and the architect asked me what "def initialize" was for, and got upset when I asked if they knew how OOP in the language worked. Another time they asked me for help on a weekend to figure a null pointer error on a machine that wasn't running the software they were trying to debug, and got upset when I pointed that out. I brought up both examples to the CTO. The CTO pointed out that the Architect had 10 more years of experience than I did, and while I might be right, I probably wasn't. Then the CTO said (direct quote) "you have delusions of grandeur about your technical abilities" to my face. I started looking for a new job immediately after that conversation. After I left, I heard the project got canceled, the architect got promoted, and they were hiring devs straight out of bootcamps because they couldn't attract anyone with experience.