The scenario i was thinking of is someone uses gpus to brute force a conflict between a real title and the normalized version of a naughty string.

So e.g. if "Dog" and "Bawolff sucks...GHHDCBTSfgjbftgdthn" collide after normalization (this is just a theoretical example, they dont actually collide), the vandal could create the page "Bawolff sucks...GHHDCBTSfgjbftgdthn" on an obscure language and now suddenly the en page for Dog has an interlanguage link to a maliciously titled page, and the users dont understand what happened.

@Bawolff well, right now, all the vandal has to do is go to the page and add [[nds:Bawolff sucks...GHHDCBTSfgjbftgdthn"]] to the page... Granted, the fix is a bit less obvious, but deleting a page is easy enough.

Oh, btw...

@Addshore do we have a way to prune the titles table, so we don't accumulate too much garbage there?... I don't see a good way, really.

In T156240#2971262, @daniel wrote:

@Bawolff well, right now, all the vandal has to do is go to the page and add [[nds:Bawolff sucks...GHHDCBTSfgjbftgdthn"]] to the page... Granted, the fix is a bit less obvious, but deleting a page is easy enough.

I agree its somewhat of a far fetched scenario (since its high effort for a relatively low amount of disruption). As I said in the parent task, im not sure how important this should be. Maybe we should just document it and deem it an acceptable risk. However the more I think about it the more I like the idea of mitigating by using a keyed hmac with a secret key (to prevent offline attacks)

Change 334316 had a related patch set uploaded (by Addshore):
Log hash key conflicts

https://gerrit.wikimedia.org/r/334316

Change 334316 merged by jenkins-bot:
Log hash key conflicts

https://gerrit.wikimedia.org/r/334316