Posts Tagged ‘security’

Preventing fake signups

The problem

One annoying problem I began encountering with ScratchGraph a while ago was fake signups. Every so often I would notice a new account created but there would be no interaction on the site beyond account creation. I’d also notice some other errors in the application log, as the spam bot would attempt to fill in and submit every form on the landing page, so I’d get login failure and reset account errors as well. At first, I figured I could just ignore this; metrics would be a bit off, I’d have a bounced welcome email from time to time, and I could just purge the few fake accounts at some point the future. Unfortunately it got to the point where there were so many fake accounts being created that figuring out if an account was real took more effort, there was a lot of garbage in the database and logs and, perhaps most importantly, welcome emails being sent out would be bounced or flagged as spam, dragging down my email reputation and increasing the possibility of emails going to spam.

A solution

There’s a bunch of blog posts from email marketing services detailing this issue, e.g. Mailchip, Folderly. There’s usually a common few solutions mentioned:

  • Email confirmation for new accounts
  • Some sort of throttling
  • Honeypot fields

I opted for honeypot fields.

  • I wanted to minimize dependencies and additional integrations, so no ReCAPTCHA
  • Email confirmation seemed like too heavy of a lift and I disliked the idea of having a user jump from the application to their inbox

  • Throttling kinda makes sense (I could see if other forms were submitted around the same time, with the same email address, and flag the account), this is possible but not trivial for a PHP application where you don’t have service-level jobs running in the background
  • So, I added a honeypot field on the signup form. In practice, I wrapped a text input in a hidden div and I gave the input the name fullname. A user’s full name is also not requested/collected during sign up and I figured the spambot may try to gauge what to do with the field based on its name, so I should give it a realistic name. On the backend, if fullname is non-empty, the request still succeeds (HTTP 200), but an account is not created. Instead, email and IP address are logged in a table for spam signups (I figure I might be able to do something with this data at some point).


    I was somewhat skeptical as to how well a honeypot field on the signup form would work, I was imaging spambots being incredibly sophisticated, maybe noticing the field was hidden or there was no change on the frontend. Turns out this is not the case or at least not the case for the spambots I was facing. From what I can tell, this relatively simple approach has detected and caught all fake signups from spambots.

    Fake signup caught via honeypot field

    I imagine there’s a shelf life to this solution (happy to be wrong) but, when it starts to fail, I can always integrate another approach such as throttling or ReCAPTCHA.


Something I haven’t thought about much, but very important: for sensitive information, turn off autocomplete on input tags.

<input type="text" name="super-secret-pin-num" autocomplete="off" />

It’s a non-standard attribute, but all the major browsers implement it (including Webkit/Safari).

h/t Pete Freitag

Network security and filthy lies told by Windows XP

Note: Everything below relates to Windows XP Professional with Simple File Sharing turned off.

One of the simple things that can be done to prevent unwanted peer-to-peer network access to data on Windows is to disable the Guest account (you can alternatively give permissions to specific users or groups, but for my situation this is a hassle as I, generally, don’t need the level of granularity). By some mechanism unknown to me (perhaps malware or a recent virus), the guest account on my desktop was turned on. With the guest account on and shared folders allowing everyone access, any machine connected to the network was able to seamlessly login and access anything in the shared folders. The situation bugged me for quite a while as I didn’t realize the active guest account was the culprit because from looking at the User Accounts extension in Control Panel, I saw the following:

win xp guest account off

Unfortunately, this does not mean the account is actually disabled, it simply means it doesn’t appear on XP’s welcome screen. I finally took at look at the Administrative Tools >> Computer Management extension, then navigated to Local Users and Groups >> Users, and saw that the guest account was enabled. Disabling it here (right-click on Guest >> Properties >> check the “Account is disabled” checkbox), actually disabled the account and prevented automatic authentication as Guest for incoming peer-to-peer connections.

win xp users

As you can probably guess my real annoyance here is the discrepancy between what appears in the User Account extension vs. the actual state of the account.