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

91–100 of 239 posts

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

#91

Post by gowld »

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.

I doubt that a black-hat attacker is going to file a lawsuit to obtain someone else's personal information.

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

#92

Post by TazeTSchnitzel »

Nullabillity wrote: post #87
ckris wrote: post #70

Earlier quoted context omitted.

> There is also already a clear precedent to allow delegation of access that require strong authentication IRL. For example, PostNord allows you to retrieve someone else's mail as long as you provide ID for both yourself and the recipient. They have the same service in their app with BankID + QR code (at least for packages).

My point is that BankID should have something similar for any BankID action.

It wouldn't work, because services using BankID want a (presumably contractually-obligated) assurance that only that particular person is using the service. If someone else can be authorised use your ID, it undermines that.

They could still add such a feature of course, but they would need to inform and have the co-operation of services when someone else is using the ID, so it wouldn't be widely supported.

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

#93

Post by gowld »

phicoh wrote: post #29
Silhouette wrote: post #3

Earlier quoted context omitted.

This was actually one of the risks we identified when looking at GDPR for my own businesses last year. Given that in some cases all we have is an online account with minimal personal details, how can we possibly verify their identity to an acceptable standard if someone does send us a GDPR subject access request of any kind? If they have some sort of account with us already and that has associated ID and security che…

One option would be to evaluate if it would be safe to delete the data. In that case you could offer to delete the data. Countries typically have some expensive way to proof identity. So, delete or actually proof who you are. Of course, sending a message to, say, a know email address that to intent to do that helps avoiding angry customers. If you cannot delete the data because it is valuable to the customer, then ju…

Offering to let attackers delete customer data is not a good solution.

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

#94

Post by AstralStorm »

JumpCrisscross wrote: post #79
PeterisP wrote: post #71

Earlier quoted context omitted.

One of the intended goals of GDPR is to reduce the processing of personal data - not only that the companies should do it differently, but that at least half of the companies who currently have my data really shouldn't have it in the first place. 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 han…

> it also makes companies think twice whether it's really necessary and worth it The simple fact that someone has an account at a service can be private information. For anything requiring even a modicum of persistence, keeping these data is tough to avoid. I think most of HN agrees GDPR’s goals are good. It was just sloppily drafted, passed and implemented.

GDPR does not care about privacy.

It cares about personal identification. Such as full name and address, and a bunch of other protected things.

Why would any random service request, process or more importantly store these?

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

#95

Post by gowld »

mLuby wrote: post #23
dmix wrote: post #11

Earlier quoted context omitted.

Regardless it would then be a bad law since almost all criminal law looks at intent and reasonable expectations of how a citizen should act. We don’t need to keep replaying the vilification of security researcher game just because it involves the flawed gov systems imposed on technology itself instead of just technology. The end goal is the same, the privacy and security of end users.

Agreed. I hope any jury would nullify such a law. AKA "perverse verdict" in the UK?

Juries can't nullifiy laws. They can nullify verdicts.

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

#96

Post by eitland »

Nullabillity wrote: post #34
mrkeen wrote: post #21

Earlier quoted context omitted.

Sweden's BankID is quite good too.

BankID is horrible. 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. It also doesn't support anyway to delegate access, either to people ("my partner should have access to this bank account") or computers ("I want to back up my incoming govt. messages automatically").

> 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 should have access to this bank account") or computers ("I want to back up my incoming govt. messages automatically").

I will happily admit banks aren't too good with this, but it isn't BankIDs fault.

BankID only handles authentication. Once I'm logged in I can easily delegate access to my account using my banks self service feature. If your bank doesn't let you it is their fault.

As for why it cannot be used by a machine I guess the reason is that use of BankID is considered the same as signature. So signing with someone elses BankID is considere forgery.

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

#97

Post by aforwardslash »

testvox wrote: post #38
davidhyde wrote: post #31

Earlier quoted context omitted.

One of the major goals of GDPR is to discourage firms from retaining personal data in the first place. It did not used to cost them anything so they kept it regardless of its use. Now that there are big risks to keeping it these firms have to think twice about it. This "cobra effect" is one more reason NOT to retain personal information in the first place.

And yet other laws require the collection and retention of sensitive user data, in particular any service that allows for transmission of large amounts of money (crypto exchanges were a good example).

That is well covered within GDPR scope. Retaining data to fulfill legal obligations is allowed. One common related example is invoice data.

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

#98

Post by PeterisP »

codechicago277 wrote: post #36

This is the problem with overly aggressive legislation. The big companies performed well, the small companies ignored the law, and the medium sized companies tried to comply and failed. You can’t legislate good behavior because people will always find a way around the laws. The legal philosophy behind GDPR seems to be nothing more than to make everyone a criminal and then choose who to prosecute, and in that case why…

I wouldn't agree that the medium sized companies tried to comply with the GDPR and failed. Yes, they tried to comply with that particular request but the failures suggest that they didn't even try to be GDPR compliant in the first place - if they had done so, then they would have had assigned a data protection officer who would have long ago asked themselves the question "what do we do in case of a personal information request?", and written down a reasonable process for handling such requests, possibly consulting with the local data protection agency.

That would count as "trying", as it was their duty to have done this a year and a half ago. It's basic 'table stakes', a precondition to being permitted to handle personal data at all. If they started thinking about "how do we verify identities" only on day they received the request from this researcher, then that's not trying to comply, that's being grossly negligent.

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

#99

Post by tastetherainbow »

TazeTSchnitzel wrote: post #85
tastetherainbow wrote: post #78

Earlier quoted context omitted.

> Same problem. There is still no Linux client, for example. There was[0]. Maybe you can revive it, since it is a pain-point? > It's a different API. 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 authentication request. In other words, BankId and Mobile Bank Id are presenti…

Nordea requires Mobile BankID to log into their online banking, but they also let you log in with a card reader and do the challenge/response codes thing. I assume desktops/laptops aren't secure enough for their taste.

Fair enough. =]

Handelsbanken allows both. I think the mobile app is pretty static, however, after you sign in with Mobile Bank Id. I still wouldn't call that a "disallow", more of an intentional UI convenience for users that want #easyMode.

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

#100

Post by Nullabillity »

tastetherainbow wrote: post #78
Nullabillity wrote: post #60

Earlier quoted context omitted.

> You can install it on your PC or Mac if you want. 1. Same problem. There is still no Linux client, for example. 2. It's a different API. Most services specifically require Mobile BankID these days. Desktop (regular) BankID won't work there. 3. Many applications are only useful on the go, such as Swish. > Access delegation not being part of BankID itself is a feature not a deficiency, it would undermine the concept…

> Same problem. There is still no Linux client, for example. There was[0]. Maybe you can revive it, since it is a pain-point? > It's a different API. 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 authentication request. In other words, BankId and Mobile Bank Id are presenti…

> 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 authentication request. In other words, BankId and Mobile Bank Id are presenting the same exact set of data back to the session initiator.

They're different in that a service that takes Mobile BankID does not automatically support the desktop version, or vice versa. Whether the API is similar after that doesn't matter.

> I have, as of yet, to run into anything that would not take BankId or Mobile Bank Id.

Off the top of my head, Swish and Hemfrid only accept Mobile BankID, with no alternate authentication options. Swedbank accepts Mobile BankID or their custom OTP hardware token, but not desktop BankID.

Post reply on HN