If you haven’t already subscribed to the WhiteHat Security Blog then you should. They produce a nice amount of articles that are easy to understand, and often provide interesting insights into the security industry. However, with such a wide range of topics, mistakes can be made (or concepts overlooked), and it is one particular error that I wanted to discuss in a bit more detail here.

Founder and CTO of WhiteHat Security, Jeremiah Grossman, wrote an article about how to keep yourself safe online, and whilst 99% of the article is accurate and good advice, there is one section on making passwords hard to guess where I think Grossman has entirely the wrong idea:

Pick passwords that are hard to guess, not found in the dictionary, six characters or more in length, and sprinkle in a number or special character for good measure. Something like: y77Vj6t or JX0r21b

Whilst having a password that is not found in the dictionary is sound advice, I disagree with both the minimum length suggested, and Grossman’s apparent meaning of “hard to guess”. From the examples given, and the suggested requirements for passwords, it seems that Grossman is trying to protect against a scenario where a malicious user performs a dictionary attack against some kind of login form for a specific user account.

This type of attack does not require the attacker to know any prior information about the target’s password, but instead simply tries various common passwords hoping for a match. The problem is, this type of attack is one of the least common, usually because it targets only one account at a time, and can be easily thwarted by a system simply by detecting multiple bad login attempts and locking the user account for a certain period of time.¹

Password Attacks 101

If you really want to get a user’s password (or multiple users’ passwords), your best bet is to either sniff the network, exploit any trust the target user might have in you (or someone you know), compromise the user’s own system with malware that records their keystrokes, or breach the password database and crack the hashes (assuming the target system uses hashes). Out of these four attacks, by far the most common (and most well publicised) is cracking a list of stolen hashes.

The advantage of cracking such a list is that all the actual effort can be done on the attacker’s system, where there are no defences that can stall or thwart the attempt(s). Cracking a hash can be achieved either by employing the same dictionary attack I described above, or by a method known as brute-forcing. Whilst dictionary attacks are not always guaranteed to work, brute-force attacks are. This is because instead of relying on a pre-generated list of passwords, the brute-force attack goes further, actively generating all possible passwords and checking them against the given hash(es).

Since a lot of people are still terrible at choosing secure passwords,² it is probably best to employ both these types of attack; first using a dictionary to weed out the weak choices, and then brute-forcing the rest.

Password Haystacks

So how long would it take on average to crack the passwords suggested by Grossman? Well, according to Steve Gibson‘s search space calculator, around 35.79 seconds on a decent offline cracking machine. Depending on the algorithm being used, that time could be longer or shorter, but the point is, it’s not very long at all. This is where I disagree with Grossman’s meaning of “hard to guess”. For a human, a password like “y77Vj6t” would indeed be hard to guess, but for a computer, it is simple. There are only 7 characters involved, and each character can be 1 of a very small number of characters (62 since we are only using letters and numbers). That means that in a worst case scenario, the attacker has to generate and check 3,579,345,993,194 (roughly 3.5 trillion) possible passwords. That may sound like a lot, but hardware today can do literally billions of operations a second, resulting in the 35 second average.

Of course, not all attackers will have access to such hardware, but all that means is that the time required to crack a hash is a little longer, and as I explained before, time is not a major concern when the hashes are already stolen. To really create a password that is hard to guess (by humans and computers), you need to increase the amount of search space that a brute-forcing algorithm has to use. Steve Gibson uses the analogy of looking for a needle in a haystack: given enough time, you will find the needle, but the bigger the haystack, the less chance you will have of succeeding in your search within a certain time-frame. So it is with brute-force attacks. The more types of characters you use in your password, and the longer it is, the less chance that a brute-force attempt will find it in a reasonable period of time.

 Creating a Strong Password

There are many different opinions on what strong passwords should look like, and there is obviously a lot of disagreement over various different “methods” for creating them. For some the issue is one of security vs. memorability, and there is a general belief that any password that is secure enough not to be brute-forced cannot be remembered easily either. I think this is patently and demonstrably false, and I shall share with you my method of creating extremely strong and easy to remember passwords. Firstly, let me define a new set of requirements that all strong passwords should comply with:

1. At least one of every type of character (lowercase and uppercase letters, numbers, and symbols).
2. At least 12 characters in length.
3. It should not be found in any dictionary.
4. It should be unique. In other words, it should be something that nobody (not even yourself) has used before.
5. It should not be based on nor contain any personal details.

If you think those requirements would result in passwords like “Aj18!d#B6]0W”, then you have been taught to think about passwords in entirely the wrong way. Allow me to correct your thinking, with the following easy to remember and highly secure password:

I’m bathing in 34 fish, crikey!

This password (more accurately, a passphrase) has 1 uppercase letter, 20 lowercase letters, 2 numbers, and 8 symbols (counting spaces as such). It is 31 characters long, and although the individual words of the passphrase are found in dictionaries, the entire password is not. Finally, since it is a nonsense sentence, the chances of someone else having used it in the past are very slim indeed, and it does not contain any personal details. According to Steve Gibson’s search space calculator, a brute-force attempt that makes one hundred trillion guesses per second would take 65.53 trillion trillion trillion centuries to crack this passphrase.

The Science Bit

So this type of passphrase is very strong, and I hold that it is also very memorable, because it relies on the same techniques for improving memorability as mnemonics do. Remembering the 5 musical notes represented by the lines on a treble clef stave (EGBDF) is hard for most people, but almost everyone who has studied music will remember the helpful mnemonic “Every Good Boy Deserves Favour”. Science suggests that mnemonics are effective,³ and further research concluded that we remember humourous sentences better than non-humourous ones.⁴ Thus, in my opinion, a humourous nonsensical sentence is ideal as a secure and memorable passphrase.

I have proposed this before in various discussion groups, and the feedback has more often than not been positive. However, I am of course open to criticisms, and I shall go into more detail about possible objections to this method in a separate article. The real test would be for people to start using these sorts of passphrases in their daily lives and report back their findings. Were they easy to remember? How long did you make them on average? How many did you manage to recall before you started running into trouble? Any feedback will be interesting to hear.

My own prediction is that even hours after you have finished reading this article, you will still be able to remember the passphrase I generated a few paragraphs ago.

Update (30/3/2012): Added a 5th requirement for strong passwords, concerning the inclusion of personal details.

I was reading the BBC News website the other day, and I stumbled on an opinion piece entitled “The internet is broken – we need to start over“. The author, Professor Alan Woodward (Department of Computing, University of Surrey) argues that we need to totally rethink the Internet, because it wasn’t designed with security in mind, and is always going to be prone to vulnerabilities. I respectfully disagree with the professor, and despite him claiming to understand the root of the problems, he seems to have gravely misunderstood the technologies involved.

The Blame Game

Firstly, I am not denying that there are vulnerabilities on the Internet; the examples of exploits that the Prof. Woodward gives in his article (identity fraud and cyber-attacks from hacktivists) are both valid and important. No, my main point of contention is on where Prof. Woodward places the blame for these vulnerabilities: IP. In the article, Prof. Woodward asserts:

We need to understand the root of the problem.

…

Those who designed the Internet Protocol (IP) did not expect that someone might try to intercept or manipulate information sent across it.

Whilst this is true, Prof. Woodward is effectively doing the digital equivalent of “shooting the messenger”. IP is not to blame for identity fraud, and could hardly be blamed for cyber-attacks either. Identity fraud is often committed with the help of phishing websites, which, whilst being transmitted to the victim over IP, are only effective once loaded into a web browser (and interacted with by the victim). Replacing or changing IP will not stop these websites, or reduce their effectiveness.

In regard to cyber-attacks, Denial of Service (DoS) attacks such as ICMP flooding are carried out over IP, but are not reliant on it, and could be easily adapted to almost any other protocol aimed at replacing IP. For instance, a real-world analogy to a typical DoS attack would be to repeatedly phone up a pizza company and order hundreds of pizzas to false addresses, wasting the pizza company’s time and money. Is the answer to scrap the phone system? Hardly. A better solution would be for the pizza company to have more checks in place to reduce the attack vectors that are available.

Secure Protocols Do Not Imply Secure Applications

Prof. Woodward continues his article by mentioning some of the protocols that are built on top of IP and add security to the Internet. However, he misunderstands the relationship between those protocols and the applications that are served across them.

And, yes, many of these technologies included the ability to secure the data that is being transmitted over the internet. All will have used one of these ‘secure’ technologies, most usually when buying something over the internet.

But, stop and ask yourself this, if it is ‘secure’, why are there so many successful attacks?

One of the technologies that I presume he was talking about is TLS/SSL, which is capable of both encrypting data sent across the Internet, and detecting if that data has been altered along the way. In the case of the web, these protocols are in use when you visit a site using HTTPS (i.e. most, if not all banks and online shops). These protocols have been proven secure by rigorous mathematical processes.

So, to answer the professor’s question, there are so many successful attacks because the attacks aren’t on the protocols, but on the application that is transmitted via the protocols. ICMP floods don’t attack the IP protocol; they use the IP protocol as a transport mechanism and attack the server they are sent to, just as one might use the phone system to transmit one’s voice and “attack” a pizza company with fake orders. Cyber-attacks like Cross-Site Scripting (XSS) and SQL Injection rely on vulnerabilities in the web application, and have absolutely nothing to do with IP, TCP, or even HTTP.

Who Builds the House?

Prof. Woodward further argues that users shouldn’t be expected to change their behaviour to “fix” the Internet, since this wouldn’t fix the problem.

It is unreasonable to expect users in general to understand complex technologies to the degree necessary to ensure they operate securely over the internet.

It’s analogous to a house. By default a house should be built to allow it to be occupied safely.

If you chose to start knocking down walls then it is your fault if the house collapses. But if the foundations of any structure are unsound, no matter how strong or unmodified the building on top, there is always a significant risk of safety being undermined through no fault of yours.

I take issue with this analogy. IP isn’t some big static thing that surrounds you and protects you, and it never should be. IP is a simple protocol that lets you send your data over the Internet, and is more analogous to an envelope than a house. We don’t (or at least, shouldn’t) put sensitive data inside envelopes, since we know that envelopes are easily intercepted and opened.

A house, however, is a perfect analogy for an application on the Internet, and in this regard I completely agree with the rest of the professor’s example. My question is, who builds the house? Not the user, but the builder. It isn’t up to the user to secure the applications on the Internet, but it is up to those who create them. If IP really were to blame for the vulnerabilities and attacks on the Internet, then why are only certain companies / applications affected? IP may be responsible for transporting the attacks, but I hold that any replacement protocol would suffer the same fate.

The Internet Lives

The last part of Prof. Woodward’s article focuses on whether governments should regulate all or part of the Internet. That is a separate discussion for another article, and I won’t comment on it here. I think I have shown that the professor is wrong in many aspects of his argument, from his blaming of IP to his confusion of protocols and applications. IP isn’t perfect at security, but it was never designed to be, and never needs to be. We have protocols that can add security where and when it is needed, but we should not rely on them alone. Application developers need to be held accountable for the security vulnerabilities that they let into their code, as it is them, ultimately, who are responsible for security on the Internet.

Fox News and now various other sources are reporting that the leader of LulzSec, known online as Sabu, was captured by the FBI back in June 2011 and helped law enforcement agencies track down the rest of the group.

If true, this is a very interesting turn of events.

Update: An FBI statement seems to confirm that the authorities arrested Sabu (real name Hector Xavier Monsegur) at some point in 2011 and pled guilty to 12 charges against him on 15th August 2011. According to the statement, he faces a maximum of 124 years and six months in prison.

Update #2: Wired have published a good article that covers some of the story, and includes court documents that cover the charges against Sabu [PDF], as well as implicating him as a government informant [PDF]. Both documents state the date of his capture as 7th June 2011, which was only a few weeks after LulzSec first emerged.

I’m not going to hide the fact that I’m a big fan of Google. I have a Gmail account, a YouTube account, and a Google+ profile. I use Google Calendar to plan my life, Google Reader to keep track of news and blogs, and Google Analytics to collect interesting data about visitors to my websites. When I have a burning desire to know something, my first port of call is Google Search. Google makes my online life easier, and since the all-encompassing Google Account appeared several years ago, the hassle of having to login to all these services individually disappeared. How much do I pay overall for these services? Not a penny.

Instead, Google display adverts, and in most cases, the adverts are fine-tuned to what Google think you’d be interested in. They do this by looking at the kinds of things you do with their services, and build-up several profiles of you based on this data. So, if you get a lot of emails about computers, the adverts on Gmail might be more about computers than anything else. On the other hand, if you watch a lot of cat videos on YouTube, you may get more adverts on YouTube depicting cat products (doubtful, but you get the idea).

So what’s changing?

Today, Google launch a new privacy policy which effectively means that the data they collect about you in Gmail is reflected in the adverts they display to you on YouTube, and vice versa. Instead of having several profiles about you, they only have one. A lot of people are angry about this, especially privacy groups, but I think the entire situation is being blown out of proportion. In actuality, Google (Inc.) know no more about you than they already did, since they aren’t collecting anything new. Despite data obtained from your YouTube account being stored in a separate location to data obtained from your Gmail account, both sets of data are on Google servers somewhere. The company has always had access to that data, and now it’ll be able to use it across different services.

In addition, there is no indication that Google have ever used your personal data for anything other than displaying targeted adverts, and there is certainly nothing in their new privacy policy that suggests they plan to start selling your data to the highest bidder. It is often said that there is no such thing as a free lunch, and that holds true in this case too. Google offers its services for free, and it is only able to do that by serving adverts alongside them (and by getting people to click those adverts). The more targeted the advert, the more likely a user will click it, and the more money Google makes. It’s that simple.

Reducing your Digital Footprint

I do share the concerns that most people have of giving away too much information in the first place though. You should always have as much control over your personal data as you can, and it is with this in mind that I present the following useful links:

• Google Dashboard - This really is the control centre of all your Google services. You can manage practically all settings (privacy and otherwise) from here.
• Web History - If you haven’t already done so, clear and disable Google Web History, which records every search you make from the main Google website.
• Ads Preferences - Still don’t like the idea of targeted adverts? Opt out!
• Google Account Settings - Take some time to make sure your Google Account settings are in order. These are (currently) different to your Google+ account settings.
• YouTube Video History - Clear and disable your watched video history on YouTube.
• YouTube Search History - Clear and disable your YouTube search history.

Of course, if you have really strong objections to Google’s new policy, you can always delete your Google Account.

I’ve mentioned the HTTPS Everywhere add-on for Firefox a couple of times on this blog. The add-on, developed by the Electronic Frontier Foundation (EFF), attempts to boost your security whilst browsing by sending as many requests as possible over HTTPS. Yesterday, version 2.0 of the add-on was released, with a new feature that “detects encryption weaknesses and notifies users when they are visiting a website with a security vulnerability”. Using data obtained through EFF’s SSL Observatory project, combined with new research into weak public keys, the add-on can now warn people about potential security problems with their connection to various websites.

Until recently, it was impossible for Google Chrome extensions to intercept an HTTP request, and so a Chrome extension was not developed (although there are alternatives). With the new WebRequest API however, a beta version of HTTPS Everywhere has now been released! Both the updated Firefox add-on and the new Google Chrome extension are available here.