News Insights: J.Crew says a hacker accessed customer accounts – TechCrunch

Cybersecurity experts reacted late today on news that J. Crew has filed a Notice of Data Breach with the State of California that customer accounts were compromised by credential stuffing. It happened about a year ago, but they’re just now disclosing it (see J.Crew says a hacker accessed some customer accounts).

Paul Bischoff, privacy advocate at Comparitech:

If businesses don’t start forcing users to set up two-factor authentication for logins, then they’ll have little defense against credential stuffing attacks like these. Credential stuffing attacks succeed because customers reuse passwords across multiple accounts. That means if one of their accounts is compromised, all of the accounts that use the same password are potentially compromised as well. J. Crew can’t force its customers to use unique passwords, but it can require them to set up 2FA. 2FA requires a second form of authentication, usually a one-time PIN number, to log in from a new device. These PINs are sent via authenticator app (most secure), SMS, or email (lease secure). I think businesses have been slow to adopt 2FA because it’s more inconvenient for customers, but it’s preferable to customers getting hacked.

Jonathan Deveaux, head of enterprise data protection at comforte AG:

“Retailers are huge targets for bad actors due to the type and amount of data they process.  They’re looking to retain their existing customers and gain new ones, therefore harvesting data is the key.  Years ago, retailers were targets only for their credit card data.  Today, they possess a lot of intel on their customers, primarily personal information (name, home address, email address, etc).

Every retail organization faces the same attack exemplified in the J. Crew data breach notice. User IDs from one retailer, can be the same User IDs utilized by other retailers.  john.doe@email.com, for example, can be used at one to many retailers, depending on the end-user.  Therefore, if a bad actor can access and exfiltrate a database full of User IDs (along with passwords) from one retailer, then it is possible that those same User IDs and passwords may work at another retailer.

There are two points of view to help reduce this problem.  One view is from the consumer end, the other is from the retailer.

The end-customer (that includes me, you, and anyone else who accesses any type of account online) should really consider using different user IDs and passwords per online account, activating multi-factor authentication, and initiating password refreshes at least monthly.

Retailers can consider data protection/privacy solutions such as tokenization or format-preserving encryption to help greatly reduce the likelihood of credential stuffing.  If a consumer uses john.doe@email.com, when Retailer A uses tokenization, the User ID could be randomly be tokenized internally as qwer.o3c@email.com. When the same consumer goes to Retailer B who also deploys tokenization and enters john.doe@email.com, the User ID could be randomly be tokenized as lkjf.zxc@gmail.com. Files containing passwords can be protected in the same way.

As a result, if a bad actor gets past network defenses and intrusion detection, the data they access is worthless because the sensitive/usable data has been replaced.”

Chris Rothe, chief product officer and co-founder of Red Canary:

“According to J. Crew, they discovered this through “routine and proactive web scanning.” I read that as they (or a third-party) monitor various places on the internet and dark web and found some of their data. At that point they likely did an investigation to confirm a breach occurred and figure out when. Then they would have declared it a “breach” and entered their breach notification process.

This is an interesting aspect of breaches that I don’t think most people realize. The time from when a breach is discovered to when it is disclosed can be a long time depending on how difficult the investigation is, how sensitive the data is, etc. As a J. Crew consumer I may have an expectation that if someone compromises my account, the company will tell me immediately. The reality is it could take a very long time especially for organizations with weak detection and response capabilities.”

Jason Kent, Hacker in Residence, Cequence Security 
We see this every day, an application that doesn’t have protection against rapid credential testing. The attacker generates a list of usernames that work on an application. Once the usernames are known the attackers test large numbers of passwords they have found or created. Eventually the attacker learns the usernames and passwords of several accounts and in the next phase they attack. Both the testing and the attack are noisy but often we find organizations aren’t instrumented to see the testing and attack phases.

The challenge is that this type of vulnerability is often considered low risk because it is up to the user to have a good password, change it regularly, include special characters, etc… In this case its easy to see that even though the user has some responsibility, the system shouldn’t be built in such a way that an attacker can test credentials and later construct and automated attack that isn’t noticed. Attacks against the API of a mobile application often is difficult to see happening because the design of an API normally includes ability to be extremely fast and thousands of transactions per second are possible. Knowing where these types of attacks can occur, instrumenting those endpoints to block automated attacks is the best prevention.