> Note what happened. A high-value credential—a passport—was used in an ancillary low-value authentication system: ID verification for cannabis dispensaries. And it’s the low-value system that got hacked, putting the high-value credential at risk.
Why do these systems hold onto user's data post verification?
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.
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.
This is a really great story. It is super short and understandable, and nails the point that just falling into the default case of authenticating everything can hurt security. If someone was teaching a some sort of software engineering seminar, they should totally steal it.
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.
We are decades beyond the days where the waitress uses a credit card imprinter to copy your credit card so the restaurant can charge your credit card later, yet that's still basically the state of our tech when it comes to authentication and payment.
Not even KYC institutions have better tech. You still upload a scan of your high value creds, maybe with your face in frame.
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.
It's not like this in USA for cannabis. States with medical programs issue medical cards and the dispensary uses that as the only form of ID. For adult-recreational the dispensary can choose their ID verification system. Many use ID scanners connected to their online POS provider. The State run system doesn't track retail sales to an individual.
OMG, I forgot that AZ and VT have very unique programs. Basically everyone else is on BioTrack or Metrc which are dedicated cannabis "track and trace" - ex-pharmacy infrastructure
Cannabis is federally illegal in the US, and the federation has its own enforcement teams that can come and get you even if your state's enforcement teams won't.
This is half true. Medical cannabis is now schedule III, with state programs explicitly placed into sched III (even without FDA approval) making it fully federal legal in that case.
Economic and monetary union is as a group of policies aimed at CONVERGING the economies. From your link.
The European Union consists of 27 countries.
25% of them did not adopt Euro as the currency.
"common" language is orthogonal here - it would be valid if you could legally use euro everywhere. You can't, it's not a currency in the quarter of the states. Sure, someone may accept it and offer you the exchange to the local currency.
Vatican City example is also not very good (to put it mildly), because Catholicism is a state religion. You're not going to be deported for being Sikh, yes, but it's akin to the Romanian not being deported form Portugal for carrying lei in his pocket.
Euro is NOT a common currency in the EU. It is by far the most popular. It is a common currency in the Eurozone countries. And these two are distinct from Europe as well.
I'd suggest you discuss your ideas with someone before posting them again.
You were ridiculed because I never stated the EU was a country. I said I didn't know how things work in the EU, not that everywhere you go in the EU it would be the same (in fact, I explicitly stated, I did not know how the system worked in Spain specifically to denote national differences in law in the EU). Your malicious use of feigned lack of reading comprehension merits the response.
Look, non sequitur doesn't hold as much as you think it does.
And I'd also like to point to something you missed:
>> *attempted* ridicule.
_If_ their arguments were sound and relevant, maybe. But, well, they weren't.
Note I wasn't even responding to you, just replied to someone else seemingly conflating EU with Eurozone, trying to make fun of one phrase out of several statements, omitting the key "EU is a loose federation".
Now I fully expect @bluebarbet descent again and either chastise me for being amused at your comment, or tell you off for rudely implying malicious intent that wasn't there.
Especially since I wasn't even talking to you right now, and from your first comment's first sentence it could be clearly inferred you expect some sort of the federal policy, and this is what I was trying to address concisely, in a good faith.
Do with it whatever you want, I wasted too much time on that already anyway.
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.
There's a law forbidding storage beyond necessary minimum and law punishing such behaviour unless another law necessitated storage of the original document in the unsecured, unencrypted form. Doubtful.
There's also laws mandating secure systems design.
Separately there's no _need_ to store the original document if the verification system is sound (and audit real, not some phony crap like in some of the scandals posted here on HN).
If you need to prove you sold to real people, storing their credentials is a necessary thing, for as long as your need to prove that. At least with the way things currently are.
How else do you expect it to work? ‘Honest, we checked’ checkboxes?
If the credentials are stored for some period of time, then an inspection will reveal those stored credentials within the preservation window. Unannounced inspections will then show with high certainty a legitimate validation process.
The auditor can act as a customer and validate whether phony credentials are rejected.
Yeah, my point is that there is a significant exposure they are required to have, if they need to be able to be audited and have to actually prove they are dealing with real people.
At least - as you mention - until the rules catch up and there is some sort of one way hashing/signing or something possible, which for most of these industries is probably decades away (if ever). Most of these industries struggle with photocopies at this point.
You can store for example ID type and serial number AND hash of the personal information.
If the government-affiliated agency decides to check, they can.
But back to my original statement - unless they're explicitly mandated to keep it longer, they are forbidden from doing so, and their DPO would know it.
They most likely weren't allowed to keep it past the verification per GDPR art.5. Once the passport has been verified for whatever purpose they needed it ("age verified to be > 18yo on 2026-06-12" or "identity verified to be XXXX YYYY"), there is no legitimate use for the passport photo and details anymore, and they should delete it.
(I'm naive in this area, but..) I wonder if the various "proof of age" laws coming into play will clash with the GDPR in insidious ways. Like requiring identity providers to hold definitive "proof" of why they made an assessment rather than merely proving and discarding. I assume/hope there is some cryptographic way to do this rather than hang on to passport and ID images, however.
There are established ways / protocols to hold and provide cryptographically valid proof of a verification process, without any need to keep the actual id images in any storage. And to my knowledge there is no requirement for compliant KYC (Know your customer) to provide their ID as a proof as long as the verification process itself is compliant and audited in accordance to certain criteria.
You can compare this in a certain way to file hashes. A successful verification with a predefined minimum level of credibility can be encrypted to a special string for later being used, if a service needs to verify the person again. It doesn't matter then, that the original passport images or video ident has been deleted the second after id verification has been completed.
I'm somewhat knowledgable on privacy topics, pasting my answer to another comment:
The EDPB has explicitly ruled on that, when it comes to age verification^1, you should delete: "Trust models are crucial to prevent data breaches in age assurance contexts [...] once the user's age is verified, no record of the personal data used for the age assurance process is kept".
Why do these systems hold onto user's data post verification?