Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Black Hat: GDPR privacy law exploited to reveal personal data

bbc.co.uk

Post reply on HN
Print view View original

181–190 of 239 posts

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#181

Post by Nullabillity »

tastetherainbow wrote: post #111
Nullabillity wrote: post #100

Earlier quoted context omitted.

> There was[0]. Maybe you can revive it, since it is a pain-point? No. This is a problem that was intentionally caused by Finansiell ID-teknik, and I'm not going to get into cat-and-mouse game to fix their for-profit product. > Having read the BankId specs, they're "different" APIs in only in how the session is initiated. You're still challenged to enter the PIN for the certificate, which prompts the response to the…

> No. This is a problem that was intentionally caused by Finansiell ID-teknik, and I'm not going to get into cat-and-mouse game to fix their for-profit product. You're - literally - on "Hacker News" complaining about the lack of a product. You were given one that you could easily fix to suit your aforementioned needs/demands and was a principal complaint against BankId but, instead, you want BankId to write the Linux…

> You're - literally - on "Hacker News" complaining about the lack of a product. You were given one that you could easily fix to suit your aforementioned needs/demands and was a principal complaint against BankId but, instead, you want BankId to write the Linux app for you because... ...profits? This makes no sense; especially, when you would already have a hefty baseline of code to work with.

That's like saying jailbreaking makes iOS respect the consumer. It's a temporary hack that makes it tolerable to use... for a few days until the next mandatory update comes out and breaks everything again.

You won't get lasting improvement without changing the mindset of the powers that be.

> Does not automatically doesn't - implicitly - mean that it's disallowed. You seem to be confusing the two concepts, here.

You're saying service developers can put in the work to support both desktop and mobile BankID. I'm saying most of them are lazy and don't bother. Those two statements are not incompatible.

> We're - literally - talking about the API being the same because you made it a point that it was different. Either it matters or it doesn't. Pick one.

Similar and compatible are very different things.

Then again, this whole subdiscussion is irrelevant anyway, because desktop BankID is still crap for the same reasons as Mobile BankID.

> O.k.? We're still in the swamplands of those are problems created by the app developers and not BankId, correct..? I'm not sure I'm following how the app designers' decisions are the fault of BankId...

If BankID had spent more than two seconds designing their API boundaries then the app developers wouldn't have had to care about supporting both in the first place.

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#182

Post by domnomnom »

ng12 wrote: post #63
gen3 wrote: post #5

> "But the kind of mid-sized businesses that knew about GDPR, but maybe didn't have much of a specialised process [to handle requests], failed." I wonder if there is a market for selling GDPR compliance / advising services. Some company that makes sure your doing everything right, and inspects the requests for validity.

I think that's exactly the problem -- small/medium companies can't really afford to hire someone to do GDPR compliance (or at least, do it well). It's textbook regulatory capture.

I'm glad we can use Europe for an experimental staging area!

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#183

Post by PeterisP »

Silhouette wrote: post #176
PeterisP wrote: post #146

Earlier quoted context omitted.

"Any company doing more than selling basic goods in person for cash probably needs to process some level of personal data for legitimate reasons." is a bit tricky, and I'm not certain that it's true. I'd say that many common business processes use personal data for reasons of tradition, but don't really need it. 1) "Selling for cash" - accepting credit cards and wire transfers (paying by check isn't really a thing in…

"Selling for cash" - accepting credit cards and wire transfers (paying by check isn't really a thing in most of EU) doesn't necessarily require you to store PII. How are you going to identify the source of a wire transfer if you don't have a customer to match it against? Also, if you're selling online then anything service-like is already caught by the EU VAT place-of-supply rules (which require verification of the b…

"How are you going to identify the source of a wire transfer if you don't have a customer to match it against?"

Already in current practice you generally don't identify the source, you identify the order # or invoice # in the transfer details and ignore the payer which can be and often is different from the ordering customer (family members, companies paying some bills, etc), the payer information currently gets used only in case of mistakes and such.

My point is that I'd like all these companies to do their best to treat these purchases as if they were anonymous. But your point about VAT rules is a valid issue that might have wider implications about the general necessity to store data.

"what you'll have to tell everyone's credit card company when they start disputing charges as product-not-delivered and you have nothing to counter with." that's absolutely not an issue, that might be the case for card-not-present transactions but for as long as I can remember every single pizza courier or similar would use a wireless terminal to get a chip&pin (or now contactless) card-present authorisation which can't really be disputed in this way.

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#184

Post by wahern »

Avamander wrote: post #43
rossng wrote: post #28

Earlier quoted context omitted.

I have never used it, but I do get the impression that Estonia is pretty far ahead of everyone else. I don't know if this particular use case is natively supported (but would be interested to know). I suppose it would be possible for a third party to build it.

Yes, it's officially supported by providing everyone the possibility to sign documents with it. It was made an EU-wide standard in 2016 https://www.etsi.org/deliver/etsi_en/319100_319199/31916201/... but previous iterations have existed since 2002. The person you replied to is pretty much right, Estonian ID-card has solved 99.99% of authentication and signing problems for it's citizens, the support is mandated by law…

Flaws like this? https://arstechnica.com/information-technology/2017/10/crypt...

I support such uses of smartcards, but we have to be disciplined regarding our assumptions about non-repudiation.

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#185

Post by tooop »

rossng wrote: post #28
toomuchtodo wrote: post #22

Earlier quoted context omitted.

Hasn't Estonia solved this with their national ID smart card?

I have never used it, but I do get the impression that Estonia is pretty far ahead of everyone else. I don't know if this particular use case is natively supported (but would be interested to know). I suppose it would be possible for a third party to build it.

Latvia also has ID cards with embedded certificates that can be used to sign documents/login. These cards are optional (passport is mandatory, ID card can be requested) for now but will be required from 2023. Estonia/Latvia/Lithuania also have SmartID (although this is a private company service) which is an app on your mobile device and is used for logging in banks. SmartID account is issued by the bank (lowest level, can only log in issuer bank) or by yourself using your ID card (highest level, can log in any service that supports SmartID as well as document signing).

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#186

Post by AJ007 »

brokenkebab wrote: post #173
gowld wrote: post #90

Earlier quoted context omitted.

This is not a problem with GDPR. This is a problem with organizations (companies and governments) treating publicly data as private keys.

If GDPR created new vectors of attack which didn't exist before - there's a problem with GDPR even if there are also problems with organizations. Otherwise, you have just created a perfect excuse for any lawmaker: "my law written with good intentions, so not my problem if there are unintended consequences".

The only shocking thing to me is this is the first time I’ve seen any story about this hole in the GDPR. This was one of the top reasons we blocked and deleted all EU users. How do I verify that a request is legitimately from a user, short of them arriving in person and providing some biometrics, which presumably we would need to collect from them in the beginning?

I have no idea. Any system with a high false negative rate is breaking the law, and one with a high false positive rate seems even worse.

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#187

Post by noxToken »

segmondy wrote: post #143
jfk13 wrote: post #2

This is pretty appalling, really: "Overall, of the 83 firms known to have held data... 24% supplied personal information without verifying the requester's identity." Want someone else's personal data? No need to "hack into" any systems; just ask for it!

Verifying identity is a very hard problem.

Understood, but:

So, when one train operator asked for a photocopy of a passport, he convinced it instead to accept a postmarked envelope addressed to the "victim".

A postmarked envelope? This is baffling to me.

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#188

Post by ng12 »

gowld wrote: post #90
csomar wrote: post #17

This is horrible. So right now, in order to get access to data for a certain person, you need to hack your way through a few of the potential services he is using and drive from there. 1. The data might have things like IDs (ie: Crypto exchanges). 2. You can use that data to ask for more data. If you got a copy of his passport, now you can ask for more with this new piece. 3. Looks like some people still store passwo…

This is not a problem with GDPR. This is a problem with organizations (companies and governments) treating publicly data as private keys.

How is that not a problem with GDPR? They passed a law which relies on technology which does not exist. There is no way to safely and reliably identify an individual electronically.

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#189

Post by londons_explore »

ng12 wrote: post #188
gowld wrote: post #90

Earlier quoted context omitted.

This is not a problem with GDPR. This is a problem with organizations (companies and governments) treating publicly data as private keys.

How is that not a problem with GDPR? They passed a law which relies on technology which does not exist. There is no way to safely and reliably identify an individual electronically.

Unless you live in Estonia, where each citizen has a private key (on a smart card) and can electronically sign things to prove identity.

Governments could work with big tech players to confirm that certain Gmail/Facebook accounts are linked to one, and only one, national identity. Then through OAuth, you could use that to login anywhere else, proving you are a real person with exactly one ID (which needen't be revealed, just confirming you have exactly one account)

Re: Black Hat: GDPR privacy law exploited to reveal personal data

#190

Post by gjvnq »

Matticus_Rex wrote: post #129
gjvnq wrote: post #109

Earlier quoted context omitted.

I think I have a "legally safe", but slow, solution: 1. The user requests information about them but claims that they lost the password and the email address. 2. The company sends a form (in English) that basically asks for the information on the id (name, date of birth, etc) and the information being requested (ex: password reset). 3. The user prints this form, fills it out and attach a copy of their ID. 4. The user…

Nope, that's not legally safe -- we've been told by data authorities that the verification methods cannot be "overly burdensome" to the data subject. I live in dread of subject access requests (and thankfully have only had one, and it happened to be really easy to verify).

Maybe you can require this long process only for people that aren't in your country.

I don't know where you live, but here in Brazil having to get documents and signatures verified by a notary is super common (and super hated).

For example: I once wanted to unregister a domain I had. The only two ways of doing it were: don't pay the renewal fee OR get a paper form verified by a notary sent over snail mail to the registro.br office.

--------

Also, you may give your clients the option of verifying their signature at the embassy of the company's country in the client's country. This would skip on that whole Ministry of Foreign Affairs non sense.

--------------

A hacky way of avoiding this "excessive burden" problem is to offer all your users the possibility of linking their public gpg key to their account.

Almost no one would do it, but you gave them the opportunity to do so, thus you cover your ass at least a bit.

Post reply on HN