Prevent spammers by using a hashed user id in web applications

167 views Asked by At

I am building a web application that allows users to send messages to other users. On the send message page I currently have the user id of the receiver in the URL so the application knows where to send the message i.e. example.com/send-message/user-id/1. The user id is the primary key used to identify the receiver in the database

I am concerned that spammers could go to this page and just keep changing the user id in the URL and spam people on the site very quickly.

The solution I have come up with is to make a long unique id (123154123412). This number will be stored in the user database row and would be used instead of the primary key on the send message page so that a spammer could not easily spam lots of people by changing the id.

Are there any potential problems with this approach that I may have over looked?

If I was to use the unique id throughout the site would it slow the site down significantly. In other words is it quicker to search the database using a primary key than a generated unique id.

Thanks

3

There are 3 answers

0
SergeS On

Another thing you can do is to block sessions or ip addresses temporarily when they send too many messages in short time ( eg. 1 min between messages and max 5 messages per 15 min ).

0
jprofitt On

I would say it's generally a Bad Idea to allow people to arbitrarily message other members on a website (unless that's the point of the site I suppose). You might prevent automated spam bots, but there are plenty of people willing to pay an actual human to go around and send messages manually. First and foremost, you should probably only allow a logged in member to send a message to someone else who has "accepted" that member in some manner -- a friend, allow messages from, etc.

As far as using a long UID, as long as you have your database set up properly the only performance "hit" might be when you generate it, but it's not going to slow your site down if you use it in place of the primary key ID.

0
Your Common Sense On

This approach is absolutely useless.

As long as users of your site allowed to send messages to other users, the spammers will use whatever id you invent.

The only way is to limit the number of recipients and/or messages per hour.