Alphanumeric passwords have long been the primary method of authentication and access control on the Web. In recent years, however, relying on passwords as the sole method of authentication has proven to be unsustainable and not secure.

Research shows that authentication-based attacks were used in the majority of major data breaches in 2012. Simply moving beyond passwords to implement stronger forms of user authentication would prevent nearly 80 per cent of hacking attacks on companies.

Because people often use the same password on multiple websites, a large-scale password leak at one site creates a domino effect that harms security for many other websites and applications. When 1.5 million user credentials were leaked from Gawker Media Group, spammers and hackers immediately used those credentials to access user accounts on other websites. Hundreds of thousands of accounts on Twitter were compromised and used to spread spam and malicious links. Amazon and LinkedIn had to enforce password resets for their entire user communities.

Such debacles harm not only the individual users whose accounts are compromised; they also harm the organization, website or application itself. The negative repercussions of a data breach can include legal liability, fines, loss of customers, damage to brand reputation, plus the cost of fixing security and IT systems amidst a crisis.

When hackers stole more than 8 million user passwords from LinkedIn and eHarmony accounts in 2012, LinkedIn estimated it spent more than $1 million to clean up the breach and would need to spend another $2-$3 million for additional security upgrades. In 2011 Sony was forced to spend more than $170 million to remedy the fallout from a data breach that leaked more than 100 million PlayStation passwords.

Mobile developers must also consider better authentication methods. The majority of smartphone and tablet owners do not password protect their devices, despite having them connected to sensitive applications including work networks and banking applications. Users do that because typing passwords to log into mobile apps is too cumbersome. Experts at the CTIA Wireless conference even stated that growth of mobile commerce will be stunted until new, easier-to-use authentication methods are developed.

To achieve effective, strong user authentication on websites and applications, developers must balance security with usability. Do this by evaluating the security needs of the business as well as the characteristics of the user population. Is the user base comprised of employees, business partners, or the general public? This will help determine risk level and how stringent the authentication requirements should be.

Recommendations For Strong Authentication

Make sure the basics are covered

Since most websites and applications will likely choose to continue using a password as the first layer of authentication, make sure these basic security measures covered:

• Enforce a dictionary check to ensure that users cannot choose common words for their password.
• Require a strong username that includes a numeric character. Often the username is the easiest portion of the login credentials for a hacker to guess. Do not use the user’s email address as their username.
• Limit the number of failed login attempts to three and temporarily suspend account access unless the user can authenticate through other means.
• If the login fails, don’t identify which portion of the credentials was incorrect. Stating that the ‘password is incorrect’ or the ‘username doesn’t exist’ enables hackers to harvest account information. A general statement such as “Incorrect login, please try again” helps prevent account harvesting.
• Use SSL to create an encrypted link between your server and the user’s web browser during account enrolment, the login process and the password reset process.
• Provide users with advice on how to choose a strong username and password. Research shows that users do choose better passwords when given advice on how to do so. One option is to have a password strength meter built into the page.
• Hash user passwords using bcrypt, scrypt, or other hash algorithms specifically designed to store passwords. Do not use SHA1, MD5 or other algorithms that were not designed for hashing passwords, as they are not secure.
• Use Salt. Use a unique salt for each user account/password and store that salt with the password. An additional layer of system wide salt that is not stored with the password can also add extra strength if the database is stolen because it is not stored with the passwords but is known to you.

These steps may seem rudimentary to some readers, but a study conducted by researchers at Cambridge University showed that most websites did not even enforce these minimum standards.[i]

SaaS solutions for generating one-time passwords

With the growth of Software-as-a-Service (SaaS) providers, it’s easier than ever to adopt authentication solutions that generate one-time passwords for users without any hardware investment or significant integration efforts. While one-time passwords will not stop a sophisticated man-in-the-middle threat, they do protect against the most common security threats: users choosing weak passwords, reusing the same password or having their passwords stolen using keystroke-logging malware.

By generating one-time passwords for users each time authentication is needed, organizations can ensure strong passwords are used and that previously stolen or leaked passwords cannot be used to access accounts.

The growing number of user devices with touchscreens enables new approaches to SaaS authentication schemes, including image-based and graphical approaches. Increasingly users are asked to draw a pattern, touch points on a picture or identify a series of secret images to authenticate. When evaluating such approaches, it’s important to make sure the solution generates one-time passwords and is not simply a static pattern or image. User’s fingerprints and smudges on the touchscreen can reveal their secret pattern or touch points if it is a static approach.

One way to generate one-time passwords using an image-based approach is to have the user choose a few secret categories of things – such as dogs, flowers and cars. Each time authentication is needed the user is presented with a series of pictures on the touchscreen and must tap the ones that fit his previously chosen categories. The specific images are different every time and displayed in a different location on the screen every time, but the user will always look for his same categories. As the user clicks or taps on the pictures that fit his categories, a one-time password is generated behind the scenes and submitted to the server for verification.

Graphical authentication approaches are easier for users to remember than complex passwords and they are faster for users to perform on smartphones and tablets than typing an alphanumeric password. For this reason, they are a good method for adding a layer of security or a one-time password without inconveniencing users.

Risk-based authentication

Organizations requiring even stronger security should consider integrating a risk engine with their authentication solutions. Using behavioral and contextual risk profiling, risk engines can dynamically trigger additional layers of authentication only when needed. This increases security without inconveniencing users because users will rarely encounter the additional steps. Risk-based authentication solutions should identify device reputation, and evaluate the geolocation of the user’s IP address and time of day they are accessing the site.

Also examine the frequency of the login attempts, which could indicate a brute force attack. If a high-risk or suspicious situation is identified, require an additional authentication step from the user. The additional authentication step could simply be second layer of authentication, or it could be a second factor of authentication.

Multifactor Authentication

Organizations whose websites or applications could be a high-profile target for hackers should adopt out-of-band, multifactor authentication. Multifactor authentication involves at least two of the following authentication factors:

• Something you know (i.e. a password, secret image categories or other shared secret)
• Something you have (i.e. a mobile phone or authentication token)
• Something you are (i.e. biometrics such as a fingerprint)

Multifactor authentication solutions that rely on the mobile phone as the second factor are increasingly popular. The most common approach involves sending an authentication code to the user’s phone via an SMS text message and having the user type the code into the web page to authenticate. Knowing that banks often use this approach, cybercriminals are increasingly targeting the SMS channel for attack. Using malicious software they are able to compromise a user’s online account, intercept and reroute the authentication text messages to their own phones, then use the code to gain access to the user’s account.

A more secure approach is to adopt a multi-layered, multifactor authentication solution that remains completely out-of-band from the web session on the PC. Organizations can use push technology to send an authentication challenge to users’ smartphones. Users must solve the authentication challenge on their phone and send back their response/approval via push technology, which uses a server-to-server communication channel and is more secure than SMS.

For example, using the image-based authentication approach described earlier, when a user logs into their online bank account on the PC they enter their username and password. Using push technology, the bank sends an image-based authentication challenge to the user’s smartphone. The user must tap the images that fit his secret categories and tap a submit button to send his selection back to the bank for verification. The process remains entirely out-of-band from the web session because there is no data to type into the web page on the PC.

In addition to being out-of-band, the process is multi-layered and multi-factor. The user must have possession of the registered second factor device (their phone) but also apply a shared secret (knowledge of their secret categories) on the phone. Even if someone else had possession of the user’s mobile phone or intercepted the delivery of the out-of-band authentication challenge, they would not be able to complete the process because they would not know which images to identify.

When evaluating multifactor authentication solutions that rely on the user’s mobile phone as the second factor, look for solutions that remain completely out-of-band from the web session on the PC and those that use push technology rather than plain text SMS.

Biometrics and Behavioral Biometrics

Biometrics and behavioral biometrics are also increasingly viable authentication options. Most laptops, smartphones and tablets now come with built-in video cameras that can be used for facial recognition, and fingerprint scanners are quite common in mobile and desktop environments. Smartphone applications can be used for voice recognition. However, drawbacks of biometric authentication include the need to maintain the equipment and ‘body parts’ to get accurate readings; biometric ID data must also be stored in databases and is therefore susceptible to theft and forgery.

Depending upon the type of organization or account being accessed, users may not be willing to provide biometric data for authentication. For example, users may be willing to use a fingerprint scanner to authenticate for their bank account, but not for a social networking or shopping site.

Behavioral biometrics are technologies that tracks the user’s behavioral patterns such as keystroke speed and mouse movements. These and other behavioral profiling techniques can help to successfully identify individual users, especially when used in conjunction with another authentication factor. Behavioral biometrics are usually analyzed behind the scenes, unnoticed by the user, so they do not inconvenience the user, which helps improve the usability of security.

Conclusion

Authentication standards on most websites and applications are woefully lacking. Relying solely on passwords puts the organization, its users and its data at risk. Not every website needs multifactor authentication, but most can benefit from using multiple layers of authentication or one-time passwords. User education is also critical for improving authentication. Unless the user clearly understands the reasons for additional authentication requirements, they will find ways to circumvent the policies.

Finally, it’s important to remember that ‘security’ is a process–organizations must continually re-evaluate security needs, identify areas for improvement and make a security roadmap for future improvements. A website or application can never be completely secure, but developers and security professionals should aim to strengthen security to the point where it will deter most attackers while maintaining ease of use for end-users.

Keep Up to Date

The first and the most basic measure to secure your WordPress installation is to keep it updated to the latest release. This helps patch security vulnerabilities. The process of updating WordPress is easy and fast.

With the release of every new version of WordPress, the security bug fixing information becomes public. The WordPress dashboard is upgraded automatically or a manual upgrade can be achieved by overwriting the old files with newly downloaded files from the website. Obsolete older versions of WordPress do not have access to security patches. You don’t want to miss the advanced features and functionality.

The same is true for plugins. Whenever there is a new version of a plugin available, make sure you update. If you are not using any of the plugins installed, it’s better to remove them from the dashboard.

Customize Your Login

The default username for WordPress installation is always ‘admin’. If you don’t change the username, you are giving hackers a head start – they only have to crack your password to get access to your dashboard. You can use the following steps to make a new username:

1. Login with your admin username first. When you are inside the WordPress dashboard, click on Users > Add New.
2. Type in a new name and give it full administrative access.
3. Log out and then log in with the newly created Administrative account.
4. Make sure that all earlier posts and pages are given authorship to the new account. This is to make sure all your posts and pages don’t get deleted when you delete your Admin account and they are just transferred to another username.
5. Delete the original admin account.

It is recommended to use a different username to make new posts and pages, with Author status. Use your Administrative account when you need to update WordPress and plugins.

The password you set needs to be a complex one, a mix of letters, numerals and symbols. Using a strong password is essential on all entry points to secure your website fully.

Hide the WordPress Version

Outdated versions of WordPress are easier to hack and knowing the version number presents an incentive for hackers. Even if you are using an older version of WordPress for some reason, you don’t have to advertise that fact.

The WordPress version is by default displayed on the blog and is visible to the public eye. There are plugins available which remove the WordPress version from your source code. One such plugin is Sucuri Security, another is Secure WordPress, both available in the WordPress plugins repository. Keep the hackers guessing!

If you prefer to keep the use of plugins to a minimum, you can include a line of code in the functions.php file to prevent the WordPress version from getting displayed:

/* Remove WordPress version number */
function nm_remove_wp_version() {
return '';
}
add_filter('the_generator', 'nm_remove_wp_version');

The above code ensures complete removal of the WordPress version number from everywhere, be it your header file or RSS Feeds.

Restrict File Permissions

File permissions should be restricted to prevent breach of security of your site. The file permissions should be set to the bare minimum.

Setting the CHMOD value to 755 for folders means only the owner has write permissions and others will have read and execute permissions. Setting the CHMOD value to 644 for files means the owners have the read and write permissions and others can only read the files.

Backup

You should keep backups of all important files. Keeping a backup of WordPress data and files can play a crucial role in times of emergency. Backups can put an end to a lot of your troubles and set your mind at peace.

WP-DB Manager is a good option for backing up the whole of a WordPress website. Online backup options are also a good choice. Maintaining regular backup would ensure that your website is restored within the minimum possible time just in case it gets compromised. WordPress Database Backup is another plugin and can be used as a good option. It allows you to save the database to the server or download it on to your computer. You can also email the backup on your chosen email id. You can schedule the backup hourly, daily or weekly.

Restrict Access to Your Plugins

You should definitely restrict or simply deny access to your WordPress plugins directory. A visit to www.your-domain.com/wp-content/plugins/ reveals all the plugins that have been used in the website. These plugins might contain vulnerabilities, which might put the site’s security at risk and attract hackers.

To deny access to the directories, the easiest way is to use a .htaccess file or just upload a blank index.html file to that directory. If the index.php or index.html files are not present in the particular directory, you must also add the following line at the start in your .htaccess file in the root folder:

Options –Indexes

This will prevent the public accessing your files in the directories.

Change Database Table Prefixes

When you first install WordPress using the default values and options, WordPress tables use table prefixes like Wp_. As hackers can exploit this feature, it is recommended to change the default table prefix Wp_ to something else. To change the database table prefixes after install, you can use WP Secure Scan plugin. If you use another plugin named Change DB Prefix plugin, it can rename table prefix to another string.

Change Default Secret Keys

When you first install WordPress, there are four secret keys written in your wp-config.php file. Go here and copy all the six keys and use them to replace the four keys present in wp-config.php file. These are the random keys generated by WordPress and are changed every time you refresh the page. This helps making your passwords more secure and if anybody is logged into WordPress at that time, they will be logged out of the dashboard immediately as the cookies become invalid.

Secure Your Login Page

Your WordPress login page is accessible to the world and you must secure it so that nobody could gain access to the installation. Error messages on login pages can give clues to hackers.

To remove error messages on the login page, add the following line of code in your theme functions.php file:

add_filter('login_errors',create_function('$a', "return null;"));

This will remove the error message displayed above the username and password box.

You can use plugins such as Google Authenticator and Login Dongle for an extra layer of security. Google Authenticator is a great plugin that adds a two-step verification to your WordPress blog, as the name suggests – similar to Google Account security. Enter a password and a code sent your mobile phone.  Login Dongle plugin generates a bookmarklet with a secret question.

Secure Your Device

Make sure your workstation, PC, mobile, tablet or alternate device is fully secure and automatically updated. The antivirus software and the operating systems should also be updated to the latest release. Set secure passwords for all authentication vectors. These passwords should be complex and should also be changed frequently.

The PCs and servers should be equipped with the latest and the best anti-virus software and be secure from all malware threats. This should include periodic cleaning of harmful bugs. Firewalls should be installed at every level: operating system level, router level and even Internet service protocol level. This should ensure that all the PCs and web servers of your work station are secure.

Don’t Share Your Login

Just like any other secured networks or accounts, you should be careful not to share the username or password with anybody you don’t fully trust. Even in the worst case scenario where you have hired a webmaster to manage your website, ensure you do not share your username or password. You can create separate accounts for them with customized permissions.

Secure Your Content

While uploading content to the website, ensure that the content itself is authentic and is downloaded from safe/reliable sources. Even when you are uploading a script, you need to be cautious as there can be malwares intentionally designed to harm your website.

This is not intended to be an exhaustive list of all possible ways of securing your WordPress installation, but it does give you a handy list of WordPress security issues to consider and ways of addressing them, whether by the use of purpose-specific plugins or simple actions you can take.

Feel free to add more methods in the comments below.

Recent research at the University of Scunthorpe in the UK has identified an issue which could compromise the security on which we depend for online shopping and banking. The department for Computer Research and Advanced Protocols has demonstrated IDentity Information Overlay Technology. The technique analyzes your activity rather than data packets to reveal passwords, visited sites and other sensitive personal information.

The project leader, Professor Juppe, explains:

Modern devices have a persistent Internet connection. Even if you’re not actively using a device, it’s fetching messages, checking for software updates or handling other processes which result in a steady stream of data transmission. Binary is converted to electronic signals which flow through the network.

Binary data is usually represented as clean voltage spikes. In reality, the signal is affected by electromagnetic interference which causes imperceptibly small fluctuations named “micropulses”. While they are rarely enough to cause data loss, micropulses pass through wired and wireless communication layers. They can even cause minuscule delays and bursts when translated through a fiber-optic bridge.

The biggest cause of micropulses is the user; the human body acts as a transmitter when using an input device such as a keyboard. In essence, your connected data flow becomes a carrier wave for micropulse information which can be analyzed. It does not matter whether your connection uses HTTP or HTTPS — the actual data can be ignored but your activities are revealed.

The technology is being refined and the rate of successful micropulse analysis increases exponentially each year. The technique works better if you are physically close to the target — such as on the same wifi connection. However, the research team has successfully attempted analysis over hundreds of miles and, as micropulse detection improves, geographical location is unlikely to remain a limiting factor.

Micropulse Protection

Micropulse analysis technology is experimental but the threat is real. Fortunately, there are a number of low-tech solutions which significantly reduce the risk of identity infringement.

1. Use an on-screen keyboard
Touch screen and on-screen keyboards are not completely immune, but micropulse analysis is made far more difficult. Professor Juppe suggests switching between on-screen and real keyboards when entering sensitive information such as passwords.

2. Shield your input devices
Wrap aluminum foil around devices such as keyboards — the shiny side should face inward to reflect the pulses. If you’re using a laptop, use a small piece of foil around the Ethernet cable or, on wifi, regularly move the device to modify micropulses and make them more difficult to analyze.

3. Reduce electromagnetic interference
Device shielding may not be enough since your body conducts micropulse information. The effect can be reduced by wearing gloves and rubber boots while working.

Have any of your accounts been compromised even though you were careful to safeguard passwords? Have you been approached by someone who knew details of your online activities or services? Could micropulses be to blame?

As a Certified Ethical Hacker, I searched for a script which would help me to detect unauthorized file changes. I found a script (probably in the User Contributed Notes at php.net) which I modified to have working very nicely on my “test server” (Windows) as well as on my “production” server (Linux).

The logic is simple: “Build a database of hashed values for vulnerable files (those which hackers will modify to execute code on your server) and compare those values to the actual hashes on a regular basis and report added, changed and deleted files.”

Obviously, the code to traverse a server’s directory structure and provide hash values is far more complex than the statement above. I will go through the code for the production server.

Database Setup

For security, use a separate database for this which does not share access credentials with any other database. Use cPanel to create the new database and the new user with a strong password (I recommend a 16 character password generated by strongpasswordgenerator.com) and an innocuous name like baseline. Then use PHPMyAdmin’s SQL to create two tables:

    CREATE TABLE baseline (
        file_path VARCHAR(200) NOT NULL,
        file_hash CHAR(40) NOT NULL,
        acct VARCHAR(40) NOT NULL
        PRIMARY KEY (file_path)
    );
 
    CREATE TABLE tested (
        tested DATETIME NOT NULL,
        account VARCHAR(40) NOT NULL
        PRIMARY KEY (tested)
    );

The first table, “baseline,” contains a large field for your path/to/filenames, a fixed field for the file_hash (40 characters are required for SHA1) and acct to allow me to monitor accounts or domains separately. Set the file_path as the Primary Key.

The “tested” table will hold the DATETIME of every scan and the account is the same as baseline’s acct field so it will allow you to scan various accounts or domains and keep their data separate.

Initialize the PHP File:

First, DEFINE several constants

• PATH is the physical path to the start of your scan, which is usually the DocumentRoot. Just remember not to use Windows’ backslashes because both Apache and PHP will be looking for forward slashes.
• Database access constants SERVER ('localhost'), USER, PASSWORD and DATABASE.

and several variables

• An array of the file extensions to examine. Because not all files are executable on the server, I only scan .php, .htm, .html and .js files and these need to be specified in an array. Note than an empty array will force ALL files to be scanned (best for security but uses the most server resources).
• Directories to exclude. Iif you have a directory containing malware, shame on you! In any event, if you need to exclude a directory for any reason, you have the opportunity to list them in an array. Don’t omit any directories just because you only stored images or pdf files, though, there because a hacker can put his files in there, too!
• Initialize the variables you’re about to use: The $file array as an empty array(), the $report string as an empty string and the $acct string (use the account/acct name from your database tables) need to be initialized.

Let’s get started!

<?php
//          initialize
$dir = new RecursiveDirectoryIterator(PATH);
$iter = new RecursiveIteratorIterator($dir);
while ($iter->valid())
{
    //          skip unwanted directories
    if (!$iter->isDot() && !in_array($iter->getSubPath(), $skip))
    {
        //          get specific file extensions
        if (!empty($ext))
        {
            //          PHP 5.3.4: if (in_array($iter->getExtension(), $ext))
            if (in_array(pathinfo($iter->key(), PATHINFO_EXTENSION), $ext))
            {
                $files[$iter->key()] = hash_file("sha1", $iter->key());
            }
        } else {
            //          ignore file extensions
            $files[$iter->key()] = hash_file("sha1", $iter->key());
        }
    }
    $iter->next();
}

What we’ve just done is use the RecursiveIteratorIterator() function (a function used to iterate through recursive iterators)  on the directory ($dir) as it iterates through the directory structure. The first thing it does is check whether a directory has been banned from the iteration then branch depending upon whether file extensions had been specified. The result is a two-dimensional matrix of files, ($files), with path/name.ext as the index and corresponding SHA1 hash value.

I’ll note here that the commented echo statements were used on my Windows test server without linking to the SMTP server but you’ll need to uncomment them if you need to verify the correct functionality.

The file count can be provided immediately by the files array:

$report .= "Files has " . count($files) . " records.\r\n";

The output, whether to your test monitor or email, has just been given its first non-empty value: the hashed file count.

Last Hash Scan

The next thing to do is fetch the data/time the last hash scan was accomplished and get the stored path/file and hash set from the database.

$results = mysqli_query($db,"SELECT tested FROM tested WHERE acct = '$acct'
    ORDER BY tested DESC LIMIT 1");
if ($results)
{
    while($result=mysqli_fetch_array($results))
    {
        $tested = $result['tested'];
    }
$report .= "Last tested $tested.\r\n";
}

Compare Hashed Files with Database Records

So far, we’ve only learned the current file count and datetime of the last scan. The value we’re looking for is to identify the changed files, i.e., those added, changed or deleted. Let’s create an array of the differences.

//          identify differences
if (!empty($files))
{
    $result = mysqli_query($db,"SELECT * FROM baseline");
    if (!empty($result))
    {
        foreach ($result as $value)
        {
            $baseline[$value["file_path"]] = $value["file_hash"];
            }
            $diffs = array_diff_assoc($files, $baseline);
            unset($baseline);
        }
    }
 
//          sort differences into Deleted, Altered and Added arrays
if (!empty($files))
{
    $results = mysqli_query($db,"SELECT file_path, file_hash FROM baseline WHERE acct = '$acct'");
    if (!empty($results))
    {
        $baseline = array();      //          from database
        $diffs = array();         //          differences between $files and $baseline
                                  //          $files is current array of file_path => file_hash
        while ($value = mysqli_fetch_array($results))
        {
            if (!array_key_exists($value["file_path"], $files))
            {
                //          Deleted files
                $diffs["Deleted"][$value["file_path"]] = $value["file_path"];
                $baseline[$value["file_path"]] = $value["file_hash"];
            } else {
                    //          Altered files
                    if ($files[$value["file_path"]] <> $value["file_hash"])
                    {
                        $diffs["Altered"][$value["file_path"]] = $value["file_path"];
                        $baseline[$value["file_path"]] = $value["file_path"];
                    } else {
                            //          Unchanged files
                            $baseline[$value["file_path"]] = $value["file_hash"];
                    }
            }
        }
        if (count($baseline) < count($files))
        {
            //          Added files
            $diffs["Added"] = array_diff_assoc($files, $baseline);
        }
        unset($baseline);
    }
}

When completed, the $diffs array will either be empty or it will contain any discrepancies found in the multi-dimensional array sorted by Deleted, Altered and Added along with the path/file and associated hash pairs for each.

Email Results

You will need to add the discrepancies to the report and email.

//          display discrepancies
if (!empty($diffs)) {
$report .= "The following discrepancies were found:\r\n\r\n";
foreach ($diffs as $status => $affected)
{
    if (is_array($affected) && !empty($affected))
    {
        ($test) ? echo "<li>" . $status . "</li>" : $report .= "* $status *\r\n\r\n";
        ($test) ? echo "<ol>" : '';
        foreach($affected as $path => $hash) $report .= " • $path\r\n";
    }
}
} else {
    $report .= "File structure is intact.\r\n";
}
 
$mailed = mail('you@example.com', $acct . ' Integrity Monitor Report',$report);

Update the Database

You’re not finished yet!

//          update database
//          clear old records
mysqli_query($db,"DELETE FROM baseline WHERE acct = '$acct'");
 
//          insert updated records
foreach ($files as $path => $hash)
{
    mysqli_query($db,"INSERT INTO baseline (file_path, file_hash, acct)
        VALUES ('$path','$hash', '$acct')");
}
 
mysqli_query($db,"INSERT INTO tested (tested, acct) VALUES (NOW(), '$acct')");
 
mysqli_close($db);
?>

On the first pass, there will be nothing in the database’s baseline table and ALL files will display as Added so don’t be alarmed.

Now that you have the code, where do you upload it? Don’t even consider placing this code in your webspace (under the DocumentRoot) as that will mean that anyone can access your file and delete the saved information to invalidate your hash scans. For simplicity, put it in the same directory of your account which holds public_html (or similar) directory.

Activate

Now that you have the code, you need to have it activated on a regular basis. That’s where the CRON function of the server excels! Simply use your cPanel to create a new CRON job, set the time in the middle of the night when your server should be nearly idle (you don’t want to interfere with or delay visitors’ activities, which also means you should limit yourself to a single scan per day) and use the following directive:

/usr/local/bin/php -q /home/account/hashscan.php

where /usr/local/bin/php is the location of the server’s PHP executable and /home/account/hashscan.php is the path to your hashscan.php script (or whatever name you gave it).

Wrap-Up

We have created a new database with two tables, one to hold the dates and one to hold the baseline hashes. We have initiated every scan by identifying the file types (by extension) that we need to track and identified the start point (DocumentRoot) for our scan.

We’ve scanned the files avoiding the unwanted directories and compared the hashes against the baseline in the database. Closing the process, we’ve updated the database tables and either displayed (on a test server) or emailed (from the production server) the results. Our CRON job will then activate your hash scan on a regular basis.

This ZIP file contains the above CreateTable.sql, hashscan.php and CRON.txt files.

This is but one part of securing your website, though, as it will only inform you of changes to the types of files you’ve specified. Before you get this far, you must ensure that your files are malware free (maldet scans established by your host can do this but be sure that you keep a clean master copy off-line), ensure that no one but you can upload via FTP (by using VERY strong passwords) and keep “canned apps” up to date (because their patches are closing vulnerabilities found and exploited by hackers and their legions of “script kiddies”).

In summary, BE PARANOID! There may be no-one out to get you but there are those out for “kicks” who are looking for easy prey. Your objective is to avoid that classification.

What’s a CAPTCHA?

CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart.

On the webpage, a CAPTCHA is a security measure designed to keep out robots by asking the user to key in characters displayed in a box.

Yes, that’s the one: where you have to decipher some squiggly words and enter them in a field before you can submit an online form.And often do it three or four times before you’re successful.

For example:

For more information on definitions, see the comprehensive Wikipedia article on CAPTCHAs.

As far as the real world goes, there are some real doozies out there, like the moving CAPTCHA we found recently in an audit (we’re rebuilding the site so it won’t be there long!)

John Foliot found some inexpressibly confusing CAPTCHAs, an article which is worth a read – please note there is a lot of movement in the article (and no it doesn’t fail the flickering accessibility requirements even if it looks like it)!

Why are there so many CAPTCHAs?

Really, the world would be a much easier place without CAPTCHAs. They are confusing and difficult and we are all time-poor. And surely people want us to use their web site / submit their form / sign up to their newsletter?

The reason that there are so many CAPTCHAs is that there is so much spam in the world. They are perceived as an effective way to prevent robots from, for example, posting comment spam on blogs.

Another common use is to prevent robots with more criminal intent from logging into online bank accounts and the like.

The CAPTCHA is, in reality, a reverse Turing test – performed by a machine to make sure the person filling out the form is, well, a person.

This is also why they are often difficult to interpret. If they were easy to read, then machines could read them, and that would defeat the point.

What about accessibility?

Not only are CAPTCHAs difficult for anyone to use, they are notoriously inaccessible to people with some types of disabilities.

In fulfilling their designated brief of keeping out machines, they keep out people using assistive technologies such as screen readers, thereby closing the door on millions of blind people. So, if you’re blind, use a screen reader and want to log into your CAPTCHA-protected bank account, well … bad luck. Isn’t there a law against that? There ought to be.

There is even a specific section in the Web Content Accessibility Guidelines, Version 2.0 about CAPTCHA, in which their inaccessibility is acknowledged, but the WCAG Working Group feel they can’t be too hard-line about it:

CAPTCHAs are a controversial topic in the accessibility community. As is described in the paper Inaccessibility of CAPTCHA, CAPTCHAs intrinsically push the edges of human abilities in an attempt to defeat automated processes. Every type of CAPTCHA will be unsolvable by users with certain disabilities. However, they are widely used, and the Web Content Accessibility Guidelines Working Group believes that if CAPTCHAs were forbidden outright, Web sites would choose not to conform to WCAG rather than abandon CAPTCHA. This would create barriers for a great many more users with disabilities. For this reason the Working Group has chosen to structure the requirement about CAPTCHA in a way that meets the needs of most people with disabilities, yet is also considered adoptable by sites. Requiring two different forms of CAPTCHA on a given site ensures that most people with disabilities will find a form they can use.

Because some users with disabilities will still not be able to access sites that meet the minimum requirements, the Working Group provides recommendations for additional steps. Organizations motivated to conform to WCAG should be aware of the importance of this topic and should go as far beyond the minimum requirements of the guidelines as possible. Additional recommended steps include:

1. Providing more than two modalities of CAPTCHAs
2. Providing access to a human customer service representative who can bypass CAPTCHA
3. Not requiring CAPTCHAs for authorized users”

http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html

The emphasis in the above quote is mine. When they talk about “two different forms of CAPTCHA”, they mean one that requires sight to complete plus one that relies on audio and should therefore be accessible to people with impaired vision. They then acknowledge that still won’t make it accessible to everyone.

In reality, the ones that rely on vision are so difficult to use for fully sighted people, while the audio versions use sounds so distorted that no-one can make them out.

So basically they are inaccessible, but the Working Group decided that if people had to choose between CAPTCHAs and WCAG2 they would choose CAPTCHAs, so they allowed for it anyway.

I believe there are some effective unique and most importantly, accessible, alternatives to CAPTCHA, but I’ll talk about that in a later article.

What about reCAPTCHA – it’s accessible isn’t it?

In a word, no.

I’m always asked about reCAPTCHA, or what about Accessible CAPTCHA? I have tested numerous CAPTCHAs and I have never come across an accessible CAPTCHA. Feel free to prove me wrong.

But I am also yet to find a CAPTCHA that complies to WCAG2 either.

There is a fundamental disconnect in intent that means it is highly unlikely that a universally accessible CAPTCHA, or even a set of different CAPTCHAs will ever be devised.

CAPTCHAs are, by definition, exclusive: they are are there to keep baddies out. Their way of testing “badness” does not allow for the legitimate use of machines. So they will tend to be inaccessible.

To understand how this becomes a negative spiral, you only have to look at the Google Account Sign Up process. In order to make it “accessible”, Google provide an audio version. A group of hackers was able to prove that it could pass the audio test robotically (read more about it in the article Google recaptcha brought to its knees).

Did Google concede the CAPTCHA was a failure and should be replaced by something more accessible? Not a bit of it. Instead, they made the audio more distorted so that a machione couldn’t possibly interpret it correctly – and nor could any human. Seriously. Try the Google CAPTCHA yourself.

One of the hackers pinpointed out the problem:

While the changes stymied the Stiltwalker attack, Adam said his own experience using the new audio tests leaves him unconvinced that they are a true improvement over the old system.

“I could only get about one of three right,” he said. “Their Turing test isn’t all that effective if it thinks I’m a robot.”

Couldn’t have said it better myself.

In my next article, I’ll explore how to replace CAPTCHAs with accessible options, while maintaining security and preventing spam.

Sometimes you encounter a tip which is so simple you can’t believe you didn’t know about it before.

If you’re running WordPress, you’ll have defined a wp-config.php file which contains essential settings such as the MySQL database host, name, user and password. It normally sits in the location where WordPress was installed — in most cases this will be the web server root but it could be any sub-folder.

You certainly don’t want wp-config.php falling into the wrong hands. Under normal circumstances, a naughty cracker cannot view the file because the PHP interpreter would parse it and return an empty page. However:

• The cracker will know exactly where the file is located and can target it more effectively.
• If PHP fails, e.g. perhaps during a update, wp-config.php could be viewed directly in a browser by entering the URL.

Ready for the simple tip…

Move the wp-config.php file into the folder above your WordPress installation.

For example, you may have a folder structure such as /home/mysite/public_html/ where WordPress is installed. In that case, you would move wp-config.php into /home/mysite/.

This has several benefits:

1. Assuming /home/mysite/public_html/ was the web server’s root folder, /home/mysite/ is inaccessible to anyone using a browser.
2. A cracker has less chance of locating the correct file.
3. It’s so simple, there’s little reason not to do it!

Perhaps this won’t be the most exciting tech article you read today, but it’s useful to know. I hope it helps with your security efforts.

Mandy Barrington’s recent article “How to Stop Wasting Time Developing for Internet Explorer” was well-received by SitePoint readers. Mandy’s main point was that developing for legacy versions of Internet Explorer is painful and she offered several pragmatic suggestions such as making notes about IE-specific issues and charging clients who insist on IE6 compatibility.

Understandably, many agreed with Mandy’s article. It justified an opinion held by most web developers: we should forget legacy browsers and concentrate on more interesting technologies. I don’t necessarily disagree with that sentiment, but want to raise a few points you should also consider…

Analytics Won’t Tell You the Whole Story

You should certainly consult your client’s web statistics prior to developing a new site. However, be wary about making business decisions based on that data alone.

If your website didn’t work in the latest version of Chrome, users would either adopt another browser or go elsewhere. In either case, Analytics would reveal comparatively few Chrome users. In other words, the usability of your existing site affects who can visit.

In addition, completely new sites will not have Analytics data. Browser trends can help, but understanding your potential customers is far more important.

Not All Users Can Upgrade

Legacy IE users are bombarded with ‘old browser’ alerts. You can suggest users upgrade their browser but can you succeed where Google has failed?

As a web developer, you’re working with IT every day. Upgrading doesn’t worry you; it’s easy and everyone should do it. But are you neglecting to consider:

1. Large organizations and government departments. Those businesses may have 10-year IT plans. Desktops are locked-down and users can’t upgrade. Even when a company wants to move forward, migrating thousands of users is not quick, simple or inexpensive.
2. Windows XP users. One in four people use XP and that figure is higher for business users. Upgrading beyond IE8 is not an option.
3. You are not an average user. Most people do not understand IT. Many are terrified of it — or certainly worried they’ll break their PC. Migrating from something they know is a risk regardless of the benefits.

Be Careful When Charging Clients More

How would you react to a mechanic refused to service your car because they found it difficult? What if they normally charged $700 but ramped it up to $1,000 for you?

Clients should be charged for more work, but be transparent and explain the issues. It’s rarely as simple as an extra N% for IE6/7 support. After all, supporting legacy IEs with some cosmetic differences is different to making a pixel-perfect site which functions identically across all browsers.

Education is the key. Inform them that IE6 was released more than a decade ago and does not behave in the same way as a browser released last month. It’s possible to support IE6, but providing an identical experience will be difficult, cost significantly more and potentially harm their site with increased bandwidth and lower search engine placement.

Democracy or Dictatorship?

Is it your job to dictate what browser someone should or shouldn’t use? Or is it your job to support whatever browsers people are using? As a professional web developer, shouldn’t you be supporting as many browsers as possible? Do your visitors deserve to see something no matter what?

Despite Microsoft’s advertising, the real beauty of the web is that it’s device agnostic. Sites should work everywhere … with a few caveats:

• Pixel perfection is futile. If you want IE6 and IE10 to look the same, use Flash or PDFs.
• Functionality implementations may differ. For example, IE users may have to upload files via a form. Other browsers may support drag and drop, previews, client-side resizing, etc.
• Making a complex application work everywhere is not always worth the effort. Even if you could get an HTML5 canvas-based game working in IE6, it would sap your budget and run slowly.

But content-only websites and online shops have few excuses.

Looking at the technicalities, IE9 and 10 are unlikely to cause you major problems. IE8 will generally work, although you’ll be missing nicer CSS3 effects. Which leaves us ancient bug-ridden browsers such as IE7 and below.

However, consider how you would react to an article stating that developers shouldn’t support screen readers. Many of these make IE6 look sophisticated and they have far fewer users — but I’d hope there’d be an outcry.

No one’s forcing you to develop for IE6, IE3, Lynx, JAWS or a five-year old Nokia browser but that doesn’t make it impossible. Progressive Enhancement remains a viable technique and rarely requires extra effort if it’s implemented correctly from the start. That said, technology has moved on and developers rarely bother when CSS and JavaScript are ubiquitous.

I expect this article to whip up a storm of “I ain’t supporting IE6 no matter what, buddy” comments. But what if there was a way to support legacy browsers without significant development or testing? It’s time for you to read…
How to Use Responsive Web Design to Support Old Browsers

Will you reconsider your anti-old-browser policy now?…

An article which recently appeared on TechRepublic will strike fear into the heart of all developers and software manufacturers: Should developers be sued for security holes?

The question was posed by University of Cambridge security researcher Dr Richard Clayton. Software security losses cost billions per year and he wants vendors to accept responsibility for damage resulting from avoidable flaws in their applications. He argues that companies should not be able to rely on End-User License Agreements which waive liability.

While no legislation has been passed, committees in the UK and Europe have been considering the requirement for several years. Clayton wants applications to be assessed to consider whether the developer has been negligent. He argues that the threat of court action would provide an incentive to minimize security holes:

If you went down to the corner of your street and started selling hamburgers to passers-by they can sue you [in the case of food poisoning].

It’s not going to be easy. There’s going to be a lot of moaning from everybody inside [the industry] and we’re going to have to do it on a global basis and over many years.

Understandably, the software industry has fought back with several points:

• No one purposely makes insecure software, but the complexity of code can introduce unforeseen errors.
• When a home is burgled, the victim doesn’t usually ask the maker of the door or window to compensate them.
• Legislation would stifle innovation and manufacturers would prevent application interoperability to guard against undesirable results.
• Who would be liable for open source software?

Litigious Lapses

Clayton’s primary concern is security holes, but what does that mean? Bugs. It doesn’t matter whether they are caused by the coder’s inexperience, lack of testing or unforeseen circumstances owing to a combination of factors.

However the legislation is worded, if someone can sue for security issues, they can sue for any bug. Did an application crash before you saved 20 hours of data entry? Did an email or Twitter message reach an unintended recipient? Did Angry Birds cause distress by failing to update your high score?

Burgers vs Browsers

Let’s use Clayton’s burger analogy. Preparing a burger involves sourcing good-quality (OK — acceptable quality) meat and throwing any which is past its best. You won’t have problems if the ingredients are kept cool until required then cooked at a high enough temperature for a long enough time.

I don’t want to berate the fast food industry but there are a dozen variables and you only deal with two or three at a time. Nearly all are common sense — if the meat smells bad or looks green, it won’t be fit for human consumption. A burger costs a couple of dollars but, eat a bad one, and it will kill you.

Let’s compare it to a web browser. Conservatively, a browsing application could have 10,000 variables. There’s no linear path and each variable could be used at a different time in a different way depending on the situation. The browser is running on an operating system which could have one million lines of code and another 100 thousand variables. It could also be interacting with other software and running on a processor with its own instruction sets. It’s complex.

However, a browser is completely free at the point of use. It may be the worst application ever written. You may lose time, money and hair. But no one will die. There are risks, but are they more than outweighed by the commercial benefits?

Terminal Software

It is possible to limit programming flaws. Consider avionic software: a bug which caused a plane to fall out of the sky will lead to death. Failure is unacceptable.

Aircraft software development is rigid, fully documented, optimized for safety, thoroughly tested, reviewed by other teams and governed by legislation. It takes considerable time, effort and focus. Airbus won’t demand a cool new feature mid-way through coding. Boeing won’t rearrange interface controls one week before deployment.

The software is incredibly complex, but it’s one large application running on a closed system. The development cost is astronomical — yet failures still occur. They’re rare, but it’s impossible to test an infinite variety of situations in a finite period.

Assessing Developer Negligence

There’s only one way to learn programming: do it. Learning from your mistakes is a fundamental part of that process. You never stop learning. And you still make mistakes. I cringe when I examine code I wrote last week … applications written ten years ago scare the hell out of me.

While education is a start, it takes time, patience, and real-world problem solving to become a great developer. How could you gain that experience if you weren’t being paid? If you’re being paid, it stands to reason someone is using your software.

Anyone who thinks applications can be flaw-free has never written a program. Even if your code is perfect, the framework you’re using won’t be. Nor is the compiler/interpreter. What about the database, web server, operating system or internal processor instruction set?

But let’s assume lawyers found a way to legally assess developer negligence. Who in their right mind would want to become a programmer? Fewer people would enter the profession and daily rates would increase. Those developers prepared to accept the risk would have to adhere to avionic-like standards and pay hefty insurance premiums. Software costs would rise exponentially and become an expensive luxury for the privileged few.

Clayton’s proposal may be well-meaning but it doesn’t consider the consequences. His suggested legislation would kill the software industry. Ironically, that would solve all security flaws — perhaps that would make him happy?

Several websites including The Register and ZDNet have reported that Firefox 13′s new tab page is taking thumbnail snapshots of visited pages — including those during secure HTTPS sessions:

The problem is not unique to Firefox; Chrome and Safari also generate thumbnails of HTTPS page content but their images are smaller and less readable. Firefox’s larger snapshots can reveal webmail and online banking sessions containing visible account numbers, balances and subject lines — even after you’ve logged out.

Fortunately, the thumbnails are generated by the browser and stored locally. No URLs or data is sent to servers and the images can be removed by clearing the history or clicking the “Hide the new tab page” icon at the top-right of the screen.

While the issue is unlikely to affect those with sole use of a single device, those using shared PCs should be wary. Firefox usually refreshes the new tab page after a browser restart so it’s best to use Private Browsing Mode during your session or the Clear Recent History option immediately after.

Mozilla has acknowledged the behavior and promised to release a patch shortly. But it’s a lesson for us all: if we’re not careful, seemingly innocent and useful software functionality can cause undesirable security side-effects.

CSS3 vendor prefixes and the impending apocalypse has been discussed at length on SitePoint since early 2012:

• The Impending CSS Vendor Prefix Catastrophe
• 7 Solutions to the CSS3 Vendor Prefix Crisis
• Judgment Day Arrives: Opera Implements the CSS3 Webkit Prefix
• Two New Proposals to Solve the CSS3 Vendor Prefix Crisis

The issues are widely misunderstood — which is why we find ourselves in this mess. Hopefully, this article will shatter several vendor prefix crisis myths…

1. The W3C Invents Standards…

It doesn’t matter whether you’re inventing a CSS3 property, a wireless network protocol, an electricity socket or a company HR policy: nothing becomes a standard until it’s been implemented.

There is a widespread mis-belief that the W3C consists of HTML5 overlords who decree rules for everyone to follow. The W3C is not and never has been a web technology innovator. Browser vendors are responsible for inventing new CSS3 properties; these only become a standard when:

1. the property is submitted to the W3C (all vendors have representatives who belong to the organization)
2. it’s generally agreed that it’s a good way forward
3. at least one other vendor implements the same feature.

2. …for Vendors to Follow

If you decided to create a browser from scratch, you’d be advised to follow the W3C specifications. There’s nothing forcing to do that, but the documents define how other browsers work today. There are even documents which describe how browsers should render invalid HTML.

The specifications are a record of what’s been done — NOT what vendors must do. Once you have a working browser, you’re free to add whatever feature you like and submit it to the W3C for consideration.

3. The W3C Approval Process Takes Too Long

It takes as long as it needs.

Vendors are normally eager to seek W3C approval otherwise their efforts have been wasted. We all work on software products and know how frustrating disagreements can be, so consider how difficult it must be for five major competitors to evaluate and approve each others ideas.

However, remember that the final “W3C Recommendation” means a feature has been implemented in two or more browsers to the same level and no one has raised reasonable objections. The property may have been usable several years prior to that point.

4. CSS3 Properties Shouldn’t be Available Until They’re a Standard

Several developers have raised the notion that properties should be disabled or only present in nightly browser releases until they are standardized. Since a property must be implemented before it becomes a standard, how can you wait for the standard before implementing a property?

The point of vendor prefixes is to evaluate feature implementation. If the feature was hidden in some way, it would receive little attention, evaluation would take longer and it wouldn’t become a W3C Recommendation in your lifetime.

You’re can wait for a property to become a standard, but…

• You’ll be missing out on some great features. border-radius has been available in all browsers without prefixes for a while, yet the CSS Backgrounds and Borders Module Level 3 hasn’t reached the final W3C recommendation stage. You better go back to image slicing.
• Once a property becomes a standard, there’s no guarantee it’ll be available everywhere. Most browsers are yet to implement all CSS2.1 features — and they’ve had 13 years to do it.

5. Vendor Prefixes == Beta Software

Their is a widespread belief that vendor prefixes are comparable with beta software. It leads to the conclusion that prefixed properties are not recommended for production use. This is wrong.

Beta software is released for testing purposes to determine whether features work as intended. Vendor prefixes are used to evaluate the implementation of a new feature. The difference is subtle, but it’s important to understand that:

• While a vendor-prefixed property is pre-standard, it has been designed, documented, shared, coded and tested by the time it appears in your browser. There’s no guarantee it’ll remain the same or be implemented by other vendors, but it’s rare for a property to radically change or disappear. The worst case scenario is that the property is only ever available in one browser.
• A vendor prefixed-property has undergone beta testing and the feature itself shouldn’t cause problems. If using a property caused a horrendous browser crash, that would be a software issue — not an issue with the property specification.
• The only reason vendors don’t use the non-prefixed property name is to avoid implementation clashes during the early stages of vendor agreement. That might change if Florian Rivoal’s proposal is accepted.

6. Prefixes Aren’t Necessary

Eradicating prefixes doesn’t solve the vendor prefix crisis. Property differences are rare but they do occur. In those circumstances, a property would become unusable if you couldn’t distinguish between two browser implementations.

There may be better options but prefixes solve a specific problem.

7. JavaScript Doesn’t Have a Prefix Problem

JavaScript, or ECMAScript, is an internationally agreed standard. The language has barely changed since its inception and, although more radical changes are coming, the different JavaScript engines are identical. Even known bugs are replicated.

However, JavaScript isn’t the problem. When developers complain about client-side coding, it’s generally the browser APIs causing grief. Those APIs are called by JavaScript code but they’re pre-defined objects within the browser — they’re not part of the language itself.

Be aware that vendor-prefixed JavaScript APIs such as full-screen are already in-place and more are coming. However, it’s less of an issue since you can detect objects and fork accordingly. That’s not possible in CSS.

8. SASS/SCSS/LESS/Another CSS Tool can Fix Everything

There are several CSS scripting/macro languages which pre-compile rules into valid stylesheets. Most handle prefixes; you define a single standard property and the appropriate vendor prefixes are added automatically. It’s a great solution, but:

• Not everyone can install CSS pre-compilers since you require specific server-side languages or frameworks.
• A CSS pre-compiler is only as good as its last update. Vendor prefixes change whenever a new browser is released — the software must keep pace or it’s useless.
• It’s another syntax to learn; many developers are happy coding raw CSS.
• CSS pre-compilers introduce their own set of problems. Any system which generates code can get it wrong and make debugging far more difficult.

If you’re happy using a CSS toolkit that’s fine. But they’re not for everyone and only hide the vendor prefix problem. They don’t solve it.

9. Webkit Leads the Pack…

Webkit is one of the most active development groups and were first to implement some of the shinier CSS3 effects. But they don’t always lead the way:

• The CSS3 calc() function has only just appeared in Chrome 19 but is available in Firefox has been in IE9 for more than a year without a prefix.
• Webkit’s background gradient implementation was horrendous. The W3C members eventually settled on Mozilla’s cleaner proposal.
• Webkit does not support the background-repeat round and space properties; they’ve been in IE9 and Opera for many months.
• Webkit’s SVG parser has fewer features and is often slower than the other engines.

Other vendors contribute their fair share. Remember that webkit is used in Safari and Chrome; Apple and Google — the the world’s largest IT and web companies — regularly publicize new developments. The primary reason we’re in this mess is because some developers assumed webkit was the only important engine.

10. …so a Single Rendering Engine Would Solve Everything

A single rendering engine would make web developers’ lives much easier. Many have suggested that a some type of legally-enforced browser monopoly is a good idea. If you agree, remember that your wish was granted a decade ago. There was one dominant browser; coding was easy and there was little need to worry about W3C standards. IE6 was the standard. Should we ignore that historical lesson?

A single browser engine kills competition and evolution. The proposal fails to acknowledge several key issues:

• It’s impossible to enforce legally or practically on a global level.
• Browser vendors are competitors. Two developers will disagree about a single feature proposal; would five competing companies work in harmony on one code base? Would Microsoft, Mozilla and Opera throw away a couple of decades work to adopt Webkit?
• Vendors have different requirements and schedules. Assume Apple required a new iPhone-specific property. Would they wait for approval from Google, Microsoft, Mozilla and Opera? Or would they fork the engine and implement it regardless? Before you knew it, we’d have five separate engines again.
• Many have suggested that vendors could still compete on “features”. However, the browser is the engine. Vendors have been actively culling superfluous bloat to create faster, slicker applications. What are all these features vendors would compete on?
• One engine doesn’t mean one version. Even today, Chrome’s quicker release schedule results in it having a more recent edition of webkit than Safari.

Despite having five major applications, development is easier than it’s ever been. The browser market is active, thriving and exciting again. I hope we never lose that.

11. Vendors are to Blame

Do vendors have a duty to developers? Or should their overriding concern be for millions of end users?

There have been instances when vendors have promoted prefixed properties as an HTML5 standard, but they do not purposely make our lives difficult. Prefixes solve more issues than they raise. The only reason we have a crisis now is because a subset of web developers failed to use -webkit, -moz, -ms, -o and non-prefixed CSS3 properties. It’s time to stop the whining and fix the problems in our code.

12. Prefixes Were a Stupid Idea

Vendor prefixes aren’t perfect. They are a solution which prevents two vendors implementing the same property in different ways and rendering it unusable. Perhaps they were a little naive, but it’s easy to spot drawbacks with the benefit of hindsight.

Better solutions will inevitably appear but, until then, we’re stuck with prefixes and its up to us to use them appropriately.

IBM recently announced they had banned employees using cloud-based applications including Dropbox, Apple’s iCloud and Microsoft Skydrive. Even Siri on the iPhone is on the list since spoken queries could be stored and accessed by third parties.

The ban has been implemented following IBM’s policy of allowing employees to use their own devices. Personnel working outside the office could use their own hardware rather than depending on that provided by the company.

The policy did not reduce costs. It created new challenges since the software wasn’t controlled by IBM and many employees were unaware of the potential security risks of file sharing, open wifi and webmail systems. IBM’s primary fear was that confidential commercial information could be lost — especially when many of the popular solutions are operated by their direct competitors.

The Cloud is Inherently Risky

It doesn’t matter what claims are made, web-based applications have always been a security risk (as recently demonstrated by LinkedIn). Few of us know where our data resides, how secure it is, or who can look at it. Even if you did know, your data is still sitting on a publicly accessible network; it’s a target for snoopers.

The only real security is the volume of data stored. If someone managed to access Dropbox’s back-end, it may be difficult to identify files belonging to a specific user. Locating a juicy document within many petabytes of data wouldn’t be easy.

Reading Between the Lines

I’m a little skeptical about IBMs announcement. If you’re really concerned about security, the last thing you do is reveal company policies. IBM claim to have banned Dropbox so you can guarantee a number of confidential documents were sitting on Dropbox’s servers at some point. They’re possibly still there.

In addition, IBM is an IT consultant — with their own cloud solutions offering “security-rich virtual environments”. In other words, you should consider hiring IBM because they understand the cloud and your company’s security concerns. Although it’s not stated directly, IBM has raised doubts about the services run by their competitors.

It’s a clever piece of indirect marketing which I’m helping to spread further!

You Can’t Stop Human Nature

In my opinion, IBM’s cloud-banning policy won’t work. If they expect employees to work outside the office, those people must copy confidential documents from IBM’s systems and put them elsewhere. If cloud applications are banned, employees will simply copy files to laptops or USB drives. Is that more secure?

IBM’s employees used Dropbox and other cloud applications because they were practical. It doesn’t matter what security protocols IBM puts in place; people will find ways circumvent those policies if it makes their working lives easier.

Does your company restrict cloud usage? Have you experienced data loss or security breaches using a web application? Comments welcome…

As of May 26 2012, any website available to European visitors must comply with the EU E-Privacy Directive. New laws came into effect in 2011 which prevent identifying information being stored a user’s computer without their knowledge and consent.

If you’re using cookies or any other technologies for non-essential tracking, you must:

1. Tell users that tracking technologies are used.
2. Explain the reasons for using those technologies.
3. Obtain the user’s consent prior to using that technology and allow them to withdraw permission at any time.

The specific technology is not important. While cookies are an obvious target, the law applies to client-side storage, Flash cookies, image trackers, browser fingerprinting or any technology used to identify an individual.

A user’s consent must involve communication where the individual knowingly indicates their acceptance, e.g. clicking an icon or checkbox. Wherever possible, setting cookies must be delayed until a user has the opportunity to understand what technologies are being used and make an informed choice.

The only exceptions are sites where tracking is strictly necessary for the provision of a service or communication requested by the user. Shopping baskets, some online applications and client-side caching to improve page speed would not require authorization. Sites using analytics, advertising or customized greetings must comply.

The website setting a cookie is primarily responsible for compliance. However, in the case of third-party cookies, both parties have a responsibility to ensure users are informed about cookies and consent is obtained.

The law applies to European companies even if their website is hosted overseas. Organizations outside Europe with websites designed for the European market should consider that those users will expect information and choices about cookies to be provided (although legal enforcement is unlikely).

In essence, if you’re using Google Analytics without the user’s consent, your website is operating illegally in Europe.

How Can You Comply?

The UK’s Information Commissioner’s Office (ICO) admits the new rules require considerable work and makes the following recommendations:

1. Audit your site’s tracking technologies and usage. Take the opportunity to remove unnecessary cookies.
2. Assess how intrusive that tracking is, i.e. is it an essential application session cookie or a one that has privacy implications.
3. Decide on what solution is best to obtain the user’s consent.

British Telecom has one of the better examples. On accessing BT.com for the first time, the user is presented with a pop-up message:

The cookie option panel can be accessed from links in the pop-up or page footer:

Whether BT’s implementation abides with the law is another matter. The pop-up disappears after 12 seconds which won’t be enough for some users. In addition, full cookie approval is assumed if you don’t click the pop-up or footer link. The law clearly states that a user must knowingly indicate their acceptance; you cannot presume they understand or agree to your terms by their inaction.

The ICO’s Guidance on the rules on use of cookies and similar technologies offers pragmatic help. It’s a long read, but well-written in clear English.

The Penalties

In the UK, a fine of up to £500,000 can be levied against companies deemed to be operating illegally.

However, the ICO will initially issue information and enforcement notices. This is understandable when you consider that few Government websites have implemented cookie-acceptance systems! Formal action will only be considered when an organization refuses to take steps to comply or is actively using privacy-intrusive technologies.

The Practicalities

Laws can only succeed if they’re clear and enforceable.

The current EU directive is intentionally vague because it’s almost impossible to legislate computer code and functionality which can be developed in an infinite number of ways. The onus is on organizations to determine whether they are breaking the law and take steps to rectify the situation. Unfortunately:

• Few website owners understand the issues or know whether they comply.
• Web developers won’t necessarily know when and where cookies are used in a complex system.
• Assessing the legality of individual cookies will be impossible until precedents are set.
• The legislation has arrived very late and it’s impossible to police millions of websites.

There will not be crack Government teams dedicated to hunting illegal websites; the ICO and equivalent bodies throughout Europe will respond to individual complaints.

But who will complain? An independent survey commissioned for the UK Government concluded that only 13% of users stated they fully understood cookies. 41% were unaware of different types of local storage and 37% admitted they had no idea how to manage cookies within a browser. Even when you know a cookie has been used, it’s impossible to determine whether it’s breaking privacy laws without accessing the back-end source code.

The ICO accepts the legislation will be difficult to enforce, but will act against any company flouting the spirit of the law.

Open Season for Scammers

While this law is aimed at protecting users, it’s scammers who gain the biggest benefit. If you’ve not been contacted yet, expect to see emails such as this appear in your inbox:

Your website contravenes The European E-Privacy Directive 2009/136/EC. The legislation was passed in all European countries on May 25 2011 and your website fails to comply.

You must act immediately. To avoid a monetary penalty notice of up to £500,000, please forward payment of £10,000 to Korupt & Vyle, Internet Solicitors, so we can advise further. If we do not receive payment within seven days, your company will be reported to the UK Government Information Commissioner’s Office and all EU regulatory bodies.

Is this blackmail? Or is the scammer exercising their right to sell you compliance services before reporting you to the authorities for illegal activities? Put it this way, if you send enough emails, you’ll eventually find someone with enough naivety and cash.

What Should You Do?

If you’re using cookies or other tracking technologies for dubious purposes, you already know it and probably aren’t concerned about EU or any other laws. For everyone else, I suggest a simple approach:

1. Ensure you have a privacy policy link in the footer of every page. You might want to change this to “Privacy Policy & Cookie Usage”.
2. Explain your use of cookies and, where necessary, link to the privacy policies of third-party systems such as Google Analytics (google.com/analytics/learn/privacy.html).
3. Rather than devise a complex opt-in system, link to cookie resource sites such as aboutcookies.org which explain how to block, control and delete cookies.
4. Do not respond to unsolicited emails offering cookie legislation help.
5. If you are contacted by a genuine regulatory body, work with them to identify any privacy breaches and devise solutions. They will not charge for that service.

While the EU cookie directive may be dumb and unenforceable, it’s still a law. Unfortunately, common sense is not a legal defense.

We’ve all been there. Your wonderful website has been running successfully for months then — BAM — it disappears. Or, more often, certain features stop functioning. Despite your protests that nothing has changed, your client isn’t happy. Prepare yourself for a few frustrating hours of problem probing.

Step 1: Identify the Issue

This might sound obvious, but I’ve known many developers open their IDE and start hacking at random code. It’s more important to determine the issue than the cause at this stage. Is the site unavailable? Is a particular page or function failing? Is it limited to specific browsers?

Step 2: Test Resource Availability

Nine times out of ten, the problem will be caused by a connectivity issue at your end or the client’s. If you can’t access any other pages, it’s not surprising that your website has disappeared. That said, it’s not always obvious; certain IP ranges, countries or sections of the internet can become temporarily blocked.

Test your site from a variety of locations — a public proxy server will help identify whether it’s a local or global problem. If possible, examine the status of other sites running from the same server or web host.

One less obvious problem is disk space. If you’re running a busy site, server logs can rapidly use the available space even when your application’s storage requirements are low.

Remember that you might be using resources on other servers. This includes CDN-hosted files, database servers, or remotely-hosted APIs such as those for Google Maps, YouTube, Twitter, advertising services etc.

You should also check your server loads. A major traffic spike or Denial of Service attack will cause access problems.

Finally, is your domain registration valid and is the DNS server responding as it should?

Step 3: Identify What Changed

Once you’ve rejected connectivity, traffic, DNS and disk space, it’s time to determine what changed. 999 times out of 1,000 the problem will have been caused by an update.

You may not have touched the files but are you sure others haven’t? Check with everyone who has access but don’t necessarily believe them. Here’s a typical conversation you’ll encounter…

Client: My sites not working. What are you going to do about it?
You: I’ll fix it. Have you made any changes recently?
Client: No. It was like that when I got here.
…five hour’s frantic investigation…
You: You changed X, didn’t you?
Client: X? Oh yes, I changed X. I did that when I was fiddling with Y and Z.

Your application may not be directly to blame. Has your web host updated the OS, language runtime, database software or file permissions? While vendors attempt to ensure PHP, Ruby, Python, MySQL, PostgreSQL, etc. remain backward compatible, features will almost certainly change or break between editions.

Step 4: Reject the Edge Cases

Although rare, you should look for signs of cracking. Software such as WordPress, Joomla and OScommerce are obvious targets, however, changes are often subtle because the cracker wants to retain access. For example, you might discover that a file explorer add-on has been installed or phishing pages have appeared deep within the file structure.

Finally, you should never rule out hardware problems. Corrupt memory chips or disk sectors could be responsible for any number of bizarre issues. If possible, evaluate your application on a similar set-up or install a separate test version on the same server.

Step 5: Fix Your App

Once you have eliminated the impossible, whatever remains, however improbable, must be the truth. Perhaps your code isn’t as perfect as you thought…

Do you have any tips for diagnosing website or application problems? What was the most difficult issue you encountered?

Rumors of a Google cloud-based file storage service have been circulating since 2006 but Google Drive was finally released on April 24, 2012. That’s an unusually long gestation period for a company that normally releases first then tweaks (or abandons) later.

Google Drive is a direct competitor to established players such as Dropbox, SugarSync, Box, Cubby, Microsoft SkyDrive and Apple iCloud. But is it better?

Google Drive Features

It’s important to realize that Google Drive is a replacement for Google Docs (GDocs). Once you sign-up with your Google account, the docs.google.com URL will redirect to drive.google.com. The web interface is fundamentally the same and you can add, create, edit and delete files and folders as before.

Replacing GDocs is a clever idea. The projects are compatible and your cloud-based documents can be browsed from your desktop — an attractive feature for those migrating from Microsoft Office. It’s also apparent Google has learned lessons from doomed projects such as Wave; it’s easier to piggy-back on the success of an existing project than build a new user base from scratch. GDoc’s 40 million users have little reason not to adopt Google Drive.

To make the most of Google Drive, you need to install the desktop application on your PCs, tablets and smart phones. Native applications are currently available for Windows, Mac, Android and iOS but you can be certain that other platforms including Linux and Blackberry will appear shortly.

The desktop application creates a folder on your device. Its files and sub-folders are automatically synchronized to the web and your other devices. Google offer a generous 5GB of free space with competitive plans including 100GB for $60 per year.

How Does it Compare?

Following sign-up, you’ll need to wait for around 24 hours before your existing Docs account is converted. I suspect Google will convert all accounts at some point in the future.

The desktop application is simple to install — assuming it doesn’t throw fatal errors. Many Windows users have reported similar experiences to me although installing Microsoft’s Visual C++ 2008 SP1 Redistributable rectified my issues. Once installed, there’s a little configuration to set the Google Drive folder and the application will run in the background so you can forget about it. On my system, it required a little over 30MB memory to execute — not horrendous, but Dropbox uses less than half that.

If you’ve used similar services you’ll understand how Google Drive works. The main difference is that you’ll find Google Docs files in your synchronized folder. Resources such as PDFs are downloaded as-is so you can open them directly.

Native Google documents are simply URL links which open the file in a browser. While that’s practical, it means you can’t open files offline and you don’t have a real backup in the event of connectivity or service problems. I’m not convinced it’s a major drawback but an option for automatic conversion to desktop formats such as TXT, RTF, DOC, ODT, XLS and PDF would be a bonus.

Finally, there’s the issue of trust. From an ownership perspective, the terms and conditions are clear:

You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours.

Privacy is another matter…

When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones. This license continues even if you stop using our Services.

Could Google take a sneaky peek at your files to provide context-sensitive advertising? Put it this way, I suggest caution if you’re planning to upload documents containing personal information. But the same can be said for every online service since the dawn of the web.

Google Docs Summary

In essence, there’s little to distinguish Google Drive from its competitors. Google has copied the best features from Dropbox and, while that’s no bad thing, it doesn’t offer a compelling reason to switch. Yet.

More competition is great for users, though. Google may drive down storage prices and you can install different services concurrently to obtain many gigabytes of free backup space.

Pros:

• The service works.
• Generous 5GB of free space and inexpensive storage plans.
• Automatic Google Docs synchronization.
• Google will evolve the product rapidly.

Cons:

• Currently limited to Windows, Mac, iOS and Android platforms.
• Some rough edges; application installation problems and less-efficient memory use.
• Google document synchronization is a little kludgey.
• Fewer features, no API and less capable than competing products.
• Potential trust issues.

Have you installed Google Drive? Do you prefer it to competing services? Should Dropbox be concerned? Do you trust Google keep their eyes off your data?