GDPR is an identity thief's dream ticket to Europeans' data
theregister.co.uk
theregister.co.uk
However, as far as I can tell, these companies have done the opposite and _breached_ the GDPR by failing to keep personal data safe, as the GDPR itself requires, in the process of handling a data access request (as happens to be mandated by the GDPR).
I don't see how this is a problem with the GDPR itself. It _is_ a problem with how some companies have implemented it.
According to the article, the researcher says that "lawmakers need to set a standard for what is a legitimate form of ID for GDPR requests".
I'm not sure I want this. I want companies to remain liable for data breaches even if they come from illegitimate data access requests. A single standard won't suit all situations.
Without any reasonable way to distinguish between legitimate requesters and attackers, their options are to not provide the information to someone who may be the right person or to provide it to someone who may be the wrong person. If both of those are illegal that implies it's impossible to comply with the law.
If you need identity data than verify identity. Most companies dont and then they should not store it.
This is already the case in banking i dont see a reason why other companies think they shouldnt need to do this.
The problem is that there is data which is personally identifying and yet not useful to authenticate the user, and that information may be necessary for the operation of the service.
> This is already the case in banking i dont see a reason why other companies think they shouldnt need to do this.
What banks do is to know the identity of all their users. Requiring sites to do that is the exact opposite of the apparent purpose of this law, so it would be a massive farce if that was the only way to comply with it.
The article also jumps to the same troubling conclusion: That the law is deficient because it failed to make provision for greedy data hoarders to continue without changing their business.
In my opinion the law is working as intended, and requiring extreme security precautions around the hoarding of personal data. If a few companies with abusive business models become non-viable in the process, that's a side benefit
Giving out data to someone other than the data subject is a data breach.
If you can't identify the subject positively you don't give out the data.
You document this - it is not like you get an instant fine without anybody asking you about what was going on.
This is not YouTube or PayPal or Twitter banning your account without a chance to talk to someone. Before you get a fine someone will talk to you. If you get a fine you can appeal. It is not instant 4% of you income decucdet automatically from you account.
Maybe things will improve with time as people learn from episodes like this. Or maybe not.
If you can't verify you don't give out information.
There are so many ways to verify. Public Data is not a shared secret, thus not something to verify identity with.
What Pavur managed, is a wake up call for companies to further clean up their act, and that is positive step to making GDPR stronger but not to remove it.
One cannot blame the whole system for some/many bad actors. If improvements are needed in the identifying mechanisms, so be it, but as a system, it is built to work FOR the people.
Also (without reducing the effort and results of Pavur) anything you read on UK media condemning anything EU-made, take it with a pinch of salt, a no-deal Brexit may be coming and some media will do their best to demonize all-things-EU. Agendas will be served.
Okay, now let's relate it back to what Hacker News knows about
> "Software, like any other infosecurity control, have exploitable vulnerabilities," he said. "If we'd look at these vulnerabilities before the Software was deployed, we could pick up on them."
It's correct to say that you can limit the number of vulnerabilities you ship, but it's always going to be non-zero and you're always going to need to deploy security patches.
I'm not sure poor implementation and compliance with a new law is a particularly huge threat. Over time best practices will emerge and this will essentially be a low success rate attack vector. Compare that to the counter-factual, before GDPR the number of companies with your data was far higher, the data they held was far more in depth, and they often had little to no security procedures. The underlying message here is that the fundamentals of GDPR make your data safer, not less safe.
Before the GDPR this would have been stamped "identity theft" putting the company in the clear. As if you were somehow responsible for the company not verifying the identity of their customers.
[Edit]
I should mention that around here there is an established 2FA solution used by banks and the government so verification has been de facto standardized.
The GDPR does create a new attack surface, in that companies now have a legal obligation to provide information. The article did not say whether or not there is a legal obligation to properly verify the identity of the requestor.
Back when I first worked for a start up, Richmond Informatics (subsequently Garlik, which was then bought by Experian) it began by doing subject data access requests for key personnel just to see what was out there. That's well over a decade ago.
And yes, they have a responsibility to ensure they only give the actual subject the data, which is tricky but if it's too hard then probably "don't keep any data" was the correct answer. "Thank you for your letter. We do not keep any data whatsoever about our users". Done.
At Experian the main theme of the training in this area was "Do not try to help, don't respond in any way except to forward everything to the special department that handles these requests".
The attach described is similar to "password reset", which gives an adversary access to everything and companies that don't have strong security in place, or users with weak passwords are likely subject to exploitation.
For instance, I already know my mother's maiden name, so a response of "We know your mother's maiden name" would be just as useful to me as "We know that your mother's maiden name is <NAME>", but would be much less useful to someone pretending to be me.
There are situations where you do need to see the actual data so it should still be available, but getting that data should require a much more robust proof that you are the data subject than is required for just getting the existence data.