Dad stuck in support nightmare after teen lied about age on Discord

Data dump confirms dad's suspicions that Discord knew teen's age prior to hack.

See full article...

 

[GaidinBDJ]

But like many kids who, regulators have found, commonly lie about their age to access social media platforms, she didn’t want to wait another year to join her friends on the messaging app. Hiding her age, she created an account that listed her as over 18 years old.

Why the audacity! Lying about your age on the Internet!! What are kids these days coming to?!

whistles innocently

 

[GaidinBDJ]

Discord has a lot of problems to resolve with reguards to community safety, but when it comes to authenticating another person's identity they'll need accurate information (even if it's only your age). It honestly did not help that a kid lied about their age just to get on the platform.

There are schemes they could implement to verify that users of a site are over 18 without forking over your personal information to that site.

 

[GaidinBDJ]

How could the site positively confirm a person's age without someone surrendering their government ID?

Site generates a token like this:

{ hash( site + userid + secret_salt ), age >= 18 }

User gives the site to some kind of trusted holder of personal information (say, your state DMV). If the rule is true, the DMV signs the token. The user then returns the signed token to the site. The site then checks the signature against the public key for the DMV.

The site knows the user is over 18 but nothing else about their identity, the DMV knows they verified the someone ages but doesn't know why/for what site. Because you're the one handling the token, you can see the information they're asking to be verified.

This is incredibly easy to implement. There are a buch of existing information-holders that could implement this (DMVs, Login.gov, credit bureaus, etc.) with pretty small amounts of effort. The scheme could also be used to verify all kinds of information and could be used by anybody.

 

[GaidinBDJ]

But such a thing is already being done with third party identity proofing companies. While Discord proper wouldn't get their hands on a users PII in your example, it would still create a real user ID attribution (something privacy advocates oppose).

No, it wouldn't.

The site's internal information would only know one thing about your real identity: Did you pass the rule?

Let's go with Discord and say they want to verify a user is over 18.

I sign up for Discord. They have some kind of unique internal ID for me, of course. That's basically what an account it. I've picked my own username and can make it "me" or just some random thing. They assign a unique id of "8675309" to my account. So they make the hash with (Discord + 8645309 + secret_salt) and pair it with "age >= 18".

I give that to the Nevada DMV (my state). They sign it if true. I return the signed token to Discord. Discord checks the signature and verifies it.

Discord now know exactly two things about me: I'm over 18 and I used Nevada's DMV to confirm that's true. That's it.

Yes, they can use subsequent activity to probably narrow down my identity, but I can choose to stay more private by making other accounts. If I make 10 accounts, and verify it the same way, they have no way of knowing those 10 accounts are the same person. They only know those 10 accounts are all over 18 and all used Nevada's DMV to verify it. I could be 1 person with 10 account or 10 different people. They've no way of knowing.


With Discord using a third party that I have to provide both my Discord identity and my real-world identify, they could correlate all those accounts. And that's ignoring the fact that it's just a "trust me, bro" approach. With my approach, I don't have to trust the exchange because I'm the one handling it.


And, ignoring major sites. Let's say you told me "Hey, I'm 47 years old." Well, I could say "prove it". I make a token { hash( gaidinbdj + nvemb3r_age_check + blahblah_secret), age = 47} and give you that token. You get it signed and pass it back. I check the signature. I now know you are 47. And you didn't have to tell me anything you didn't want to about yourself.

 

[GaidinBDJ]

The BC provincial government setup a system similar to this. Every resident of the province has (or has the option to get) a BC Services Card. This card is used for accessing government services and health care. This is a picture ID that includes your birthdate. Using this card, you can enable a BC Services account online (via the web or an Android/iOS app). Then, 3rd-party sites/businesses can use that for authentication / age verification / similar services.

The 3rd-party service never sees your actual information. They make a request for "is user over 18" or "verify this user is authorised" or similar. The request pops up on the app similar to MFA. You use your phone lock system to authorise the request. The 3rd-party service gets a token that says your identity is verified and to authorise access.

The Canadian federal government is working on something similar for accessing Revenue Canada and other federal services.

Similar to how banking online works via Google Pay/Apple Pay/Samsung Pay/Interac/etc where tokens are passed around rather than the retailers seeing your actual credit/debit card/bank account numbers.

Good luck getting a social media company to use these services, though, as that would require per-province/per-state/per-country/per-whatever setups. That would take too much effort compared to a hacked-together, homegrown, in-house "solution" that doesn't actually solve anything.

That scenario has two privacy flaws: 1) you have to trust they're exchanging information without providing anything beyond what they're claiming and 2) your government can keep track of where you authenticated what.

Sure, there's a certain amount of accountability with a public service like a government, but why simply trust when you don't have to?

 

[GaidinBDJ]

Most DMVs are still struggling with email and online renewals. There's no such thing as "easy to implement" for a DMV. They'd have to farm it out to some private contractor.

I just picked DMV's as an example. Some states may have DMV's that don't have accounts for everyone. I dunno. Most do have online accounts already set up. Go with Login.gov, then. It's linked to your Social Security account, so they have access to something as simple as date of birth.

Implementation really is simple at that point. There's nothing fancy or new, here. All they need to look at is if your age is >= 18 and then spit back the signed token. If the rule is something they don't understand, they just don't sign it. It fails "safe" (i.e. not verified).

I mean, if your DMV account can display your age/date of birth (which I imagine most can do), then that's it. They don't need anything else aside from making a public key visible.

 

[GaidinBDJ]

I'm not sure I really want the DMV (or other government agency) finding out which sites I'm visiting, though. I also feel like this could easily become an oracle for identity scammers to verify information. You could find out which names were valid in a given jurisdiction, and by repeatedly manipulating the age field you could determine someone's birthdate.

That's the thing. The DMV doesn't know who the original source is. All the DMV knows is you gave them a token and they were asked to verify you're over 18. When I'm saying the site does hash( userid + site + secret_salt) the DMV sees none of the internal stuff. They just see a hash. They can't see any of the actual information inside. They just see "HASH, age >=18".

And they couldn't repeatedly test because you're in the middle. The DMV isn't just taking random tokens from anybody who asks. This is a token you provide to them once you're logged in tot the DMV site. And then you take the signed token and pass it back to the site yourself. At any point in this process, you can choose to abort. You can also see what rule the site is asking for. If the site gives you a token like {HASH, age >18 AND address = 123 main street} you can just go "Eh, I'm not passing that along" and the exchange is over.

 

[GaidinBDJ]

If the only thing you have is a single boolean value from the verifier, that isn't a strong enough assurance if I were running the site. It's not enough to validate their age once, but continuously in anticipation of any changes that need to be made (age gates being raised for example), as well as possible erroneous or fraudulent validations as well.

I'm for collecting the bare minimum neccessary for this to happen, but what that means is determined by Legal.

I think you're not understanding what's happening here.

If you're running a site, what you're getting is signed message verified by something like a state DMV that the user in question is 18 or older. If the user is 18 or older today, they'll always be 18 or older. The user will never, ever be younger than they were when their age was verified (since, y'know, linear time and all).

If you're running a site where you want to verify users are 18 or older, the only thing you need verified is if they're 18 or older. That's a single boolean value. There is absolutely no reason you would need to know if they're 18, 28 or 98. All you need to know is if they're 18 or older.

Even if, in some weird circumstance, you needed to know a user's exact age, you could just make a token with the rule "age = 42" or whatever. They could choose to pass that token to the verifier and it'll be signed if true.

 

[GaidinBDJ]

You'd need to know the exact age because rules and regulations are going to differ. Laws and regulations could concern persons of various age groups.

On top of that, for your scheme to work the verifier would've had to put a reference in whatever message they're sending that could point to a user so it could positively prove their age via an audit trail. Hell, I don't even see the whole point of engineering this whole thing given that present day solutions already exist for this, and have been practiced everywhere that sells alcohol in America.

You still don't need to know their exact age, only that they are at least the age required by law. If you wanted to check different jurisdictions, then the token would look like {HASH, age >= 18 AND state = NV}. Even if you did absolutely have to know their exact date of birth for some reason, then you just make the token {HASH, DOB = 1/1/1970} and have them get that signed. You now have the verified the required information without the user having to compromise any other private information.

The audit trail is "here is the signed token." You compare the signature against the public key of the agency the verified it. Done. The DMV doesn't need to keep track of what it signed, it only need to check the rule and sign it. The site knows what token it generated for you, so if you pass back a signed token that doesn't match, they can reject it (which prevents replays and using the same token for different sites).

And this system is not implemented. When you buy alcohol, you have to show your identification which provides the store with all your information, including your identity and full date of birth. The store doesn't actually need to know your identity and date of birth, only that you're over 21. There's a reason I don't use my state ID when I'm buying age-restricted things; I use my passport which contains less information (notably, it doesn't have my home address on it). But that's still not ideal because the store still gets to learn my identity, which is doesn't actually need to know.

How do I get the token, then, and what prevents someone else from creating one on my behalf?

They could make the token, but without you in the middle to pass it to the DMV, there would be no way to get it signed. The signing part wouldn't be something public, it'd be something inside your account. Just a text field you could paste the token into and have it spit back a signed token (if the rule is true).

 

[GaidinBDJ]

If the DMV isn't keeping track of what it signed then how can it be relied upon for validating someone's identity in this verification scheme?

If the authorities did an audit and believed that someone was underage on a service they weren't supposed to use, they would need to be able to follow that trail to positively confirm their age.

I mentioned the ID at the bar example because positively confirming someone's identity is the only way to positively confirm someone's age. A third party verifier could hand out "bar passes" to those of age so they wouldn't hand out their true ID to the barkeep, but the verifying entity would still need to retain the subject's actual ID information that the bar pass could point to, and the bar pass would contain information that could point to the persons true ID.

It can be relied on because anybody can look at the DMV's public signing key and confirm that the token with the rule was signed by them. It's a pretty well-established and secure cryptographic concept. If the authorities wanted to check this, they just have to take the signed token the site has and compare it to the DMV's public key to know the DMV did verify that the rule in question is true. The site can't lie about the token to authorities (because the signature would no longer validate if it's tampered with) and the user can't forge tokens because the site can just check with the DMV.

The site doesn't have to ask the DMV anything personal about you directly and nothing in the token needs to point to your actual identity in the DMV system; they just need to be able to see the DMV's public signing key to know that the signed token you gave them back was legit.

For your bar pass system, it work like this: The bar takes a picture of you,prints it out with a note saying "This person is 21 years old", and puts their thumbprint on it. You then take that pass to the DMV who checks their records, sees that's true, and then laminates the pass (we're pretending this is magical lamination that can't be duplicated and can be easily confirmed as real, just like a cryptographic signature). The DMV has no idea which bar is for, and they don't need to know (we're also pretending they can't look up the thumbprint, that'd be hidden by the hashing in the real token). You then go back to the bar and hand them the pass. They can see it's been laminated by the DMV and know you are 21. If the liquor authority comes in and accuses them of serving you underage, the bar can just show them the pass and the liquor authority can confirm it's the DMV's lamination and know you're 21. If you tried to give the pass to a buddy over 21 to get laminated, they couldn't because the photo wouldn't match. If you tried to swap out the photo, you couldn't get the DMV's lamination to seal it. If you tried to re-use the pass at a different bar, it wouldn't pass because the thumbprint wouldn't match. If you tried to change the rule (to, say, "This person is over 10 years of age), the bar would know to reject because that's not what they wrote when they gave you the token. And the bar never need to know any other information about you. Y

I mean, that's not a perfect analogy, but I hope that got across what this process actually is.

 

[GaidinBDJ]

I think the problem is if you're accused of allowing a specific person that's underage, you need to be able to show that specific person gave you proof that you can trace back to their record at the DMV. An anonymous system doesn't provide that ability to prove what happened later.

Note that in most states, if you accept a fake ID you're still at fault for letting the person in, even if the fake is convincing.

Then you give them the signed token that specific person gave you. You'd have that signed token linked to their account the same way you'd have something like a photo of their ID linked to their account.

That is only secure if the site and the DMV don’t both save the token and the user has no way of verifying that. The site would want to save the token to prove that an age verification was done. The police could demand a user’s verification token from the site and then demand that the DMV look up who authenticated for that token. The DMV could also sell the token associations to advertisers to fund the service like the post office does with advertising.

Well, the site would save the signed token and that's no problem because the token doesn't have anything in it that the site didn't generate itself.

The DMV has no way of knowing what the token it for; it only knows what rule it was asked to verify. There's no reason to keep them and, as a public agency, they'd be accountable to the public if they did. And sell what to advertisers? The DMV gets nothing worth selling. They can't see what site is requesting the information. They only know someone asked if you were over 18, which is information they're already holding. It could be from Facebook, or Discord, or it could have been from me asking you to prove your age just person-to-person.

And, yea, if the police knew what site you used, which account was yours, and could get warrants for the site and for the DMV records (if the law allows them to keep them), they could correlate them. But, at that point, they'd have to know enough about you that the privacy matter is moot. But that's not really the point here. None of these verification systems are to thwart legal processes, but this system is to thwart companies from mass-collecting data about people they have no actually need to know.