AnyVan confirms digital break-in, says customer names, emails and hashed passwords exposed
- Reference: 1611045909
- News link: https://www.theregister.co.uk/2021/01/19/anyvan_confirms_digital_breakin_says/
- Source link:
The company wrote to customers mid-last week to inform them of a "breach of security resulting in the unauthorised access to data from our user database," according to the email seen by The Register .
[1]
"This leaking of data came to our attention on the 31st December but we understand the incident itself occurred at the end of September. As soon as the incident came to our attention, our specialist IT team investigated it and have since taken the following remedial action: all passwords have been changed."
The data in question? "Customers' names, email and a cryptographic hash of their password were accessed and 'potentially viewed' but no other personal data was unwittingly shared. A probe of events continues," said Anyvan.
[2]
As well as being "very sorry for the inconvenience," the company advised customers who used a password to access their account from April last year to update it immediately and in line with good hygiene to "regularly change your password to accounts that hold your personal data."
Besides changing the passwords, it didn't mention how it would avoid the same incident from re-occurring. It is not known whether the password hashes were salted. Salting is normally done to prevent hash collision attacks - where an attacker tries to find two input strings of a hash function to produce the same result.
El Reg sent a list of questions to AnyVan last week about the compromise of its internal systems, asking how entry was gained; how it has since been secured; whether the password hashes had been salted; and whether customers in mainland Europe had been impacted or just those in the UK. We also asked if it had informed the ICO.
We can answer the last one. The UK's Information Commissioner confirmed to us it was not told of the incident by AnyVan. "Not all breaches need to be reported. Organisations are required to establish the likelihood of the risk to people’s rights and freedoms. If a risk is likely, the organisation must notify the ICO; if a risk is unlikely, it doesn't have to report it."
A spokesewoman added: "However, if an organisation decides it does not need to report the breach, it needs to be able to justify this decision, so should document it."
Additional details of [3]breach reporting requirements are here.
[4]
Neil Brown, tech lawyer at decoded:legal, told us the breach in AnyVan’s case is "pretty limited in scope of personal data" and he could understand why it had opted not to tell the ICO. ®
Get our [5]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x250&tile=2&c=2YAa7yp6J9TxuXW66eJ6f3AAAANg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x250%7C300x252%7C300x600&tile=3&c=33YAa7yp6J9TxuXW66eJ6f3AAAANg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dtop%26test%3D0
[3] https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/personal-data-breaches/#:~:text=You%20must%20report%20a%20notifiable,give%20reasons%20for%20the%20delay.
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x100%7C300x250%7C300x251&tile=4&c=44YAa7yp6J9TxuXW66eJ6f3AAAANg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://whitepapers.theregister.com/
The only way
This is something that has become so frequent that no one is in the least surprised anymore.
A huge data breach?
Thousands of passwords and (most important) personal and banking data stolen?
Move along now, nothing new here, happens all the time.
The only way that this will eventually stop is to heavily fine the company that allowed this to happen.
We can't continue to be so naïve as to think that, in this day and age, these things just happen .
No ...
They happen because some DH beancounter calculated the risk vs. the cost of having a secure system and decided that, given lack the penalties involved, it was a good deal to take the risk.
And some bigwig approved it.
Of course, we all know that given enough time and resources, any secure system could eventually be breached.
But a severe penalty eg: 50% of the previous year's profits and 100% in a recurrence would put real fear in any CEO's mind.
The result will be that systems would never again be breached due to incompetence and greed.
O.
Re: The only way
That's really not practical though.
My company stores minimal customer data which is secure *to the best of my knowledge*, but my bugs and mistakes notwithstanding, I'm still relying on at least the following (in no particular order) to be secure in the first place:
My hosting provider.
Linux.
The programming languages and libraries that I'm using.
MySQL.
All third party libraries I'm using. (Not many, and nothing on critical paths, but there are some.)
My payment provider.
I do the best I can to ensure that any data I manage is secure. But there are so many unknowns here.
If my company were to be arbitrarily fined due to a bug in one of the technologies I'm using, how is that fair? The only way I could be 100% responsible would be if I hosted my websites and databases on my own machines, running 100% my own code from the BIOS up. Which is never going to happen for 99.9999% of companies out there.
In your scenario, no third party library with any form of liability disclaimer would ever be used ever again. And in fact most third party library developers would probably stop from fear of being sued to smithereens if (and when) a vulnerability was exploited.
If only they'd put a sign on their website saying "No user data left on this site". That usually deters most would be ne'er-do-wells where vans are involved.