The leak came from a third party ID/age verification service for a regulated substance in a heavily regulated region. I think there's a good chance that they're under various regulatory/KYC type laws that would make holding onto user data mandatory. One practical scenario where this would come into play is if they were suspected of intentionally accepting fraudulent credentials, basically acting like a fake ID service for hire. In that case authorities would want to be able to see all data that they were basing acceptance on.

There are various reasons. What if it turned out someone was using a stolen ID or a fake ID, or the ID didn't match the face, or it wasn't even an ID? You'd want to be able to see how your process missed it.

The real problem is that there aren't many options for real authentication over getting people to upload pictures of high-value credentials. Now every service has to be a security expert, like encrypting the images at rest so they aren't the ones who leak it.

It's kind of like how dumb our credit card system is where you have to both share a secret with everyone (from random websites to random restaurants) while hoping the bad guys never get it because the secret can be used anywhere. It kinda works against everyone except the bad guys.

Maybe it's time we come up with a deliberate system.

> Why do these systems hold onto user's data post verification?

Depending on the company, you could rate the reasons on a scale from "incompetence/naivete" to "revenue stream".

I have a story about this, although it's a bit convoluted and not entirely related. But it does showcase low-value usecase compromising a high-value auth mechanism.

I was working on a project, client is a Real Estate agency, they use a CRM where they upload houses and it in turn uploads it to various sites like Zillow. We needed a list of their listed houses, so we wanted to use that data source instead of making a CRUD where they have to add houses yet again.

We ask the CRM sales team about APIs, they tell us that there's no accounts for third parties, client accounts have APIs, so we have to ask the client for an API key (or for their account password).

Which makes sense in general I guess, but the data is public in our case, so the CRM sales staff 's idea was that we should ask the client to let us access their account in order to get public data. We proceeded to scrape the houses from a website like Zillow like cavemen.

As it happens, our project was ancilliary low-value. So I don't doubt that the clients of this CRM are vulnerable in a similar way, and the root cause of the issue isn't evident at all, I can see 2:

1- Paradoxically, having an API that always requires an API KEY (as opposed to allowing unauthenticated access for public data) is less secure, as credentials/tokens will be used more often when not necessary.

2- This CRM effectively acted as an aggregator, consuming the APIs to publish to other vendors, but they don't provide an API for other vendors to read data from them. This effectively causes third party vendors to authenticate as the client, which is just incorrect. Credentials should identify a person/group, not a usecase.

In a word: complaints.

It’s somewhat understandable but also part of the problem.

I'm not sure how it works in the EU, but in the US, most states have a "PMP" (prescription monitoring program) that tracks the sale of marijuana in many states (nevermind that its not an actual prescription, but it is a controlled substance) and viewable by your doctor back up to ~12 months or so. Most people don't know this however and think it works like alcohol sales where it's sold after ID verification and then everyone forgets about it. Some states treat marijuana sales like prescription drug dispensing, it has to be reported to a central database including the intimate details of the persons involved. I have no idea if this is the case in Spain, however.

[dead]

Why wouldn't they? There are probbaly significant downsides if they fail an audit requirement, and they're probably mandated to retain records for some period, with no consequences to extended retention.

Set up a system so that it costs you nothing to do a bad thing but possibly wrecks you legally and financially to do the good thing, and people will inevitably do the bad thing. They shouldn't be collecting this information in the first place.

The people who design these policies are incapable of actually building things that work. They are not the intelligent, competent leaders exercising a careful craft that they like to pretend they are.

They keep going after age verification, online ID, central bank digital currencies, etc - keep this incident in mind. The people who implement and write these policies are morons. They don't game things out and plan for redundancy or resiliency. They don't take into account bad faith actors. They don't account for deliberate exploitation of the system.