Security for Web Developers (2015)

I Developing a Security Plan

2 Embracing User Needs and Expectations

Security won’t work unless you are able to convince the user to embrace it. Any Draconian device developers contrive to enforce security without the user’s blessing will eventually fail because users are adept at finding ways around security. In situations where security truly is complete enough to thwart all but the hardiest user attempts, the user simply refuses to use the application. Long lists of failed applications attest to the fact that you can’t enforce security without some level of user assistance, so it’s best to ensure the user is on board with whatever decisions you make.

Users have two levels of requirements from an application and security must address both of them. A user needs to have the freedom to perform work-required tasks. When an application fails to meet user needs, it simply fails as an application. User expectations are in addition to needs. A user expects that the application will work on their personal device in addition to company-supplied devices. Depending on the application, ensuring the application and its security work on the broadest range of platforms creates good will, which makes it easier to sell security requirements to the user.

This chapter discusses both needs and expectations as they relate to security. For many developers, the goal of coding is to create an application that works well and meets all the requirements. However, the true goal of coding is to create an environment in which the user can interact with data successfully and securely. The data is the focus of the application, but the user is the means of making data-oriented modifications happen.

Developing a User View of the Application

Users and developers are often at loggerheads about security because they view applications in significantly different ways. Developers see carefully crafted code that does all sorts of interesting things; users see a means to an end. In fact, the user may not really see the application at all. All the user is concerned about is getting a report or other product put together by a certain deadline. For users, the best applications are invisible.

When security gets in the way of making the application invisible, the security becomes a problem that the user wants to circumvent. In short, making both the application and its attendant security as close to invisible as possible is always desirable and the better you achieve this goal, the more the user will like the application.

The problem with developers is that they truly don’t think like users. The cool factor of abstract technology just has too big of a pull for any developer to resist. A development team should include at least one user representative (one who truly is representative of typical users in your organization). In addition, you should include users as part of the testing process. Security that doesn’t work, like any other bug in your application, is easier to fix when you find it early in the development process. When security is cumbersome, burdensome, obvious, or just plain annoying, it’s broken, even if it really does protect application data.

Even though this book doesn’t discuss the DevOps development method, you should consider employing it as part of your application design and development strategy. DevOps (a portmanteau of development and operations) emphasizes communication, collaboration, integration, automation, and cooperation between the stakeholders of any application development process. You can find a lot of DevOps resources at http://devops.com/. A number of people have attempted to describe DevOps, but one of the clearer dissertations appears in the article athttp://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing-anyway/. The article is a little old, but it still provides a great overview of what DevOps is, what problems it solves, and how you can employ it at your own organization.

Security is actually a problem that an entire organization has to solve. If you, as a developer, are the only one trying to create a solution, then the solution will almost certainly fail. The user view of the application is essential for bringing users on board with the security strategy you define for an application. However, you must also include:

• Management: To ensure organizational goals are met.

• Legal: To ensure data protection meets government requirements.

• Human resources: To ensure you aren’t stepping on anyone’s toes.

• Support: To ensure that any required training takes place.

• Every other stakeholder involved in defining business policies that control the management of data.

After all, enforcing the data management rules is what security is all about. It’s not just about ensuring that a hacker can’t somehow find the hidden directory used to store the data. Security is the informed protection of data such that users can make responsible changes, but damaging changes are avoided.

Considering Bring Your Own Device (BYOD) Issues

Users will bring their own devices from home and they’ll use them to access your application—get used to it. Theoretically, you could create methods of detecting which devices are accessing your application, but the fact is that users will find ways around the detection in many cases. Creating applications that work well in a BYOD environment is harder than working with a precise hardware configuration, but you can achieve good results. The main point is to assume users will rely on their own devices and to create application security with this goal in mind. The following sections describe the issues that you face when working with BYOD and provide you with potential solutions to these issues.

Some organizations have actually embraced BYOD as a means to save money, which means that developers in these organizations have no standardized device to use for testing purposes. The organization simply assumes that the user will have a suitable device to use for both work and pleasure. If your organization is part of this trend, then you not only need to deal with BYOD devices as an alternative to company products, you need to deal with BYOD devices as the only option. It pays to know what sorts of devices your users have so that you have some basis on which to decide the kinds of devices to use for application testing and how to set device criteria for using the application.

Understanding Web-based Application Security

The solution that is most likely to make BYOD possible is to create web-based applications for every need. A user could then rely on a smartphone, tablet, notebook, PC, or any other device that has an appropriate browser to access the application. However, web-based applications are also notoriously difficult to secure. Think about the requirements for providing anything other than password security for all of the devices out there. In fact, the password might not even be a password in the true sense of the word—you might find yourself limited to a Personal Identification Number (PIN). The weakest security link for web-based applications in most cases is the mobile device. In order to make mobile devices more secure, you need to consider performing these steps:

1. Involve all the stakeholders for an application (including users, CIO, CISO, human resources, and other people outside the development team) in the decision making process for application features. You need to make this the first step because these individuals will help you create a strategy that focuses on both user and business needs, yet lets you point out the issues surrounding unmet expectations (rather than needs).

2. Develop a mobile security strategy and put it in writing. The problem with creating agreements during meetings and not formalizing those agreements is that people tend to forget what was agreed upon and it becomes an issue later in the process. Once you do have a formalized strategy, make sure everyone is aware of it and has read it. This is especially important for the developers who are creating the application design.

3. Ensure that management understands the need to fund the security measures. Most companies today suffer from a lack of resources when it comes to security. If a development team lacks resources to create secure applications, then the applications will have openings that hackers will exploit. The finances for supporting the development effort must come before the development process begins.

4. Obtain the correct tools for creating secure applications. Your development team requires the proper tools from the outset or it’s not possible to obtain the desired result. In many cases, developers fall short on security goals because they lack the proper tools to implement the security strategy. The tools you commonly require affect these solution areas:

a) User or system authentication

b) Data encryption

c) Mobile device management

d) Common antivirus protection

e) Virtual Private Network (VPN) support (when needed)

f) Data loss prevention

g) Host intrusion prevention

5. Create a partnership with an organization that has strong security expertise (if necessary). In many cases, your organization will lack development staff with the proper skills. Obtaining those skills from another organization that has already successfully deployed a number of web-based applications will save your organization time and effort.

6. Begin the development effort. Only you have created a robust support system for your application should you start the development effort. When you follow these steps, you create an environment where security is part of the web application from the beginning, rather than being bolted on later.

A 2014 IDG Research Services report based on surveys of IT and security professionals describes a number of issues surround mobile device usage. The top concern (voiced by 75 percent of the respondents) is data leakage—something the organization tasks developers with preventing through application constraints. Lost or stolen devices comes in at 71 percent, followed by unsecure network access (56 percent), malware (53 percent), and unsecure Wi-Fi (41 percent).

Considering Native App Issues

The kneejerk reaction to the issues surrounding web-based applications is to use native applications instead. After all developers understand the technology well and it’s possible to make use of operating system security features to ensure applications protect data as original anticipated. However, the days of the native application are becoming numbered. Supporting native applications is becoming harder as code becomes more complex. In addition, providing access to your application from a plethora of platforms means that you gain these important benefits:

• Improved collaboration among workers

• Enhanced customer service

• Access to corporation information from any location

• Increased productivity

Of course, there are many other benefits to supporting multiple platforms, but this list points out the issue of using native applications. If you really want to use native applications to ensure better security, then you need to create a native application for each platform you want to support, which can become quite an undertaking. For most organizations, it simply isn’t worth the time to create the required applications when viewed from the perspective of enhanced security and improved application control.

Using Custom Browsers

In creating your web-based application, you can go the custom browser route. In some cases, that means writing a native application that actually includes browser functionality. The native application would provide additional features because it’s possible to secure it better, yet having the web-based application available to smartphones with access to less sensitive features keeps users happy. Some languages, such as C#, provide relatively functional custom browser capability right out of the box. However, it’s possible to create a custom browser using just about any application language.

It’s a good idea to discuss the use of smartphone kill switches with your organization as part of the application development strategy. A kill switch makes it possible to turn a stolen smartphone into a useless piece of junk. According to a USA Today article (http://www.usatoday.com/story/tech/2015/02/11/kill-switch-theft-down/23237959/) the use of kill switches has dramatically reduced smartphone theft in several major cities. A recent PC World article arms you with the information needed to help management understand how kill switches work (see http://www.pcworld.com/article/2367480/10-things-to-know-about-the-smartphone-kill-switch.html). In many cases, you must install software to make the kill switch available. Using a kill switch may sound drastic, but it’s better than allowing hackers access to sensitive corporate data.

Beside direct security, the custom browser solution also makes indirect security options easier. Even though the control used within an application to create the custom browser likely provides full functionality, the application developer can choose not to implement certain features. For example, you may choose not to allow a user to type URLs or to rely on the history feature to move between pages. The application would still display pages just like any other browser, but the user won’t have the ability to control the session in the same way that a standard browser will allow. Having this additional level of control makes it possible to allow access to more sensitive information because the user will be unable to do some of the things that normally result in virus downloads, information disclosure, or contamination of the application environment.

A custom browser environment also affords the developer an opportunity to rely on programming techniques that might not ordinarily work. Developers experience constant problems making third party libraries, frameworks, APIs, and microservices work properly because not every browser provides the requisite support. For example, in order to determine whether a particular browser actually supports the HTML5 features you want to use, you need to check it using a site such as HTML5test (https://html5test.com/) to obtain a listing of potential problem areas like the one shown in Figure 2-1.

Figure 2-1. Using standard browsers means looking for potential support problems.

The problem with the customer browser solution is that it introduces disparities in user support depending on the device the user chooses to rely upon. When these sorts of disparities exist, the developer normally hears about it. Users will want to access the organization’s most sensitive data on the least secure device available in the most public place. Imagine working on patient records in a Starbucks using a smartphone. The data could end up anywhere and a data breach will almost certainly occur. In some situations, the developer simply needs to work with everyone from managers on down to come up with a reasonable list of data handling precautions, which may mean that using the custom browser solution won’t be popular, but it will tend to enforce prudent data management policies.

Verifying Code Compatibility Issues

The BYOD phenomena means that users will have all sorts of devices to use. Of course, that’s a problem. However, a more significant problem is the fact that users will also have decrepit software on those devices because the older software is simply more comfortable to use. As a result of using this ancient software, your application may appear to have problems, but the issue isn’t the application—it’s a code compatibility problem caused by the really old software. With this in mind, you need to rely on solutions such as HTML5test (introduced in the previous section) to perform checks of a user’s software to ensure it meets the minimum requirements.

Another method around the problem is to discover potential code compatibility issues as you write the application. For example, Figure 2-2 shows the W3Schools.com site that provides HTML 5 documentation (http://www.w3schools.com/tags/). At the bottom of the page, you see a listing of the browsers that support a particular feature and the version required to support it. By tracking this information as you write your application, you can potentially reduce the code compatibility issues. At the very least, you can tell users which version of a piece of software they must have in order to work with your application when using their own device.

Figure 2-2. Verify that the code feature you plan to use actually works with user software.

It’s also important to note that some sites also tell you about compatibility issues in a succinct manner. The W3Schools.com site also provides this feature. Notice that the list of HTML tags shown in Figure 2-3 tell you which tags HTML5 supports, and which it doesn’t. Having this information in hand can save considerable time during the coding process because you don’t waste time trying to figure out why a particular feature doesn’t work as it should on a user system.

Figure 2-3. Finding documentation tells you about version issues in a succinct way is important.

A serious problem that most developers will experience with code compatibility is making HTML5 render properly with older browsers in the first place. Sites such as http://www.w3schools.com/html/html5_browsers.asp provide some answers you can use. For example, it shows how to usehtml5shiv to make Internet Explorer support HTML5 elements. The cdnjs site (https://cdnjs.com/) contains a large assortment of these helpful JavaScript add-ins. You can find them at https://cdnjs.com/libraries. Figure 2-4 shows just a small listing of the available libraries. Unfortunately, you need to find examples for all of these libraries because the site doesn’t provide much in the way of helpful information. The majority of the library documentation appears on GitHub. For example, you can find the html5shiv.js documentation at https://github.com/afarkas/html5shiv.

Figure 2-4. The cdnjs site provides you with a large number of helpful libraries.

You see the abbreviation CDN used all over the place online. A Content Delivery Network is a series of services that provides web content of various sorts. The main purpose of a CDN is to provide high availability and high-speed delivery. It also provides region appropriate content when needed. Consequently, cdnjs is simply a CDN specifically designed to provide access to JavaScript code and make it available to a large number of developers, similar to the way that the Google CDN (https://developers.google.com/speed/libraries/) performs the task.

Handling Nearly Continuous Device Updates

Your application will need to be flexible enough to handle all sorts of odd scenarios. One of the more common scenarios today is dealing with nearly continuous device updates. In this case, a user is perfectly happy using your application on a smartphone one day, but can’t get anything to work the next. Common practice is for support to blame the user, but in many situations the user isn’t at fault. At the bottom of the whole problem is that updates often take place without user permission or knowledge. Unfortunately, an update can introduce these sorts of issues:

• Code compatibility

• Security holes

• Lost settings

• Unbootable device

• Data damage

One of the ways around this issue is to make turning automatic updates off as part of the security policy for an application. Making the updates manually after you have tested the update as part of a rollout process is the best way to ensure that your application will continue to run. Unfortunately, this solution won’t work. Users won’t bring in their devices for testing unless something has already gone wrong. Even if users were willing to part with their devices, you likely won’t have the resources needed to perform the required testing.

An alternative solution is to design applications such that they automatically check for updates during startup. If the version number of a product that the user relies on to work with the application changes, the application can send this information to an administrator as part of a potential solution reminder.

Creating flexible designs is also part of the methodology for handling constant updates. Even though a fancy programming trick to aid in keeping data secure looks like a good idea, it probably isn’t. Keep to best practices development strategies, use standard libraries when possible, and keep security at a reasonable level to help ensure the application continues to work after the mystery update occurs on the user’s device. Otherwise, you may find yourself spending considerable time trying to fix the security issues that’s preventing your application from working during those precious weekend hours.

Devising Password Alternatives

Passwords seem like the straightforward way to identify users. You can change them with relative ease, make them complex enough to reduce the potential for someone else guessing them, and they’re completely portable. However, users see passwords as difficult to use, even harder to remember, and as a painful reminder about the security you have put in place. (Support personnel who have to continually reset forgotten passwords would tend to agree with the users in this particular situation.) Passwords make security obvious and bothersome. Users would rather not have to enter a password to access or to make specific application features available. Unfortunately, you still need some method of determining the user’s identity. The following sections present you with some mature ideas (those you can implement today) that you might find helpful in searching for your perfect solution.

A Word About Near Field Communication (NFC)

One of the more interesting developments in technology has been the use of NFC for all sorts of needs. NFC is an extension of the Radio Frequency Identifier (RFID) technology used mainly in products. You find the passive tags in just about everything you buy. The RFID tag doubles as a security device, but its main purpose is to identify the product. Radio waves from a scanner power the tag and the tag returns the information it contains. NFC is a high frequency subset of RFID that provides some special qualities you may need useful when creating security solutions for your application.

• The same device can act as a sender and tag.

• Device exchange information securely.

• You can reprogram a device as needed.

• The device contains both intelligence and local memory, making it more flexible than RFID.

NFC offers the potential to eliminate passwords. A person could have a chip embedded in a credit card sized ID badge. Tapping the badge on an NFC-enabled device would provide the required login. There are many NFC-enabled devices today, including PCs, tablets, and smartphones, so this solution could work everywhere.

The technology is also immature, so it’s important to weigh your options carefully. Fortunately, the World Wide Web Consortium (W3C) is already working on standards for web development. You can see the working draft at http://www.w3.org/TR/nfc/. A library, API, or microservice that conforms to this standard can provide the resources needed to create robust applications that meet both organization and user needs, while reducing support costs and make the application significantly easier for the user to work with. Best of all, using an NFC solution lets you create a truly secure application.

Working with Passphrases

Passwords are hard to remember. Creating a password such as !jS2Zd5L8 makes it really hard for hackers to guess the password and does improve the chances that your application and its data will remain safe. However, the password is also impossible to anyone to memorize, so users often write it down somewhere. In fact, the user might just keep a file right on the hard drive to make access easy. Of course, hackers know this and look for such files. In short, complex passwords are a great idea from a security perspective, but they show terrible planning from the user’s perspective. It’s possible, however, to get nearly the same level of security using a passphrase that’s actually easy to remember.

A passphrase is a semi-human readable phrase of some sort. You use letters, numbers, and special symbols in combination to make the password complex. For example, you could create a passphrase such as I luv fl0w3rs! as a passphrase. The passphrase contains upper and lower case letters, numbers, and special symbols. It’s resistant to dictionary and other common brute force attacks. It’s probably longer than must users will ever allow for a password. Yet, it’s still easy to remember. A user won’t have to write the passphrase down.

It’s important to choose phrases that the user will remember, but that aren’t associated with the application, the user’s personal life, or the user’s work environment. There isn’t a good reason to let the hacker have advantages when it comes to guessing the password. So, a passphrase such as I Work in R00m 23a. isn’t a particularly good passphrase—it would be too easy to guess.

Simply telling the user to rely on passphrases isn’t going to work. In fact, users will still use passwords such as secret and master because they’ve used them for so long. Users tend to reject anything that makes them work even a little harder. As a consequence, you must still enforce complexity rules as part of your application code so that the user is forced to rely on something better than the usual suspects when it comes to passwords. If a user has to come up with a truly complex password, then the idea of using a passphrase instead becomes a lot more appealing.

Using Biometric Solutions

Biometric solutions rely on some unique characteristic of you as a person to generate a password. The idea behind a biometrics is that a biometric password is unique to a particular person, isn’t easy to steal, the user can’t lose it, and the password is complex enough that hackers can’t guess it (at least not easily). The three most common biometric solutions in use today are:

• Fingerprint:

• Iris:

• Voice print:

All three of these solutions do have limitations and hackers have ways to overcome them, so you might choose another biometric or combine a biometric with some other form of authentication. Vendors have a number of biometric alternatives in progress. The following list describes some of these alternatives:

• Heartbeat: One of the more interesting biometric alternatives is to combine a heartrate monitor with analysis algorithms. In fact, the solution already exists in the form of the Nymi wristband (https://www.nymi.com/). This solution relies on NFC to transmit the user’s password to any NFC-enabled device. The same wristband could log onto a computer, enable an application feature, open a house door, or start a car.

• Full Facial Recognition: In the movie Minority Report, cameras scan people’s faces and present them with ads as they walk down the street. The interesting thing is that the technology already exists in the form of Facebook’s Deepface (https://research.facebook.com/publications/480567225376225/deepface-closing-the-gap-to-human-level-performance-in-face-verification/). Simply by looking at your computer (webcam attached), you could log into the system and have all the required application features in place. In fact, Facebook recently claimed it could perform the scan from either the front or the side (http://money.cnn.com/2014/04/04/technology/innovation/facebook-facial-recognition/), which makes this solution relatively flexible when compared to other biometrics.

Interestingly enough, all those selfies people are taking will make it quite easy for law enforcement and others to build a facial recognition database that will make it impossible for anyone to hide. Just think about the effect of every store camera being able to spot people based solely on their facial characteristics.

• Ear Shape: You hold your smartphone up to your ear, just like you would when making a call. However, instead of hearing someone talk to you, you get logged into an application. The solution already exists in the form of the Ergo Lock Screen App (http://www.descartesbiometrics.com/ergo-app/).

• Typing Technique: Every person has a different way to type. The speed at which you type, the time you hold down the keys, even the pauses between letters, all identify you as a typist. By typing a specific phrase and monitoring how you type it, an application could create a two-factor authentication that’s indistinguishable from just typing the password. However, now a hacker stealing the password still wouldn’t be able to use it. One company who has already implemented such a solution is Corsera in the form of Signature Track (seehttp://blog.coursera.org/post/40080531667/signaturetrack for details).

The promise of biometrics doesn’t quite match the reality of biometrics. You already know from the descriptions that hackers have come up with methods for overcoming biometric passwords. If a user’s password is compromised, you simply give the user a new password. However, if a user’s fingerprint is compromised, it really isn’t feasible to cut their finger off and sew a new finger on.

Why Use Two-factor Authentication?

A problem with most single-factor authentication solutions is that they have a weakness that someone can exploit with relative ease. For example, a hacker could steal either a password or a passphrase using a social engineering attack or even brute force. By using two-factor authentication, it’s possible to reduce the risk of someone overcoming the authentication process. Of course, it could be argued that three-factor or four-factor authentication would be even better, but there is a point at which no one could ever get onto their own account.

There are many types of two-factor authentication. For example, you could supply a user with both a password and a token. You could also combine passwords with biometric solutions. Many banks currently use two-factor authentication and you can optionally use it on sites such as Google, Facebook and Twitter.

The problem with two-factor authentication is the same problem that occurs with single factor authentication—users typically don’t like authentication at all. The feeling is that it should be possible to use the application without doing anything extra at all. Of course, authentication is important and you should use two-factor authentication for critical or sensitive data. However, it’s important to consider the user’s view of which authentication choices will work best. Creating a flexible solution is essential if you want this security solution to succeed.

Relying on Key Cards

Most people see key cards as an older type technology that still sees wide usage. For example, go to a motel and it’s likely the person behind the desk will give you a key card with a specially encoded magnetic strip. The key card replaces the key that you might have received in the past. Organizations also use key cards to meet various needs, including controlling access to areas such as parking lots. A combination of a key card and a PIN often provides access to sensitive areas. Suffice it to say that you have probably used more than one key card at some point in your life.

Key card technology is constantly improving. Some modern key cards don’t look like much of a card at all—they appear as part of a fob or other device that a user can put on a keychain or wear around the neck.

By relying on RFID or NFC technology, it isn’t even necessary for the user to slide the device, simply waving it in front of the lock works. The idea behind a key card hasn’t changed though. You have a physical device that contains security information that the user relies upon for access to resources instead of using a password.

PCs can also come with key card technology. You can use the key card to control access to the PC as a whole, or to control access to a specific application. When used for a specific application, the developer needs to provide code to read the card, determine its validity, and authenticate its user.

The main advantage of using a key card is that it can provide a complex password and potentially other details to help identify the user. The password can be as complex as is needed to thwart hackers. Depending on the technology used, you may even be able to change the key card information with relative ease, so a password change need not be a costly thing to do. Key cards also tend to be large enough that users won’t routinely lose them (although you can count on users misplacing at least some of the key cards). Because the technology has been around so long, key cards can also be relatively low cost when compared to other security solutions. Users also tend to like key cards (except when lost) because they’re fast and easy to use.

The main disadvantage of key card technology is that users do misplace them or leave them at home. A lost key card could provide a hacker with the sort of access needed to do real harm to your organization. Even if the user simply forgets the key card at home, providing a temporary key card is an additional support cost. Of course, there is also the matter of actually getting the temporary key card back when the user no longer needs it.

An interesting place to look at various key card technologies is Secura Key (http://www.securakey.com/). This site shows you many of the key card options you have available. You can even find keyboards, such as the IOGEAR model athttp://www.iogear.com/product/GKBSR201/ that provide the required key card reader as part of the keyboard. The point is to reduce the user interaction required to use your application in order to reduce potential user error and data leakage.

Relying on USB Keys

A USB key is essential a flash drive that contains one or more passwords or tokens. You plug the USB key into your computer, start it up, and the computer uses the data on the USB key to log you into the system. The same key could contain passwords used to access applications. The application would need to be aware that the password is on the key, but the technique makes it possible to log into the application without actually providing a password or any other information. Google is currently working on a USB key setup (seehttp://www.technologyreview.com/view/510106/googles-alternative-to-the-password/) and you can be sure other vendors will follow. USB keys have some significant advantages over key cards:

• It’s possible to change the passwords without obtaining a new USB key.

• The USB key can hold multiple passwords.

• The overall cost of USB keys is lower than using key cards.

• It’s possible to upgrade the sorts of credentials that a USB key provides.

Of course, the USB key shares many of the same failings as the key card as well. For example, whether a user loses a key card of a USB key, the result is the same—the user can no longer log into the application and someone else could. In fact, given that USB keys are small than key cards, it’s far more likely that a user will lose the USB key and compromise more than one password as a result.

Implementing a Token Strategy

You generally implement a token strategy using smartphones. A special site sends the user an SMS message, image, or sound that acts as the means to log into a computer. For example, Illiri (http://www.illiri.com/) sends a sound to the users smartphone that the user simply plays to the computer in order to log in. Likewise, Clef (https://getclef.com/) performs the same task using an image. In both cases, you can choose to send a different token every time the user logs into the system, which means that even if a hacker steals the token, it’s essentially useless.

In most cases, an application uses a token as a second authentication method in a two-factor authentication system. The first authentication method is still a key card, biometric source, password, or passphrase. However, it’s theoretically possible to use a token as a primary authentication method should you wish to do so. As with any other method of authentication, this one comes with a number of issues you need to solve:

• The user would need to have a smartphone with them at all times.

• Losing a smartphone could potentially compromise the token system as a means for logging into an application.

• This setup only works to log into devices other than the smartphone and many users today really do want to use their smartphone in place of a computing device whenever possible.

• The computer used to log the user in would need to have the requisite device for accepting the token.

Focusing On User Expectations

Up until this point of the chapter, you have focused on user needs. No user wants authentication, but every user needs authentication. Expectations fall into the nice to have category when it comes to development, but implementing them can create good will, which makes the user a little more open to actually using all those need to have items you added to the application.

Of course, some users have unrealistic expectations, such as an application that makes them look especially appealing to someone else or does all their work for them while they play solitaire and watch movies all day. Unfortunately, even the best developer in the world could never address expectations of that sort. The following sections describe some reasonable user expectations.

Making the Application Easy to Use

The chapter has made a point of emphasizing the need for ease-of-use. Users don’t want to know the details about the security solution you implement. In fact, most users really don’t want to know anything about the application other than it can provide the data needed to accomplish a task that matters to the user. In the long run, anything you can do to make security invisible to the end user increases the chances that the user will actually participate in the secure management of data and that the strategy will succeed in keeping data safe.

The counterpoint to the need for ease-of-use is creating a security scenario that works as advertised. Just one data breach can ruin a company’s reputation and cost your organization buckets of money. According to a recent ComputerWorld article, a data breach now costs $154.00 on average per record (see the article details at http://www.computerworld.com/article/2926775/security0/data-breach-costs-now-average-154-per-record.html). The cost for each record lost will continue to increase, so the need for solutions that are safe continues to increase. The user expectation is ease-of-use, but the application reality is the need to keep data secure no matter what it takes to do so.

Making the Application Fast

Many developers don’t understand the user’s need for speed at all costs. Of course, part of the problem is that the user’s attention span has decreased over the years. According to an article on The Guardian (http://www.theguardian.com/media-network/media-network-blog/2012/mar/19/attention-span-internet-consumer), you have between one and five seconds to grab the user’s attention. Users want instant gratification and quick fixes. Deep thinking and in depth analysis are no longer part of the user’s repertoire. Unfortunately, the more security you add to an application, typically, the slower it becomes. If you were to ask most users how much time they want to spend on security, the answer would be zero. User’s truly don’t care about security—they want data fast.

The user expectation then is that there won’t be any sort of wait for the data needed to perform a task. In addition, the data needs to be accurate and in a form the user needs at the outset. Anything less tends to breed frustration. The reality is that security will slow the application, but that you, as a developer, will need to concentrate on keeping delays to a minimum.

In addition, a secure environment means that not all data will be available all the time. You really can’t permit a user to look at patient records while sitting at the local Starbucks sipping a latte. It’s an unreasonable expectation on the part of the user to have this level of access (not that it will keep users from asking for it). So, a fast application is one that authenticates the user quickly and then presents the user with legal choices for data access. Hiding illegal options will often keep the user from looking for them in the first place, but you also need to provide help that specifies why certain data manipulation options are missing.

Creating a Reliable Environment

Above any other consideration, you must make the application reliable. The application can’t behave in an unpredictable manner because the user will become frustrated and not use it. Even if the application is the tiniest bit slow, a user will complain less about speed than an application that truly is fast, but performs tasks incorrectly. It’s also essential that the security and the data manipulation features work flawlessly. Chapter 5 discusses the various techniques you use to create a reliable application. Part III of this book is all about various kinds of testing. You need to take testing seriously to create a reliable application that generates few user complaints.

The user expectation in this case is that the application performs flawlessly in every situation. Again, it’s a matter of making the application transparent so that all the user has to focus on is getting a task completed. In the real world, you can come close to flawless with proper coding techniques, testing techniques, threat analysis, and constant checks on issues such as device updates. So, in this one particular case, a user expectation comes quite close to being something you can provide in reality.

Keeping Security in Perspective

If you take nothing else away from this chapter, it’s the fact that security is a balancing act. Unless you keep security in perspective, your application may not protect data enough or encumber the user to the breaking point by implementing Draconian features that don’t really serve a useful purpose. Users are quick to spot functionality that they not only dislike, but apparently doesn’t serve a useful purpose.

Even though it might appear that the user expectation is that applications don’t need security, most users realize that security does have a place, especially if the user wants to keep the organization healthy. It’s not really a matter of selling a user on the need for security, it’s more a matter of selling the user on a specific level of security. When you keep security in perspective, it’s a lot easier to close the deal and have the user on your side.