Implementing Anonymous Posts on Gurlic

Upon login, one-way hash their password plus a fixed random string (NOT the same one as used to authenticate that they are logged in!). Then store that in a cookie.

When they post anonymously, store the value of that cookie in the database as-is (and don't validate it - you can't validate it anyway, you (hopefully) don't have their password). To edit a post, check that the value in the database matches the one in the cookie.

Remember: Unlike the authentication (session) cookie, this special cookie is never stored in a way that links it with their real user info.

This does not allow password changes, but that's probably OK since edits are usually done relatively soon after posting.

(If you really wanted to allow password changes, then every time they change passwords, update all of the matching hashes in the database to the new hash.)

A tip: Generate a list of harmless words (say you have 200 words).

When the user posts, one-way hash the value from the cookie, plus the topic (or thread) ID (whatever you use to group messages). And calculate the value of that hash mod 200, and call the user "Anonymous word4".

This way if the users posts more than once in the same topic, you can see that it's the same person - this makes conversation a lot easier.

I don't see why you couldn't add another column with an auto-generated phrase/key that can be used after the fact similar to when you enable 2fa. Anonymous posts would have an edit that takes said key which would be saved by the author if they so desired.

bro how do you police that? what happens if people start uploading highly illegal stuff anonymously and you truly keep no record of who did it?

doesn't this make it a lot easier to vandalise the site? normally they'd at least have the cost in time/resources required to create an account, which you can throttle somewhat and in the best/worst case at least it isn't just a click

just curious if this won't be a problem or you have some measures in place to go around it

> That is a little tricky though, because there has to be some record that ties the user to the post itself - which defeats the purpose of anonymous posts. In the case of a database leak, that connection is out in the public. We don't want that.

And if it's a randomly generated string then it's only useful if the attackers can discover who it belongs to... I don't see the issue.

The way I approach this is by allowing users to use pgp for identity management, with one-click signing and two-click keygen in a friendly web ui.

Then any modifications are just a matter of sending a signed token like #remove or #edit.

> which defeats the purpose of anonymous posts. In the case of a database leak, that connection is out in the public. We don't want that.

Um, you should be logging IP, in case someone posts illegal materials, is spamming, etc...

A per-post bearer token either input or generated at post time is a pretty straightforward way of doing this. The former would be similar to a temporary password; imageboard-style tripcodes use a similar mechanism for a different purpose (having awkward-to-forge “same author” marks in otherwise-unauthenticated posts by showing a hash of the display name + tripcode).