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

171–180 of 239 posts

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

#171

Post by PeterisP »

pbhjpbhj wrote: post #155
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…

>you don't need any details about the transcaction beyond the amount and ID. // That's a lot of trust in the merchant services. "What transaction?", then if all you had was a transaction ID what do you do? Also, to process refunds you need to have payment details. In your second case only store the details if people explicitly want you to. You can do repeat customer discounts by sending vouchers for a later order wit…

What do you mean by ""What transaction?", then if all you had was a transaction ID what do you do?" - that's a common process in online stores, you make a contract with an acquiring bank with the default scenario that you won't be processing transactions yourself (as most smallish customers can't or don't want to handle full PCI DSS compliance), then you (or the bank) contracts with one of the merchant gateway providers, and whenever you forward them a customer order session and get back a confirmation token, then you verify it afterwards (usually next morning after closing of business day) with your bank that you've got each transaction. Or something similar, details may vary - but it's an established process that works for thousands and thousands of companies without any significant trust issues. Yes, the gateway has to be trustworthy - in part that's the service they provide, to handle card data in a trustworthy manner because you don't want to be required to be trustworthy because doing things in a trustworthy manner is complicated and expensive - secure facilities, regular audits, four-eyes principle, separation of duties that's infeasible for smallish companies, etc, etc. You also have to trust your acquiring bank, and Visa/Mastercard network, that's also part of the deal.

"Also, to process refunds you need to have payment details." this is false, merchant gateways (in general, not all of them) can also execute refunds (or recurring payments) without you having any sensitive details but just that same transaction confirmation token they give you when the initial transaction was made, I've written code relating to these processes.

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

#172

Post by JumpCrisscross »

PeterisP wrote: post #124
JumpCrisscross wrote: post #104

Earlier quoted context omitted.

> Why would any random service request, process or more importantly store these? So they can identify users for purposes of complying with GDPR? (For example, to handle the data requests highlighted in this post.)

The GDPR recitals do not recommend gathering additional data solely to be able to fulfill these requests. See https://gdpr-info.eu/recitals/no-64/ and https://gdpr-info.eu/recitals/no-57/ - the key part is "A controller should not retain personal data for the sole purpose of being able to react to potential requests."

> The GDPR recitals do not recommend gathering additional data solely to be able to fulfill these requests

One, these are non-binding recitals.

Two, the conflict between (a) data-furnishing requirements and (b) advice against retaining data that would validate the requestor is exactly the point of this post.

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

#173

Post by brokenkebab »

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.

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".

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

#174

Post by krona »

efdee wrote: post #139
rjzzleep wrote: post #49

Earlier quoted context omitted.

I'll let you in on a secret. For government institutions which in general have huge amounts of information about you and are notoriously bad at security. They don't even get fined with the GDPR. The worst that can happen to them is bad press. So the institution that has all the healthcare data of all German citizens can not get fined under the GDPR. Same with any other KdöR https://de.wikipedia.org/wiki/K%C3%B6rpersc…

We had a mayor fined for sending out election mails to a list of subscribers to list intended for other purposes. Not exactly "big government agency" but it still counts. The downvotes are probably because you failed to cite the laws that exempt government agencies from the GDPR.

It's fairly well cited all over the internet that the EU commission and other European institutions claim they are exempt from the GDPR, after they were found to be in breach of the legislation it created.

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

#176

Post by Silhouette »

PeterisP wrote: post #146
Silhouette wrote: post #128

Earlier quoted context omitted.

It depends on the circumstances of each scenario, but it would be completely reasonable if large numbers of smallish companies acknowledge that they lack the capacity to handle personal data properly and the recommended strategy for GDPR compliance is that they should simply stop requesting and storing that data. That's not a reasonable strategy at all. Any company doing more than selling basic goods in person for ca…

"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 buyer's location and keeping adequate evidence for up to 7 years) and there have been proposals to extend that to sales of physical goods for some time.

If you're delivering pizza, then you don't need to store every order's phone number and address forever; and if you don't store the delivery data beyond the delivery, then if someone requests all the data you have on them, then you can honestly say "nothing".

And that's exactly 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.

I'm afraid you're being extremely optimistic about how much personal data processing can be avoided in even these everyday situations. And this is before you do anything like marketing, customer relations, logging use of your electronic systems, having any employees, paying any suppliers, etc. I don't doubt that some cases where companies currently have your data could be avoided, but I suspect 50% is a gross exaggeration.

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

#177

Post by tjoff »

JumpCrisscross wrote: post #75
tjoff wrote: post #67

Earlier quoted context omitted.

The email used during registration is sufficient. If you don't have email then username+password. If they don't have that they don't get access to data. They need to be able to prove who they are and reasonably that is the same information that is used during registration. If password is lost then tough luck.

> If password is lost then tough luck This is your personal opinion of how it should work, not GDPR.

GDPR requires the user to identify themselves to request data.

If a password and username is the only possible way of identification then that is enough. And if one can not provide that then tough luck it is.

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

#178

Post by eitland »

Nullabillity wrote: post #108
eitland wrote: post #96

Earlier quoted context omitted.

> BankID is horrible. The rest of your post does not back up this claim IMO. > It's coupled to your phone's OS, so as it becomes even more mandatory you're stuck carrying around an iOS or Android device, even if your primary phone is something like a Librem 5. At least here in Norway you can get a standalone hardware 2-factor key. > It also doesn't support anyway to delegate access, either to people ("my partner shou…

> At least here in Norway you can get a standalone hardware 2-factor key. You can get the key embedded on a smartcard, but it's still coupled to their proprietary driver (which only works on Windows or macOS, of course). It's also a separate API and not as widely supported as Mobile BankID.

> You can get the key embedded on a smartcard, but it's still coupled to their proprietary driver (which only works on Windows or macOS, of course).

Maybe it is different where you live but the standalone hardware key I mention is standalone: You open the website, enter your national id, find your token generator, enter pin code for hardware token, read your token, type it into the bank web site, and enter your password ib a different field.

Nothing of this is linked to Windows or Mac, only to a reasonably modern browser.

And the thing you describe seems to be very very different and I'm confident there's only one BankID product in the Nordic countries, so either it is implemented in a very different way with your bank or we aren't talking about the same thing.

> It's also a separate API and not as widely supported as Mobile BankID.

Around here hardware tokens were supported before mobile BankID was even a thing. They are still available everywhere I log in.

---

As for why I care, I find that BankID is a good idea, reasonably implemented, so I don't think it is OK to trash it - unless I'm misunderstanding something, in which case I want to learn.

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

#179

Post by Silhouette »

SiempreViernes wrote: post #76
PeterisP wrote: post #66

Earlier quoted context omitted.

I don't think that what you describe is incompatible with GDPR. In general GDPR allows and requires you to use 'all reasonable measures to verify the identity', and in your particular scenario requiring the same authentication that you usually use would be considered reasonable, and it's likely the only possible reasonable measure - if what you say is all you store, then it's impossible to distinguish between two dif…

Yeah, there is some weird subtext to the argument, that for some reason account access shouldn't count as secure verification? I guess this all hinges on the idea that to implement GDPR all you need to do is set up an email adress and handle all requests manually, only to then discover that: actually, identity management via plaintext email is a bit tricky.

Yeah, there is some weird subtext to the argument, that for some reason account access shouldn't count as secure verification?

It's not in dispute that account access using known good credentials would be reasonable verification. But people forget passwords or mistype email addresses or lose access to email accounts, and they still have legal rights as data subjects under the GDPR.

So, it also matters whether other forms of identification are acceptable. If you have some reasonable means of confirming someone's identity in response to a request under GDPR and you try to avoid using it because the person didn't follow your preferred method based on standard account credentials, it's not clear that regulators would accept that as reasonable. And any time the words "not clear" appear, they come with an implicit threat of severe penalties in GDPR world.

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

#180

Post by bchanudet »

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).

IIRC they also allow charging the person - for a "reasonable" amount - for the data retrieval process (which I assume would include the "identity verification" part).

Maybe using the 3-D Secure protocol (especially the second revision) would be enough to unburden yourself for verifying the identity as Mastercard/Visa/American Express supposedly check it for you.

This would work only in some conditions (the data subject should have a card to their name that supports 3-D Secure protocol, and you need to had a complete payment platform to your website/app/whatever) and doesn't solve all the other problems we have (like being sure we are delivering the right information esp. regarding homonyms and so on), but that could be something to investigate.

Post reply on HN