Lakeland hacked, all customer passwords deleted

Updated happygeek 1 Tallied Votes 399 Views Share

UK home shopping pioneers Lakeland have sent an email to all customers past and present to warn them that the retailers website has been hacked. What Managing Director Sam Rayner calls a "sophisticated and sustained attack" took place late on Friday 19th July. Measures were taken at the time to block that attack and repair the system, however the ongoing investigation has revealed that two encrypted databases were compromised.

In that email to customers, Rayner states that the company has been "unable to find any evidence that the data has been stolen" but nonetheless has taken immediate action to delete all customer passwords used on the site. Customers logging in will be required to choose a new password.

cdccf491e497d5ef1ceee2a707c5f3e6

Although further details are scarce at this point in time beyond the hack using "a very recently identified flaw in the Java software used by the servers", Lakeland is to be applauded for a timely and honest disclosure of the breach. Rayner calls this a "policy to be open and honest with our customers" and although he continues to state that it is not known for certain that the hackers succeeded in stealing data Rayner does wisely admit that there is a 'theoretical risk' and as such think it best to be "proactive in alerting" customers. Obviously there is some careful wording being used here to try and mitigate any brand damage, and I'm no great fan of the whole 'potential/theoretical' language approach when disclosing such attacks (let's be honest, the chances are pretty high that those databases have been harvested), but kudos to Lakeland for doing the right thing in letting customers know as soon as possible.

What we don't know at the moment is the exact nature of the databases concerned, although the resetting of passwords would suggest that they contain customer and login data. We don't know the exact nature of the encryption either, other than the databases were encrypted, and questions such as whether the hashes were salted or not remain unanswered for now.

What we do know is that the Lakeland advice is spot on when Rayner advises "as a precaution... if you use the same password on any other account/s, you should change the passwords on these accounts as soon as possible".

Indeed, I would go so far as to say that perhaps the single most important step you can take to protect your data, given the number of high profile database breaches that happened over the last year, is to never reuse a password on multiple sites. Every password should be unique, and every password should be complex and strong. Use a password manager to both protect these in an encrypted database and make remembering them a no-brainer. Anything less is, quite frankly, asking for trouble...

Dani AI

Generated

correctly praises the transparency, but a few concrete technical points are still needed to assess risk. The crucial question is whether the credential store used one‑way hashing (with a unique salt per record and a modern KDF) or reversible encryption protected by a separate key. Request from the vendor: the exact crypto used, whether salts were per‑account, KDF/work‑factor parameters, and whether any encryption keys or backups were exposed. Absent clear answers, treat credentials as potentially compromised for risk decisions.

Practical triage for affected customers: compile an inventory of services that use the same email/username, then prioritize rotation and containment for pivot points (email accounts, password vaults, financial services). Wherever available, enable multi‑factor authentication. A durable mnemonic approach is to adopt long passphrases (multiple common words) or generate unique secrets with a vault, then rotate the highest‑impact credentials first. Monitor account activity and transaction alerts closely for several months.

Operational checklist for site owners and devops: preserve forensic images and full logs, engage an independent incident responder, rotate all credentials and TLS/private keys if there’s any chance of key exposure, patch the exploited Java component immediately, rebuild affected hosts from known‑good images, hunt for web shells and lateral movement indicators, and review backup integrity. Follow applicable breach‑notification rules and publish a clear post‑incident statement including affected tables, crypto details and a remediation timeline.

Key takeaway: insist on specific cryptographic details from the retailer, protect pivot accounts with MFA and unique long secrets, and for operators adopt modern password storage (Argon2id or bcrypt with strong cost), per‑record salts (and careful pepper/key management), plus layered detection and recovery processes. A short upfront investment in passphrase creation and a vault removes the long‑term burden described by .

Member Avatar for Member #949455
Member #949455

Indeed, I would go so far as to say that perhaps the single most important step you can take to protect your data, given the number of high profile database breaches that happened over the last year, is to never reuse a password on multiple sites. Every password should be unique, and every password should be complex and strong. Use a password manager to both protect these in an encrypted database and make remembering them a no-brainer. Anything less is, quite frankly, asking for trouble...

I couldn't agree with you more. Passwords are very hard to created and keep for a long period of time. I change my passwords few times a year. It's easy to say to create a complex and strong password but actually creating one takes time. It take me like a few hours to create one.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.