Hacker News new | past | comments | ask | show | jobs | submit login
StockX was hacked, exposing millions of customers’ data (techcrunch.com)
142 points by rmason 78 days ago | hide | past | web | favorite | 102 comments



> ...The company “robbed their users of the chance to evaluate their exposure” by not informing customers of the breach when it happened...

StockX is valued at $1B and aside from their cataclysmic choice of using MD5 + salt as their way of hashing passwords (They obviously don't take security seriously) the company failed to inform their customers of this security breach as soon as it happened and left it very late for the customers to change their credentials. I would expect any unicorn valued company to have some form of incident-response system to immediately inform staff of the breach and to instantly reset all user credentials and to notify their users.

Instead they didn't inform their customers after the breach and now someone is calculating all those MD5 collisions and attacking all accounts with common passwords.

In the case of StockX handling this security breach, this is un-professionalism at its finest.


Jeez. Even coding bootcamps teach developers to use at least bcrypt for passwords.


Then they get into I dustry and get told that getting stuck in the weeds of security isn't something which generates value


You nailed it.

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)


It’s just a Wordpress site using ancient defaults. It’s not exactly a technology business.


It sure looks like Wordpress, but are you sure? They don't have the wordpress login page at /wp-login.php and I don't see references to /wp-* in the source.


I haven’t looked at the site myself yet, but renaming those is sometimes used a security through obscurity.


And not such a bad idea, either! I use Wordpress just for a company landing page, and moved all the defaults. It took probe attacks down to almost nothing. It used to get probed all day long for Wordpress unpatched bugs in both Wordpress and popular plugins. The scripts all give up after getting 404 on the usual pages.


> calculating all those MD5 collisions

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


you don't need the password, you just need a string that when hashed produces the same hash as the password e.g. the hash of "insecurepass123" has a hash of 79054025255f, which is the same hash as "%AZQ%ɟr7<[؂>1V4[m6S49cH͠3BW".

If you know the hash is, either will match the hash.


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, to extremely unqualified devs being hired to fill seats.

I'm not surprised by this in the least, and frankly, I'm surprised it's not worse.


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.


I used to work closely with Quicken Loans and other FoCs and can attest that this behavior is commonplace. There is this strange culture within the Family of Companies where non-tech leaders think that tenured Quicken engineers and tech people are these sort of super-geniuses. Many years back I was a part of a company in the Quicken led start-up space. We were often "encouraged" to meet with Quicken or FatHead senior engineers for advice. One time I reluctantly agreed and met with "the best programmer in Michigan" who's first piece of advice was:

"Delete your app and start over. Ruby on Rails is trash. Real programmers use C#. With C# you can create libraries that you can reuse across all your apps."


While I don't agree with the way he spoke, was C# one of the de facto or explicit in-house languages of the company, and Ruby was not? If so, he may have been referring to the fact that the company already had many libraries in C# that you could use. Plus, if C# was one of their areas of expertise, it's typically best to use that as opposed to a new, unfamiliar language unless you're explicitly testing out a new approach.

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.


>While I don't agree with the way he spoke, was C# one of the de facto or explicit in-house languages of the company, and Ruby was not? If so, he may have been referring to the fact that the company already had many libraries in C# that you could use. Plus, if C# was one of their areas of expertise, it's typically best to use that as opposed to a new, unfamiliar language unless you're explicitly testing out a new approach.

[...]

>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#.

According to the parent comment, he was working at a startup that was in the "Quicken led start-up space". My interpretation is that Quicken was acting like an incubator, and he isn't working in quicken, and so the engineering teams are separate. Therefore I don't think organizational inertia applies here.


This is correct. Our company was under the Quicken "Family of Companies" umbrella, but we were a 5 person start-up building a web app unrelated to Quicken.


It sounds like they were pretty well-integrated into Quicken engineering, although we'll have to hear from the OP to know for sure.


Yikes. I worked on a team whose de facto tech lead (it wasn’t explicit because we were “flat”) had no idea what SQL parameter binding was (I had to explain why interpolating strings in SQL queries is dangerous). And we apparently went to the same university and got the same degree, and he had at least ten years of “industry experience”.

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.


What on earth is a ‘family of companies’? Googling for it just gets me some sort of crane conglomerate.



Huh, that’s a bit of a random collection of stuff.


Rock Ventures, http://www.rockventures.com/ , was founded by Quicken Loans billionaire Dan Gilbert.


Wow that is so sad/hilarious.


Sounds like you dodged a bullet.

Did you end up working at another Fashion-Tech company? I'm curious how much of this is characteristic of Fashion-Tech industry in general.


I dodged a bullet indeed. Out of the dozen other devs there, there was exactly one person I'd care to work with again. They got pushed out a month or two later, and post-shenanigans felt infinitely better.

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.


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.)


I'm a current employee in the FoC (just not StockX), and with more than a decade in software development, I am easily the least experienced on our team by several years.


What is "FoC"?


I think its "family of companies" which StockX is a part of.

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


They are so many of them!


> 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?


I got an email 3 days ago asking me to reset my password due to "system updates" and initially assumed it was just a phishing email. Since gmail is pretty aggressive about filtering those I looked into it more and realized it was genuine which made me even more confused because I couldn't imagine what sort of "system updates" they could've done that would require a password reset for all users. I kind of assumed they were covering up a breach so I wasn't at all surprised to see this headline. How scummy.


I thought the same thing when I received it. However, at the end I gave them the benefit of the doubt that perhaps they were migrating from one hashing algorithm to another and decided to just reset everyone's password in the process. Lying about the breach entirely is so shady


I had the same reaction to the email


> 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 data is shoe sizes? MD5 hashing for passwords isn't ideal, especially combined with email addresses - that could lead to some email accounts being accessed if people use the same password for everything. The article seems to not really give much attention to this though, not clear if the author even realises this is the main problem.


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.


That would be a civil case prosecuted by the other companies, not a criminal case.


It should be criminal.


People that re-use passwords should be considered negligent. There is no reason to do so for anything but the most trivial logins.


Good luck proving that a "reasonable person" shouldn't have done it. Most people on HN probably do, but I wouldn't be surprised if everyone coming out of a 3 month coding bootcamp only knew to hash passwords and nothing else. The other comments in this thread seems to suggest that the company is filled with bootcamp programmers.


As a government body actually publishes advice on this, NIST [0], it may well be possible to argue for what is reasonable in a court of law.

[0] https://csrc.nist.gov/projects/hash-functions/nist-policy-on...


I just googled how to store passwords in a DB and the first result said I shouldn’t use MD5 or SHA. Reasonable person would do a cursory search for information if they didn’t have the knowledge. I am willing to bet they knew better. When I worked for a company that stored passwords in clear text, we knew it was wrong but never prioritized fixing it. If the execs would have faced jail time, I bet it would have been prioritized.


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.


You can't sue a company for your own bad security practices.


> The stolen data is shoe sizes?

StockX is a platform for trading shoes, among other things.


I never heard of them before, so I checked Wikipedia and read this:

"The platform works by buyers undercutting each other in a fashion similar to the stock market, eventually causing limited items to lose all value. "

Can someone elucidate how this is like the stock market, because I don't get it.


Wikipedia gives a terrible description.

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.


Well, every data helps if you're trying some targeted hacking. If the username is LebronJames and the shoe size is 9, it's not the right Lebron...


Author might be a young intern writer.


My bad. He isn't. I suppose this was a 'strictly news' piece. Separate analysis coming soon.


> 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 should have known better (sadly, despite this, an absurdly high number of companies still use MD5 for pass hashing).

These passwords, hashed with MD5, might as well be considered to have been stored in plaintext.


Given that data, doesn't their attempt to call this "system updates" constitute a violation of California's data breach notification laws? https://oag.ca.gov/privacy/databreach/reporting


Oh man this is an interesting grey area. If the data was “encrypted” then they aren’t required to notify unless the encryption key is reasonably believed to have been acquired by the hacker.

I don’t know anything about MD5 or what makes it vulnerable but if StockX has no reason to believe the hacker acquired the key they could certainly make the argument they had no notice obligation.

Reading the statute (and assuming MD5 is as weak as everyone here says) I would say it falls outside the definition of “encrypted” but it really kind of depends on how honest the security engineers were with the lawyers.

I’ve never thought to ask “how encrypted?” when dealing with a breach but I definitely will now.


The non-password data was not encrypted, so is definitely a breach of California law.


Ahh well then it’s definitely not grey. And serves me right for scanning the comments here and not actually reading the article.


MD5 is not an encryption algorithm. There is no key!


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.


In 2012: https://www.zdnet.com/article/25-gpus-devour-password-hashes...

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.


Those time periods also assume that you're just blindly cracking every possible 8-character combination, but you don't have to do that. Running your cracker against a password list like rockyou will probably get you 90%+ of passwords cracked in less than one second per hash with that same hardware.


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.


Show me the benchmarks.


https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...

Looking at phpass (one of the md5 algorithms), a high-end GPU can do 7M hashes per sec.


If StockX was using phpass (which is a KDF that uses MD5 as a base but adds multiple permutations on top), it is quite a bit safer (but still not recommended and these hashes should be considered to be compromised).

The bigger issue is if they were actually using raw MD5 (which is sadly quite common), which is benchmarked at 25 billion (with a B) hashes per sec per GPU.


nowhere in these benchmarks anyone said the MD5 were salted. am i reading it wrong?


Unless you're operating under the (likely incorrect) assumption that the salts aren't leaked than salting the password doesn't matter for attacking a single user - it just means you can't reuse your results for other users.


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.


If the passwords have leaked it's safe to assume the salts have, typically they're stored side by side.


If the hash has been leaked then why is there reason to believe the salt _hasn't_ been leaked?


>Unless you presume that you know the salt your comment is utter nonsense.

Usually the attacker will also know the salts in a breach of this type, unless the company did something clever with the salts (doubtful since they used MD5).


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.

We don’t know how the passwords are hashed. All we have is a journo guessing.


Usually the salt is stored along the login and password.


That’s not on the list of things stolen, so the passwords are safe. The salts were kept elsewhere, as they should be.


The article doesn't mention customer id and account creation date, though these records were almost certainly along the login and passwords also. It's general news article.


Do you have some insider information, or where are you getting this? If the hackers were able to steal all of the other login information, the salts were almost certainly stolen along with the hashes.


Why should salts be stored elsewhere? If you have some high-security other storage, why don't you store the password hashes there?


You need to update yourself on the vulnerability of MD5.

5 years ago, a run of the mill gaming PC could crack an MD5 hash in a reasonable amount of time. Worst case, you'd have to let it run overnight.

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.


> Worst case, you'd have to let it run overnight.

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.


> 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.


I used to work at a Dan Gilbert Quicken Family of Companies company, and I am not the least bit surprised by this, especially the abysmal choice to use MD5. Let’s just say, the engineering chops across the family of companies is... mediocre, at best.


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 don't see where you're coming from at all.


There are two topics that are HUGELY overrepresented in discussions of computer security: password complexity and password hashing.

MD5 hashes is not good. But it also isn't catastrophe level security. If you aren't reusing passwords then the hashing choice doesn't matter since the system has already been breached. If you are reusing passwords you don't exactly want to rely on bcrypt hardness to keep you safe.

If I could make the web services I use switch to MD5 hashes and spend more time on other relevant security posture, I'd very seriously consider that.


This is bad advice and you should feel bad.

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 do know this. And we can also choose how we spend our energy on education and outreach. IMO, we should be pushing password managers and 2fa as hard as humanly possible. People can only integrate so much security advice. If I'm providing guidance for a business that wants to improve the security posture of its users, I'd tell them to make 2fa integration as easy as possible and to encourage their users to use password managers before spending time on the particulars of the cryptographic storage of passwords.


We're talking about poor security practices that lead to increased risk to consumers right? Doesn't hashing fall within that? I didn't see anybody claiming that was the only factor, it's just one that stick out.


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.


a time series of... shoes?


Most people who use StockX buy limited release sneakers that you can no longer get via retail. Prices go up and down depending on demand and scarcity (think eBay.) It may seem silly, but certain designs can go for a lot of money ($1,000+).


Yes of shoes, who buys who is trying to buy, position sizes, limit orders placed by user


I expect a lot of downvotes for this post from people who have not had experience working with people in fashion.

Investors should be weary of people from the fashion industry. I say this as someone who has both a computer science degree and a fashion design degree, and 90% of my friends were in the fashion industry at some point. Coming from tech, you'll find people here are much flakier and just unreliable. In the NYC fashion scene in particular, people have huge egos and they don't always act out of pragmatism or logic. The tendency to keep up appearances manifests itself in many ways. Look at Barney's, it appears great on the outside, but recently considered bankruptcy before receiving a capital injection.

Recently, I went into one of the top streetwear brands in the world, a staff member tried to start a fist fight with me after a piece of paper fell out of a hat, and I refused to pick it up and told them to screw off after the guy tried to disrespect me in front of my girlfriend. I've never been to a retail store where a staff member told a customer "meet me outside p___y", but that is the nature of streetwear culture in NYC. In case you aren't aware, these streetwear stores in NYC have BOUNCERS. Let that soak in. They're just accustomed to bullying customers because people are so desperate to buy clothing that they are willing to put up with the nonsense. They particularly like to single out mainland Chinese who don't realize (or maybe don't care) when these staff are disrespecting them, and, since I'm Asian, the guy who picked the fight thought I would not stand up for myself. If you want more examples of ridiculousness of streetwear, search "ym bape compilation" on YouTube. This dude loves the clothing brand called "Bape" and goes around and assaults everyone he sees wearing the brand Supreme.

There's economic demand and money to be made here, but just know the demographic you're dealing with. The customers and investees are of the same thread. I'm looking to start a fashion tech company myself, and aren't intimidated by potential competitors considering how disjoint these two worlds are, both network-wise and culturally. The typical engineer won't see the value of all this vain-ness, and people in fashion business aren't always the most reasonable people. A UX designer I work with recently told me a story of how they were redesigning a website for a top fashion brand, and the brand requested they make the shopping experience as UN-usable as possible and difficult for people to actually make a purchase (but it works I guess). At any rate Investors, find a leader who can bridge that gap while still being able to attract engineering talent.

Don't get me wrong, you can fund leaders in the FashionTech who are completely unreasonable, and even incompetent, but the company will still do well since product-market fit and demand will outstrip all other factors, until something like this happens. One of my professors owns a set of retail stores in NYC that was acquired by one of the largest clothing manufacturers in the US, but they did not know a single thing about accounting, business operations, engineering, and non-artistic things. Super unreliable, super unprofessional professor but they had a really good intuition for branding.

Luxury brands, corporations (Adidas, Nike), and the LVMH conglomerate are a slightly different story


This comment plays into some awful streetwear stereotypes. "ym bape compilation" is about as representative of streetwear as a video of Raiders fans rioting is representative of professional sports, if not less so. Sure, there are some assholes. Where aren't there?

I think the sort of behavior you describe can happen with any sort of niche or exclusive retail. It's not particularly fair to single out streetwear here, which already has a negative stigma in many circles.

I'd assume the bouncers would be there primarily to prevent shrinkage. Seems reasonable to have people around to ensure running off with hundreds of dollars of clothing is less attractive of a proposition. Sorry you had to deal with that confrontation either way, though.

I'm curious how much of the flakiness attributed to fashion applies to other arts or arts-adjacent areas.


Whose hat did the paper fall out of?


The store's. I put the hat on while I continued shopping. I had every intention of buying the hat, but apparently the paper fell out. The employee came to me fist-clenched, with a fighting tone. I'm sure you're skeptical and think there's two sides to every story, but I don't want to expand too much on the story for privacy and retaliatory concerns. I invite you to come to SoHo, NYC and visit a few stores if you have any doubts.


I've lived in NYC all my life and am familiar with the scene.

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.


> Did they ask you nicely (initially) to pick it up?

Nope. It was "Are you going to buy that?" and other rhetorical heckling questions. I said "yes" and didn't give them the attention they want. Eventually, looks over to my girlfriend, turned back to me, and commands me "go pick that up". If they simply asked "did you drop that?" I would have immediately said "oh, sorry, I didn't see that" and done so.


I see. Typical territorial domineering of an immature ego.


In every other sane retail environment, this should have never happened at all, regardless of how rude the customer is, unless they're being racist or intentionally degrading or belittling the staff.


arent they a quicken family company?


Yep


Can't believe something like this (md5) wasn't flagged during tech diligence by any of their investors (GV, General Atlantic, Battery, DST Global, etc)...


The interesting part to me was that this happened in May, and they closed $110MM in funding a month ago. That could explain quite a bit.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: