Preventing Fraud with IP address Logs

Security often comes at the cost of convenience. Authentication procedures and similar guards against fraudulent activities are no exception. Think, for example, of the hassle you have to go through if you really want to prevent credit card fraud. In this case, the authentication measures and safeguards may include:

• Alerting your bank and/or credit card company when you will be travelling (because otherwise everyday purchases at a store are flagged as “irregular” due to your location, triggering an automatic freeze on your account(s) during what had been (until that time) your “vacation”).
• Getting your card shut down because you failed to verify a large purchase in time.
• Having your account frozen on a semiregular basis because your purchases are flagged as “suspicious” (with the understanding that all too often “suspicious purchase” seems to be equivalent to “online purchase”).

…and so on. Or you could be really zealous about credit fraud and contact all three credit agencies to initiate a credit freeze, which is a powerful safeguard but also has the downside of seriously inconveniencing you, too.

This sort of convenience compromise, though, isn’t a given. As a counterexample, compare biometrics to an ID badge that can be easily lost. It doesn’t matter how scattered or forgetful one is, or how serious a case of Absent-Minded Professor Syndrome one has, it’s hard to forget your thumbs or irises at home. Alternatively, and more relevantly, consider single sign-on (SSO) authentication. Setting secure passwords to the various devices, sites, applications, etc. isn’t too difficult, but remembering them can be. Remembering to change them, and then remembering the new ones, can be even more of a challenge. SSO authentication is closer to a kind of “thumbprint” password in how easy it can be to prove to your own device or your network that it is in fact you trying to gain access. And SSO doesn’t require the kind of technology that high-end, biometric-based security does.

So while authentication, fraud detection and protection, and similar services can involve all sorts of convenience compromises, they need not (at least not always). That is, there are authentication and fraud detection methods that don’t involve compromising convenience. SSO authentication is one example. The Sona platform includes many more. Most of these are features so integrated into the platform they don’t require any action that could be inconvenient. Other methods of user authentication we offer simply extend those you use already, such as SSO authentication integration.

That said, Sona administrators have a certain flexibility when it comes to particular system settings that can involve balancing control and convenience. Even SSO doesn’t need to be a one-size-fits-all scenario. Sona offers “Partial” automatic account approval for certain SSO sites. This allows participants who have SSO accounts to receive approval automatically, while non-SSO users require account approval. You can read all about this SSO option here: New “Partial” Automatic Approval Option for SSO Enabled Sites.

While we like offering a flexible, adaptable platform to fit your needs, we’re not so keen on giving in to the convenience compromise if we can possibly avoid it. So we added an additional way for administrators to choose convenience while providing checks to unauthorized or fraudulent activity : IP address logging.

As you might expect, we’re going to introduce, explain, and demonstrate this new feature shortly. What you may not expect, and what we’re rather proud of, is just how seamlessly the new IP address logging feature works within the Sona platform and alongside other features you are already familiar with (making its use all the more effortless). To start, then, we’d like to set things up with a bit of Sona-specific context now.

For administrators, one of the great conveniences Sona offers is allowing participants to create their own accounts without any further action needed. Of course, there is a bit of a trade-off here. On the one hand, requiring administrators to create all accounts can be quite time consuming (but not always—if your pool consists entirely of one or two courses offered every semester, then having a roster template allows you to use the User Import Wizard to easily create all the accounts needed every semester).

On the other hand, you may want to exercise more control over the account creation process without having to create every user account yourself. That’s why we offer various in-between options, balancing convenience and control. Administrators can, for example, allow participants to create accounts that will require administrators’ approval.

Fraudulent account creation is not, alas, where possible fraud-like behavior ends. We’ve no doubt that not a single participant on your Sona site would ever dream of even thinking about misrepresenting whether or not they signed up for a study, or claim they were logged in at such-and-such a time when they were not. But participants registered on other Sona sites (not yours, of course) have occasionally made statements that invoked a certain degree of warranted skepticism, as in the following examples: “I logged in every week and there were never any timeslots open!”; “I completed the survey through the Sona site, but something happened and I didn’t get any credit!”; “No, I haven’t been filling out other participants’ surveys for cash”; etc.

Ok, the last example there isn’t one we’ve heard about. Individuals who want to fill out as many surveys as possible (why worry over response quality) already have sites they can go to. Much more likely are participants claiming they were logged in at such-and-such a time or any number of similar examples. And these are, admittedly, far less serious than hackers trying to create one or more accounts or the more general cases of suspicious activity.

The point is that, no matter how secure your system is against unauthorized users, that still leaves open the possibility of authorized users engaging in questionable activities. And while most security issues, particularly anything to do with hacking, are handled automatically by Sona’s built-in protection systems, there are times when Sona administrators might want some additional information about user activity.

That additional something’s called an IP address, a unique address assigned to a computer or device connected to the internet, and we’ve incorporated IP address logging into existing records of user activity. This includes newly created or requested accounts as well as individual users’ activities (such as login times or study sign up times). To illustrate, we’ll start with how to use the system’s IP address logging feature when looking at recently created or requested participant accounts.

To view recently created or requested participant accounts, open the “User Management” dropdown menu. Depending on whether your Sona site is configured to require account approval or not, you will see one of the two options displayed below:

Either will work for our demonstration, so just select the one you see. This will take you to the page of recently requested or created participant accounts. If your system allows participants to create accounts without requiring approval, you might be looking at a table similar to the one below:

This table (or one like it) is no doubt quite familiar. After all, the menu option to navigate to this page isn’t new. But if we look a little closer at the “Creation Date” column…

So not only can you see the user-supplied information in the full table of recently created/requested accounts along with the date, you can also now view the IP addresses used on that date by that user. Moreover, this IP address is a clickable link (we’ll go over how IP address work as links and to what sort of pages below). Note how IP address logging in this example doesn’t involve going to a new page or generating a new kind of report. It is incorporated into existing activity monitoring features Sona already offers. It’s a particularly useful addition because it represents a different kind of information. Most of the information on this table is what somebody put into the form they used to create or request their account. It’s user-dependent information. The IP address is not.

This extra information, both in this context and elsewhere (as we will see) comes in handy precisely for this reason. To get a better idea of what we mean here, we’ve brought in an expert user, Real Person, to demonstrate what questionable activity might look like on your site and how the information from IP address logging can help:

Having two requested or created accounts at almost the same time is perhaps suspicious by itself. Usually, though, an individual creating a duplicate account won’t have a name like “Real Person”, much less attempt to create the duplicate account under the moniker “Fraudulent User”. But IP addresses give user-independent data, telling you where the account request or account created originated from. So even though it’s generally more difficult to determine if two accounts created back-to-back are really two legitimate users (and the timing is a coincidence), or if something else is going on, IP address logging makes this much more transparent. Two users at almost the exact same time is one thing, but two users from the same IP address? That’s more likely to be the “something else” we mentioned.

In many cases, the “something else” isn’t anything nefarious at all. Being able to check IP addresses like this is certainly a security feature, but only one piece of the story. Suppose, for instance, that two different users live in a dormitory and share a Wi-Fi router (which would explain the duplicate IP address). In this case, the user-dependent information (e.g., User IDs and names) comes into play, showing that the two requested/created accounts came from two different people accessing via the same IP address. But the overall point remains the same: Now, in along with specific dates and times, the system gives you an additional piece of important information you can use for fraud detection and prevention.

This is a good time to mention another way in which IP address logging works when it comes to account creation. If you have Administrator Account Notification Email enabled (select “System Settings” from the “Set Up” dropdown menu to check this), then any attempt to create/request an account from an IP address used by an existing account will automatically trigger a notification email sent to you. The example email below illustrates just such a notification (suitably altered to draw attention to the relevant details) such as it might be seen on common email platforms:

We’re still only on the first example of how IP address logging works, and we’ve not only seen how naturally it appears in a well-used context, but also how email alerts, an independent process, likewise smoothly integrate IP address logging into an existing task such as account approval and/or participant account self-creation. We’re not done, however, so if you’re following along in your Sona site, don’t leave this page yet. We mentioned above that those IP addresses are clickable. Now comes the promised explanation on how these links work.

We’ve just seen how selecting the View Recent Participants/Approve New Participants page includes IP addresses for new accounts created or requested. Each IP address is a clickable link, so let’s give one of these a try, just to see where it takes us:

When you click on an IP, such as in the image above, the link brings you to a page of user accounts who have logged into your Sona system using that IP. So, for example, we can imagine clicking on the IP address as in the above picture. The link brings us to a new page with the following information:

As you can see, our resident fraud expert has been rather busy. Note the highlighted IP address in the upper-lefthand corner. This lets you know that all the users on the table were logging into their accounts via this particular IP address. Now, if it were simply the case that two different, authorized users logged into their respective accounts using the same IP address, this may very well be of no concern. Lots of participants, as well as researchers, share computers and network access. This could be a research lab computer, for instance (not to be confused with a computer located in a computer lab, that could explain why accounts belonging to authorized participants have the same IP address).

Things get more suspicious when we see that this same IP address was later used to request two different accounts on the same day. It’s still possible that four different individuals, two of them with Sona accounts and two of them requesting Sona accounts, all used the same internet access. It’s not particularly likely, however.

In practice, one could contact authorized users and reach out to participants requesting accounts if and when a duplicate IP address is flagged (whether via email notification or just from looking over the IP addresses in the table of recently created/requested accounts). But it would be nice if we could, at least in principle, easily learn even a little bit more about user activity from IP address logging. Perhaps, instead of looking at the activity associated with a particular IP address, we might want to reverse things a bit and look at IP addresses associated with user accounts. Maybe just by following clickable links as we did before…

Sona administrators can now look at individual users’ login dates alongside the other user information they need. So if you were looking at the login activity associated with a particular IP address (as in the previous example), clicking on the user’s name would immediately bring you to their record page.

This is, however, not the only way to access this information. This is a good thing, because most of the time you might be interested in a particular user’s login activity it won’t be because you clicked on an IP address from the list of recently created/requested accounts. So to give you a better feel for yet another way your site incorporates IP address logging into familiar pages and tasks, we’re going to approach user-specific login activity from another perspective, in another way. You’ll still see the same kind of information you would had you clicked on a user name associated to a particular IP. But for this example, we’ll start at the home screen you see every time you log in to your Sona account.

In fact, for this example, not only can you start at the beginning (as if you’ve just logged in), you can even look at your own login activity. Select “View and Edit Users” from the “User Management” dropdown menu. This will bring you to the search screen, where you can type in your own name (if you want) or select a name from the list of e.g., of all researchers or administrators you can generate using the radio button options:

Selecting a user will take you to the records page for that user. One reason you may want to select yourself in this case is for illustration purposes. Apart from anything else, you will ensure that a login record exists simply by virtue of being online! The section of the records page you’re looking for will be on the right, under the name “Login Activity”, as shown below:

We should probably point out here that a boring looking login history is a good thing. The fact that the example user’s Login Activity, as displayed above, shows the same IP address repeated many times means that the user logged in to their account from the same place, even the same device.

This is not to say that seeing different IP addresses is any cause for concern by itself, of course. In many cases, you might be interested in a particular user’s login activity not so much to identify suspicious IP addresses, but to check that there actually is one for a particular date and time.

For example, if a participant says that they definitely logged into their Sona account on X date around Y time to complete an online study, then there will be an IP address in that users Login Activity record. If there isn’t, well…

You can, of course, still track overall usage in a myriad of other ways, such as Login Days Tracking. Login Days Tracking provides a useful way of seeing the number of unique days a user has logged in. By way of illustration, suppose you are running a Credit Completion report for a particular course. You can select “Yes” to the option “Include Login Days?” so that the report includes the number of unique login days for each participant in that course. This will certainly give you a good, overall measure of user activity. But if a participant swears they were logged in to their account to complete some online study before the “complete by” time, and couldn’t access the study, Login Days Tracking won’t help much. IP address logging, on the other hand, will tell you whether the participant actually was logged in at that time.

As just one additional important, security-related example for IP address logging with an individual user’s record, consider a more serious problem. Suppose a participant reaches out to say that something happened with their account. If the last login activity for that user came from an IP address that they’d never used before and corresponds to a location in another country, it may be that their account was compromised.

This just about concludes the presentation of our latest fraud detection and deterrent feature, at least for now. As is often the case with such features, IP address logging is already seamlessly incorporated into existing monitoring services provided by Sona. There’s no extra report you must generate to use this feature, no new page to remember to visit, and even the genuinely new component (email alerts for duplicate accounts) is automatic. It’s truly the biometrics ease vs. convenience compromise (i.e., no compromise at all). We just wanted you to know where to look, and to help you to know what you might want to be looking for. The rest is all about you making things easier for yourself, all the while making your Sona site more secure for everyone.

We also want to let you know that this isn’t the be-all-end-all in terms of new features for fraud detection (a phrase we did say 10 times fast). And while we offer, for example, randomized password generation services, users can still opt for passwords that are less than ideal. We can’t rewrite the basic network architecture and protocols the web (and internet more generally) run on to make everything as secure as we’d like (but we can, and have, come as close as is possible with our cloud provider). Nor can we stop your participants from simply giving out their passwords to others and, for example, asking them to take an hour long survey in their stead. For that, we’d need to employ something like webcam enabled ID verification, and…that’s quite likely a future feature.

In fact, a number of new features currently in development or recently released concern, or are related to, authentication, fraud detection, and security more generally. IP address logging is just one weapon in the arsenal you have at your disposal to combat fraud. And we’re glad to offer it.