Box 14.1 App Transport Security

Sadly there’s not as much transparency when using a mobile app to connect to the Cloud as when using a browser. As of the release of iOS 9 for Apple devices, Apple has been strongly encouraging app developers to make use of its App Transport Security (ATS) layer, which ensures a minimum level of security (via the use of HTTPS) for all network communication.

However, this effort has been undermined somewhat by advertisers such as Google who are advising developers to disable this feature in order to use their advertising services. Compounding the issue is that there’s ultimately no way for the end-user to know if the app they’re using has ATS enabled or not.

Box 14.2 Passwords

Everyone hates passwords. Either they are too difficult to remember or else too simple to break to be effective. Despite many attempts to try and find a better approach to providing a collection of letters (and sometimes numbers, and sometimes punctuation) to identify yourself, by and large we’re stuck with them. And in a Cloud-enabled world, they are everywhere. Everything from online shopping to checking your calendar probably requires a password (even if you’ve opted to have it stored so you don’t have to keep typing it in). It is, therefore, extremely tempting to simply use the same password for everything, so that whenever you’re asked for a password to something, the response comes easily and automatically.

Sadly, this is perhaps the worst thing you can possibly do, as far as your online security is concerned. Even if you’re very careful never to reveal your password to anyone, even if you never even write it down, and even if it’s 30 characters long with a mixture of letters, numbers, and punctuation, the chances are that eventually one of two things will happen: either you’ll unknowingly provide your password to a site designed to collect passwords from people, or one of the sites you’ve previously entered your password will get compromised, and the database containing yours (and hundreds or thousands of others) will get stolen. Either of these two possibilities typically has the same outcome— some malicious person will then attempt to use the password (likely in combination with a registered email address) to access every worthwhile Internet account you might own, from social media to banking, to that one account which opens the door to every other account—email.

For this reason, it’s essential that you try to have different passwords for every site. This might seem difficult or impractical but is actually remarkably simple if you use software such as 1Password (agilebits.com/onepassword) or KeePass (keepass. info) to track which passwords you use where (and indeed generate random passwords on your behalf if preferred) in a secure database (which itself is unlocked via a single password—but this is the only one you’ll ever need to remember).

Box 14.3 Password Strength

Spend enough time signing up with different web-based services, and you’ll become familiar with the different approaches to passwords they take. Some are content to let you choose any password you want, whilst others will impose certain restrictions (“you must use at least one number”, for example), and sometimes have some really bizarre and self-defeating rules about how your password should be composed (“the password must be exactly 8 characters and not have any two of the same characters”). Almost all of them have some notion of what makes a “strong” password, and many of them will use a “password strength” meter to indicate this to you.

But tellingly, the exact same password will produce a different strength rating on different websites. There’s much debate as to what makes a strong password, precisely because it depends on the method that is used to try and break them. A “dictionary attack”, for example, goes through every word in a dictionary (or combination of words), and as such some sites enforce the inclusion of at least one number in a password precisely to avoid these types of attacks from being viable.

However, it does seem that the vast majority of articles on the subject reach the same conclusion—in general, the longer the password is, the better, as most attacks take longer with longer passwords. Coupled with this, you should try to maximise the “search space” of the password (or maximum number of possibilities attackers must check) by including at least one number, one symbol, and one uppercase letter. Do this, and there’s a good chance your account won’t be compromised even if a hacker breaches the system.

Hashed and Salted Passwords

Just as it’s important to protect your own passwords, the sites you log on to have a measure of responsibility to protect your personal information and your password in particular. User passwords are commonly stored in a database and, ideally, the server hosting the database is secured to prevent access from attackers.

However, as countless high-profile incidents have demonstrated over the past few years, it is virtually impossible to prevent the most dedicated hackers from gaining access to a system on the Internet, and when they do, they’ll likely be headed directly for the database that stores user accounts and passwords. If you take the position that at some point, these data could fall into the wrong hands, then you must take steps to protect these data further. The most common solution is to “hash” passwords that are stored in the database. That is, when a user creates (or modifies) their password, the site doesn’t actually store the password they provide, but an encrypted (“hashed”) version of the password. Thus when the raw password data are viewed, the original password cannot be discerned.

There’s a slight caveat to this which is that in recent years it’s possible to use so-called “rainbow tables” (which list a large number of possible passwords and their equivalent hash based on the most popular hashing algorithms) to look up an original password based on its resulting hash. There’s a solution to this, however, which is for the site to also add a “salt”, or random sequence, of characters to the original password, with the aim of making the overall length of the string to be hashed sufficient to defeat rainbow tables (due to the sheer volume of data required, rainbow tables are limited to decoding hashes of strings up to a particular length). Salts can either be constant (the same string is appended to each password) or can be randomly generated and stored per account (the latter approach is considered safer as it prevents an attacker from attacking multiple accounts simultaneously).

The important part to this is that no-one else, not even the web-site owner, knows what your password is. The password is verified by repeating the operation (salting and hashing the password you provide when attempting to log in) and then comparing the result to the stored value. An exact match happens to mean you entered the correct password, but all the system really cares about is the salted and hashed end result, which, of course, bears no resemblance to the original password.

Time-based, One-time Passwords

A one-time password is a type of password that can be used to log in to a service only once, after which the password is rendered invalid. These are considered more secure than a regular password, because even if they are discovered somehow, for example, through negligence on the user’s part, or by monitoring an unsecured transmission, they cannot be used. They also tend to be randomly generated and thus more resistant to dictionary attacks and other password-cracking methods, and can be considered unique, so if another service that the same person uses gets compromised, it doesn’t affect the site using the one-time password.

However, the challenge with implementing one-time passwords for use with web-based services is distributing them. In order to get the one-time passwords to the user you’ve got to regularly send new ones in a secure way (and guarantee the user has a record of them). Even if you do this in batches of passwords (which is considerably less secure than having one at a time), it’s still difficult from a logistical point of view.

Time-based, one-time passwords (TOTP) are a way to overcome these issues whilst still getting the benefits of one-time passwords. With TOTP, one-time passwords are generated, but they are done so automatically based on an algorithm that uses a secret key (that is generated once and is generally hidden from the user) in combination with the current date and time. With this approach only the secret key needs to be secure, as the date and time (and in many cases the algorithm used to compute the codes) is public knowledge.

Two-factor Authentication

Two-factor authentication provides an additional layer of security to users by making them identify themselves by using something only they would know (as in, a password or personal identification number [PIN]), as well as something only they would have (as in a security key or credit card). Whilst this does not completely guarantee security, it provides a much greater degree of security than just using one form or the other (it’s one thing to steal someone’s credit card, or to guess or find out their PIN, but quite a feat to be able to do both) and in a way that doesn’t inconvenience users too much.

That said, the nature of the web means that the second factor of two-factor authentication tends to be in the form of a hardware key that generates a unique code that can be input into the login screen. By definition, this code must be time based, or else it becomes little better than a second password, rendering the actual hardware part of it worthless. So in reality, the devices will use some form of TOTP. And because hardware keys can be relatively costly to manufacture, and the thought of users carrying round a pocket full of hardware keys wherever they go is a little optimistic, the trend has been to have the codes generated on a mobile device which the user already owns, such as a smartphone.

Some implementations of this have a dedicated app that uses a proprietary algorithm to generate or request the codes, whilst others just have the site send an SMS message to the phone number registered for the user (this is not ideal, as SMS messages are not encrypted and vulnerable to being intercepted by a third-party). Increasingly, though, many implementations use the algorithm described by RFC 6238, which can be used in conjunction with a number of freely available mobile device apps (most notably, Google Authenticator [m.google.com/authenticator]), as this means they need to implement the service only into their own system and not have to spend resources creating corresponding apps for mobile devices.

There are some other caveats to using the RFC 6238 algorithm (which mainly boil down to the dependence of keeping clocks synchronised) that in practice mean there are fallback options to the system which can be considerably less secure (such as single-use backup codes that are not time-sensitive and which may have been saved somewhere in an insecure manner).

Additionally, although two-factor authentication methods will typically use codes generated on (or sent to) a mobile device, the use of TOTP itself does not necessarily qualify as two-factor authentication, unless the mobile device is completely separate from the service being unlocked. For example, if you use a banking app on a mobile phone, and the bank sends a TOTP code to that same phone, it is only one-factor—you just need access to the phone to unlock the account. Still none of this means using such an approach is completely worthless; just that it is not as secure as a purely two-factor one.

Box 14.4 Man-in-the-Middle Attack

Even if a connection is encrypted, that doesn’t guarantee it is secure. A so-called man-in-the-middle attack is one where someone silently acts as a go-between for the end-user and the web service. They intercept messages from the user and relay them to the service and do the same for messages going back from the server to the user. In this way, neither the server nor the end-user knows the messages are being intercepted. In this situation, the data would still be encrypted, however, under the right circumstances, the hacker would have the information to decrypt them.

There are ways to prevent this from happening by sites using the correct encryption protocols. Fortunately, modern browsers will provide feedback as to how secure they are (if there’s a padlock, or a green padlock, the chances are you’re protected).

Box 14.5 Virtual Private Networks

One reliable way to secure Internet communication is to use a virtual private network (VPN). A VPN provides a secure link to another network, typically across the Internet. It is a common way to allow access to a network at an office whilst elsewhere (or as a way to connect separate offices together). Even outside of a corporate environment, however, there are many benefits to using a VPN.

Because all communication via a VPN is secure, the act of using a VPN effectively provides greater security when using one to browse the Internet. Because of this, there are many services (such as privateinternetaccess.com) available that offer a VPN to an Internet proxy, providing a way to securely access the Internet, even when on public WiFi. Such services are relatively cheap, at around $50 per year or so, but they should be weighed on their individual merits, particularly in regards to their policy on privacy and how they might impact your bandwidth (there are numerous “free” VPN services, but for the most part these should be avoided, as there’s a tendency for people running such free services to snoop on their users).

Box 14.6 How to Hack into Someone’s Account

The first thing to bear in mind is that unless you already know someone’s password, simply guessing it on a website’s login screen is not going to get you very far. The vast majority of websites have a multitude of measures in place to ensure you can’t just keep trying password for a particular user’s account. Even for those who have somehow managed to not have any checks in place, the nature of the Internet means it would still be a laborious process, as there’s the inherent delay between submitting a password and then getting a response back, so attempting to burn through thousands of password combinations is going to take a very long time, and (one would hope) draw attention from the website’s owners. So in order to break into someone’s account, you will actually need to know what their password is before you try logging on.

So first you’re going to have to gain access to the system that stores the passwords, and download the list of passwords so you can get at the one you’re after. To do that, you’ll have to find a way in. Commonly this is done by exploiting a known vulnerability, which is feasible if the company running the website doesn’t bother keeping their software up-to-date. One of the most widespread of these is the “Heartbleed” bug, first discovered in 2014, and estimated to have affected 17% of secure web servers at that time. As of September 2015, an estimated 200,000 devices were still vulnerable. Even if that particular exploit doesn’t work, you can make use of an “Exploit Kit” to try and identify known exploits for a particular server.

Once you’ve gained unrestricted access to a server, assuming you can’t now just add yourself as an administrator with full permissions, you can instead download databases which include (amongst other things) usernames and passwords. Maybe at this point you’ll get lucky and discover that all the passwords are stored in plain text (as is the case for the various sites tracked at plaintextoffenders.com), and you can just look up the one you want. Even though this seems implausible, this was certainly the case for UK retail giant Tesco as of 2012—gain unrestricted access to their system and you’d find yourself in possession of the passwords of potentially millions of users (perhaps worst of all, they didn’t acknowledge, at least not publicly, that this was even a cause for concern).

But assuming the site has taken proper precautions and hashed stored passwords, you’ve now got to crack the encryption. At this point you can grab a rainbow table (for example, from http://project-rainbowcrack.com/table.htm) and use that to cross-reference the password from the stored hash. In cases where the hash was also “salted”, the rainbow table approach won’t work. But if you know what the salt is for a given user account (as these are typically randomly generated per user and stored in the database alongside the username), the best chance of success is a brute force attack. According to the GRC Search Space calculator (grc.com/haystack.htm), for a randomly generated, eight-character password containing a mixture of mixed-case letters, numbers, and symbols, this could be done in under 19 hours with regular hardware, or just over a minute with dedicated equipment. Had the password have been just three digits longer, the process would take somewhere between 1 year and 10 months and 1,828 years.