Security and Inquisit 3 Web Edition

Running experiments and gathering data over the internet introduces potential security issues that may not exist when running experiments on tightly controlled lab computers. Without taking the proper security precautions, it may be possible for "snoopers" to browse your scripts and data files. This could be a big problem for scripts that contain login credentials, or for data files containing confidential or sensitive data. Malicious hackers could even delete your scripts and data. Obviously, that's not a good thing.

Inquisit has several security features, described below, that enable you to protect your assets.

Protecting your scripts.

In order for Inquisit Web Edition to be able to load your scripts from the web, they must be placed on a web server, where it is potentially accessible to anyone with an internet connection. Inquisit supports two strategies for preventing unwanted access to your scripts. First, you can configure the web server to provide access only to authenticated, authorized users. In this case, users will receive a login prompt when Inquisit loads the script, and they must enter a valid userid and password to continue. Second, you can obfuscate the script using Inquisit's built in password encryption system. Anyone who attempts to open the script with Inquisit must first supply the password used to encrypt it. If they attempt to view the script in any other program, they will see nothing but garbage characters.

Authentication Methods

There are a number of different authentication schemes used by web servers to protect content from anonymous access. The following schemes are supported by Inquisit.

Basic Authentication

When Inquisit attempts to load protected content, the server sends a message indicating that authorized credentials are required, and Inquisit will prompt the user for a username and password. If the user supplies credentials, they sent the server, which determines if they are valid and provides access to the content accordingly. Basic authentication works over firewalls, and is widely supported by almost all browsers and web servers. An important caveat is that the userid and password are sent over the network in plain (unencrypted) text, which means they could be read by someone with a packet sniffer. Basic Authentication by itself should not be used for any content that requires real security. However, Basic Authentication used in combination with SSL (otherwise known as HTTPS) is a secure alternative.

Digest Authentication

Like Basic Authentication, when Inquisit attempts to load a script using Digest Authentication, the user must supply a valid userid and password in order to continue. The advantage of Digest Authentication is that the credentials are encrypted before being sent over the network, so they are not vulnerable to packet sniffers. It can also be used to for authentication across a firewall. Digest Authentication is an open standard that is supported by most browsers and web servers.

Integrated Windows Authentication (NTLM)

Windows Integrated Authentication, also known as NTLM, provides another secure way to protect your script. This method protects login credentials by a sophisticated series of handshakes between the client and the web server. Mozilla added support for NTLM in version 1.4, so it is now supported by Firefox and Netscape (as well as IE).

Configuring Authenticated Access to Scripts on the Web Server

To protect your content from unauthorized access, you must place it in a protected folder on your web server. Most web servers have fairly simple setups for protecting a folder. For example, with the Apache web server you can protect the content in a folder using basic or digest authentication by adding a special password file to the folder.

With Microsoft's IIS web server, you can lock down a folder through IIS Manager by right-clicking the folder, selecting Properties, and clicking on the Directory Security tab. From there you can launch the following window. By default, folders allow anonymous access, which means anyone can browse the content. By unchecking this box and checking one of the other options, you and protect the folder.

Encrypting Your Scripts

Encrypting your scripts is another way to prevent unwanted snoopers, whether you are running experiments in a lab or over the web. An encrypted script can not be read unless the user has the password that was used to encrypt it. If you don't have the password, the script is illegible.

Importantly, for web research encryption should be considered a deterrent, not a foolproof security mechanism. The reason is that in order for the Inquisit Web Control to read the encrypted script, it needs to know the password. Thus, you will need to include password in the web page used to launch the file. A clever hacker could figure out that the password specified in the launch page is the same one required to read the script file.

See Introducing Inquisit 3 Web Edition for details on how to provide the password to the Inquisit Web Control.

Protecting your data files on the server.

By default, Inquisit Web Edition (IWE) saves the data to the millisecond.com web server. IWE uses SSL to encryt the data before sending it over the wire so that it is protected from network sniffers. Once the data has been saved to the server, you must login to the web server using your Millisecond userid and password in order to access the data files. Without the userid and password, the data files can not be accessed. Using the Millisecond Data Service is the easiest and most secure option for saving data over the web.

Inquisit also supports saving data back to another web server using HTTP POST, or to an ftp server. In either case, you can protect the server (or the particular folder on the server) where you intend to save the data files using basic authentication. You can then specify the userid and password required by Inquisit to access the server in the data element in your script. If your script contains a userid and password for accessing your data file share, you should always save it as an encrypted inq file rather than a plain text exp file.

Whenever saving data to a web or ftp site, it is good practice to move the files to a more secure location (e.g., not accessible from the internet) as frequently as possible. Ideally, you should write an automated process that moves the files according to a regular interval, or better yet, whenever it detects that a new data file was created.

Alternatively, Inquisit allows you to email the data file to the email address of your choosing. The nice thing about this approach is that you don't have to worry about putting login credentials in your script where someone could potentially see them. Make sure you have enough space in your mailbox and that your spam filter doesn't mistakenly strip out the data file attachments.

If your data files contain sensitive information, you can instruct Inquisit to automatically encrypt using the encrypt attribute of the data element. This is a useful privacy mechanim for data gathered over the web or on the desktop. Again, do not forget the password that was used to encrypt the data file, or your data will be lost.