Security Blog

We have been alerted by JANET CSIRT (who are the security people at what is effectively our ISP) that a number of incidents have occurred over the last few weeks indicating that people at academic institutions have been sharing or encouraging the sharing of Eduroam credentials (i.e. wireless).

However convenient it may be to share your account password to temporarily allow someone onto the wireless network, it is not permitted and a very poor idea. Your username and password authenticates you to the Eduroam networks, but is also used to restrict access to your email, your files, and all the information you have access to via the University network. Sharing your personal account password with anyone is not permitted by the University password policy and could expose you to disciplinary action.

In addition, if you share your password you effectively become responsible for the activities of those you share the password with … and indeed with anyone they in turn share it with. This can have significant and drastic consequences; including ongoing consequences that persist long after the password has been changed (as a number of people at the University have found to their cost when their account password was compromised). Indeed, if illegal activities are carried out with your account credentials, the police will come knocking at your door.

Even if you manage to convince the police that you were not responsible, it does not stop the disruption of having a police raid on your home at 05:00 in the morning!

JANET’s notice regarding this can be read at: https://community.ja.net/blogs/eduroam/document/advice-regarding-keeping-eduroam-credentials-secure

Please, please, please do not share passwords.

In the latest in a long line of compromised password databases, we hear that the University of New South Wales has had a password database compromised.

This is interesting for several reasons :-

1. UNSW is an HE-sector institute so the level of embarrassment is very comparable to the level of embarrassment we would suffer if we were to be have the same sort of data stolen.
2. UNSW had a web-based application which accessed data from a database which contained passwords – itself a bad thing and if necessary would be a big flag that the application would have to be approached very carefully to minimise the risk of flaws.
3. The best guess is that these passwords were initial passwords in that they were created as part of the account creation process and the relevant students were expected (if not forced) to use these passwords only once before setting a more reasonable password. Only it is quite probable that the initial passwords were not removed from the database after being issued.
4. The passwords themselves are “interesting” as they are relatively short (7-8 characters is really no longer long enough for a password), and to make an attacker’s life easier are simple pronounceable syllables.

The striking thing about the Naked Security commentary is the clear indication that they do not really understand the account management problems in the HE sector. Which is probably close to the worst case scenario for account management – not many organisations can expect a significant proportion of their account holders to turn up on one particular day and ask for their account passwords. Indeed there are probably more accounts being handed out to students on one day in “September” than there are members of staff!

In such circumstances, there is a great deal of pressure to make things just a little bit easier for the students concerned – handing out account details over the web in advance, making the passwords easier for the students, etc. All very understandable, but each such step makes the security of all the accounts just a little weaker. And using weak passwords for initial passwords encourages the further use of weak passwords – most people are likely to take their initial password as an example of a sensible password. Even if they are told that this initial password is weak and should be made stronger.

Bear in mind that often students (especially foreign students) often rely on being able to connect to the Internet to let their families know that they have arrived safely – and a delay in allowing them access to the Internet because of a password issue is not welcome.

Switching to a model where students create their own accounts – at the very least provide their own passwords (but preferably usernames too) – would seem to be the way forward, providing that the passwords are not stored in plain text form. Of course getting to that destination may require the assignment of scarce resources, and so is likely to impact on other projects.

There is no such thing as a secure server, but it is almost always possible to make a server more secure than it currently is. By following the recommended steps for a more secure server regularly it is possible to run a server that is sufficiently secure to make break ins very much less likely. Most server compromises are carried out by people who want to break into any server with the least amount of effort expended – so the simplest attacks are tried against many servers.

Of course, if you are managing a server that is likely to be specifically targeted – perhaps you have valuable research data that an aggressive foreign government (yes they do break into servers) wants to get hold of, then you have to go a good deal further than the steps in this blog posting.

And if you are involved in with a server and are unsure as to who manages it, then ask. The least secure servers out there are those where two groups each assume the other is managing the server with the result that it doesn’t get managed.

Install Operating System Patches

Operating system patches are fixes for a broken operating system. Sometimes these include security fixes, and sometimes do not, but there is great value in applying them regularly. There is a risk associated with patching servers, but there is also a risk associated with not patching servers. And the total risk is reduced by scheduling the risky activity for a particular time; which can be done with operating system patches, but it is difficult to get an attacker to only attack at specified times!

In many cases, automatic patching is perfectly suitable and should be the default option. Any other patching policy should be documented.

Update “Layered Products”

In some cases, servers can perform all of their required functions with just operating system software installed, but in others it is necessary to install software from other sources. For the want of a better term, these will be referred to as “layered products”, which can include (but are not limited to) :-

1. Added database engines such as Oracle.
2. Stacks of web infrastructure services such as XAMPP.
3. Web applications such as WordPress, Joomla, or Drupal. It includes not only the main service, but also support applications such as PhpMyAdmin.
4. Commercially supported server based applications.

It is important that these are regularly checked for updates, and any updates applied. This can be as simple as a few clicks for something like WordPress, but could involve considerable effort. Ideally updates should be applied as soon as they are released, but that is rarely possible in practice.

However where applying updates is as simple as the updates for WordPress, there is no excuse for not applying updates on at least a weekly basis.

Follow Best Practice Configuration Guidelines

Installing something, and then getting it running is not the end of the job for a professionally run service. It is also necessary to follow best practice in the configuration of the service. These obviously are different for different services, but for servers themselves include :-

1. Disable all unnecessary network services. It may not be insecure now but it could be in the future.
2. Ensure all privileged accounts have strong passwords.
3. Consider installing a firewall to block any network connections except to permitted services.
4. Limit access to administrative interfaces so they cannot be used from outside the University – for example, limit access to PhpMyAdmin to inside the University.

With all the noise about password security going around, there is bound to be some accidental leakage of the phrase “password hashes”. This post is about what they are, and how password cracking works with password hashes.

What Is A Password Hash?

Whenever you set a password in almost any computer system – including all those web sites, the password is “hashed” so nobody can see it. This involves applying a function to the password to generate a string that is supposedly unique (i.e. no other string can generate that second string); this is known as “hashing” for reasons to do with earlier uses for such functions.

This hash is stored and when you try to login, the password you login with is hashed and compared with the stored hash. If the two hashes are identical, then it is assumed that you have provided the correct password.

A hash will look something like :-

$apr1$kIetT94E$d597gZiP9B4UheeMx7JH2.

Different hashes will look slightly different, but to anyone other than someone who spends far too much time staring at password hashes, the differences are not especially noticeable  And irrelevant. Password hashes :-

1. Are the same length for every password – a one character password generates a hash of the same length as a 26-character password.
2. Tell you nothing about the password itself – there is no information contained within the hash that can be used to determine any facts about the original password.
3. Cannot be decrypted. Hashing is a one-way function that eliminates the original password.

So how can attacker find out what your password is ?

How Passwords Can Be Cracked

If an attacker obtains access to a collection of password hashes – perhaps by breaking into a website and sending the relevant file elsewhere – they can attempt to “crack” the passwords.

If the attacker knows what the hash function is, they can generate a sequence of possible passwords and generate the password hash for each one. If they find a match between one of their generated hashes, and the “real” hash, they will know what the original password is.

Generating every single possible password hash sounds like a tough job, and whilst it is a tough job, computers have become sufficiently fast that it is perfectly possible to generate password hashes for every single possible password between 6-9 characters in length depending on the precise hashing algorithm used and what hardware is available to run the cracking job. Using graphics cards to accelerate password hash generation is quite common, and accelerates the work very significantly.

There is another method which involves working through a list of possible passwords based on words generating password hashes. With the right candidate word list, and the right set of rules for “morphing” each word (such as “word” -> “words”, “word” -> “w0rd”, “word” -> “drow”, etc.), it is possible to crack most passwords in a relatively short amount of time. People often assume that a password with a small amount of obfuscation (changing “l” to “1″, “o” to “0″, adding numbers to the end of the word, etc.) will make cracking their password far harder. That is not really so – people who crack passwords know about all the word mangling that people might choose to use (and a great deal more), and go out of their way to include rules to apply modifications to normal words.

“Salting” the Hash

As described so far, it would be possible to pre-compute all the possible password hashes and simply do a comparison against the pre-computed tables to quickly find passwords. In fact it is possible to download “rainbow tables” containing these pre-computed hashes and use those to break passwords stored in very weak password hashes. Of course this problem has been known about for decades, and the solution that was found for the Unix password file of the 1970s has been widely implemented to make rainbow tables less feasible.

The solution is known as “salt” and consists of adding additional information to the original password, so an attacker (for a 12-bit salt) has to generate 4096 different password hashes for each candidate password. Of course modern salts are much longer so the number of hashes to generate for each candidate password is far higher.

Any decent authentication system will “salt the hash” with the intention of making it harder to perform password cracking, but password cracking still works.

This blog entry is one of a number of blog entries on the IS Security Blog on password security. The entire category can be visited at the URL: http://securityblog.port.ac.uk/?cat=9. If you are just looking for advice on choosing an appropriate password, two possible methods follow immediately; if you are wondering “why?”, then please read on as the explanation is at the end.

Method 1: The Passphrase

1. Generate a list of 3 or 4 random memorable words: tree, iron, tee.
2. Capitalise one of the letters in each word (it would be sensible to pick the same letter for each word): treE, iroN, teE
3. Concatenate the words together using a favour punctuation mark to separate the words: treE&iroN&teE

This could also be called the “xkcd” method after a well-publicised cartoon criticising conventional password generation suggestions.

Method 2: The Song or Poem

1. Pick a song or poem.
2. Pick a line from that song/poem: While I nodded, nearly napping, suddenly there came a tapping
3. Take the initial letter of each word: WInnnstcat
4. Apply a selection of heuristics to add complexity :-
   1. Change letters into numbers: W1nnnstcat
   2. Change duplicate letters into a count and a letter: W13nstcat
   3. Change certain letters for punctuation: W13ns!c@!

And that is your password! The only danger here is picking a poem or song with really short lines – “sus” (“sifted, unfallen snow”) is not a suitable password!

There is also a video produced by Sophos with an alternative explanation of the same method :-

http://www.youtube.com/watch?v=VYzguTdOmmU

Why?

Passwords are a somewhat unfortunate solution to the problem of ensuring that an individual using an account is the person authorised to use that account, but they are the best solution we have at present.

Most other solutions are either too expensive to implement, or too unreliable. For instance biometric devices don’t always authenticate, and magnetic card reads attached to keyboards are still somewhat expensive.

And we do need to be aware that people are trying to break into accounts on the network for all sorts of nefarious purposes … ranging from using the account to send bulk emails (spam) with, to emptying bank accounts.

We have recently started encouraging people to use “long and strong” passwords for their accounts, but what does this mean? And how can you generate a “long and strong” password ?

The “strong” part of the phrase is a suggestion to avoid using a password that can be easily guessed which sounds like it would be easy to do. But with automated password guessing, it is possible to make enough password guesses to make it much harder to create a “strong” password. Anything based on a single word such as cloud (including c10ud, clOud, cloud7, duolc, etc.) is weak – most imaginable transformations of a word can be guessed. And don’t imagine that using words in a language other than English helps! Password cracking word lists contain words in many languages including relatively rare languages such as Welsh and Basque!

The “long” part of the phrase refers to the overall length of a password. If “password hashes” somehow escape, an attacker could use a brute-force password cracker to easily break any password less than 7 characters in length – 6 character passwords took 37m on my own home machine several years ago – and an attacker with access to more computing resources could get passwords up to 9 characters in length relatively easily. And the minimum length for a sensible password keeps going up every year.

This post will not tell you how to do email encryption and digital signing with PGP (or GNU PGP), but why and to introduce some of the concepts of PGP. Hopefully without making the mistake that most documents talking about encryption make which is to get stuck into the mathematics. The intention is that this will be the first in a series of articles going through all the details necessary to run PGP. Of course the contents of this post are specific to email and email encryption, and in some places there are little white lies – for example PGP can be used to encrypt pretty much anything including emails. But first …

Why PGP ?

There are two good reasons for using PGP (or “Pretty Good Privacy”) :-

1. It has a perfectly adequate level of encryption tested over many years. As it is widely used by cipherpunks, it can be considered to be reasonably safe … for now.
2. If you find someone who uses encryption in email day to day, it is almost certainly going to be PGP of some kind or another. People who need to communicate with others need to have encryption standards in common, and OpenPGP is pretty much the standard in this area.

PGP has quite a long and interesting history including being classified as a munitions product (thus subject to export controls), commercialisation, and standardisation as an Internet standard. OpenPGP is the standard to which all implementations mustadhere to including the original implementation.

What Does It Do?

It encrypts emails of course! But as a consequence it also implements digital signatures.

The purpose of encrypting email is of course to encode the contents of an email message in such a way as to prevent anyone reading it other than the intended recipient. Email is normally transmitted “in the clear” between the sender and the recipient which means that anyone with access to the mail servers between the two people involved can intercept that message and read the contents. There are various methods of server-side technologies to make email more secure, but ultimately the only way of being sure that your email is safe from interception is to use end-to-end encryption which is what PGP provides.

Digital signatures use the same encryption technology to sign a message to give a high level of confidence that a certain person wrote a particular message and that the message has not been modified in any way.

Public and Private Keys

The key (sorry!) thing about public/private keys in cryptography is that it just works providing that :-

1. You choose a good pass phrase for your private key, and keep it safe.
2. You keep your private key very, very private.

To encrypt an email to someone, you would use the recipient’s public key to perform the encryption; at which point only the recipient’s private key can be used to decrypt the message.

Digital signing works the other way around – you sign a message with your private key and anyone who has your public key can verify that your message was sent (and not modified) by you.

As you can see, anyone who manages to obtain your private key is able to not just intercept and read mail intended for your eyes only, but also to send out email that purports to come from you in a way that nobody can determine it is forged.

Obtaining Public Keys

Before you can send someone encrypted email, you need to obtain their public key. There are basically two methods to get someone’s public key :-

1. Obtain their public key directly from them. Ideally in person to ensure that someone isn’t impersonating them on email … whilst this may seem unlikely, people who worry about encryption do worry about this sort of thing.
2. Alternatively from a public key server which holds the public keys of anyone who has submitted it for public use.

The public key will be a plain text file with rather inscrutable contents :-

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.19 (GNU/Linux)

mQGiBDypfKARBADbpVbuMSGLLZaskm9IGK9wH2jAX4jhk/J7upqt9/iz8wzZR/tk
(Lots of lines removed)
luVqmVGLLv/NxAR76fFRe2Xyxpv5LS+zVkNygVBNS8sveWBxxbeu4aN1N00g20Vt
+r3heAfrmzBT1ABMp5CQ/p6XgFXO+D8zUiVpLpbT8b3Z7j5ZRHt5VME=
=LSDA
-----END PGP PUBLIC KEY BLOCK-----

Of course it isn’t usual to see something like this as it is usual to use applications to deal with keys. But if you encounter a file with contents like this, it is usual to import it into some application dealing with PGP.

Trust

At one level, the amount of trust you may have in any PGP public key should be determined by the method you used to obtain the key. Perhaps in order it would be :-

1. Public key file obtained by visiting someone’s desk and have them copy their public key to your USB stick.
2. Obtained via a well-known key server across the Internet.
3. By downloading their public key from their web server.

It is possible to obtain an extra level of trust – which is also called a web of trust.  This basically works by people signing other public keys to add levels of trust to a public key – they confirm they know that this public key belongs to the person in question.

The more people have signed a public key, the more confidence you have that it is genuine.

… are people who wish to abuse your account(s).

We are constantly bombarded with spam, and whilst the existing defences protect us against most of it some still gets through. And quite a bit of that spam is intended to get us to provide our account details or other personal details to a third party. I have only three spam messages in my spam folder this morning; at least one is a so-called “phishing” attack … designed to make me login to my “NewEgg” account via a link in the email.

There are a number of different tactics used in phishing attacks :-

1. An upgrade in the organisation’s email service which mysteriously requires you to fill in a form with your username and password.
2. A message about some sort of bank activity that requires you to login via a supplied link.
3. You have won a lottery that you never entered.
4. A threat to close an account for the wrong kind of activity. I can’t count the number of times my eBay account has been “closed”.
5. Notification regarding tax issues – a refund (as if!), or tax owing, etc.

Sometimes the phishing emails ask you to ring a number (where you’ll be asked for personal details), but most commonly directs you to a web form asking for details. This can looks surprisingly official complete with logos, appropriate wording, etc.

Once you have provided details, those details may well be used for all sorts of purposes including :-

• Emptying your bank account.
• Applying for credit cards in your name.
• Using your UoP account details to send spam in your name – not always with your email address on, but using your credentials.

For further information on Phishing, there are a number of links :-

• http://www.phishtank.com/what_is_phishing.php
• http://www.microsoft.com/en-gb/security/online-privacy/phishing-symptoms.aspx
• http://www.hmrc.gov.uk/security/examples.htm
• http://oithelp.nd.edu/email-and-calendaring/phishing/phishing-and-the-consequences/

Everyone should be aware that laptops (at the very least) should be setup for full-disk encryption. This is to ensure that any laptops that go missing – stolen or lost – are not causes for potential leakage of restricted data. Or indeed that nobody can steal your invaluable research data – whether it is formally restricted data or not.

If any doubt, then encrypt.

Standard laptops are supplied with a standard build with full-disk encryption enabled, but there are always some who have a need for non-standard builds. Either Linux or OSX users in particular.

As I happen to have both available, I thought I would describe how to go about enabling full-disk encryption and what the experience is like.

The first thing to overcome is the belief that encryption will make a laptop unusable in terms of performance. It is true that encryption slows down performance, but modern laptops are sufficiently fast that unless you are performing benchmarks, you are unlikely to notice the difference.

OSX

This section applies to supported versions of OSX – 10.8 and 10.7; if you are using another version it is time to upgrade as you are not supposed to connect unsupported operating system releases to our network.

The process of enabling encryption :-

1. Can be used to encrypt a disk already in use.
2. Is easy to start.
3. Carries on in the background.

The only “gotcha” is that you need to restart the machine to start the process, so it may be best to start first thing in the morning. It is also worth bearing in mind that it is not safe to leave your laptop behind on the train until the encryption process has finished!

The process is started by starting the “System Preferences” application (which is usually found in the Dock). Once that has started and is showing the usual array of icons, click the padlock button so that you can make changes. You will be asked for your account password, and once activated additional options will be available.

Select “Security & Privacy” which is usually in the top row. Once the screen changes, select the “FileVault” tab. This then gives you the option to encrypt your disk (labelled “Turn On”).

Linux

Unfortunately with Linux (or rather Ubuntu), the only option without going to extremes seems to be to setup encryption during the installation process, although this suggestion looks to be feasible. Both that suggestion, and the default Ubuntu installation process give you the option of encrypting your “home” folder.

Whilst this is certainly better than nothing, it is not total protection. Whilst most of your personal data will be encrypted, some may “leak” into other places – such as the /var/tmp/ directory. To be cautious it is best to rely on pseudo full-disk encryption, which has the bonus that it seems to work better!

If you can re-install Linux (and if you cannot, you may wish to investigate as to why and resolve the issue), then that is the recommended approach. The first step is to download an appropriate CD/USB-stick to install. The default graphical installer does not have the option to create an encrypted install, so you will have to resort to the alternate text-based installer.

Ubuntu encourages you to download the standard installer by making it less obvious that there is an alternate installer. The trick is to go directly to the right download page (here), select the release you want, and finally select the type of installer you want – here you want “alternative”. Despite being text-based, the alternate installer is almost as easy as the main installer, and offers additional options.

The installer is fairly simple to follow, and this is not the place to detail how to install Ubuntu using the alternate installer. A guide is available here, but it may be going a little too far for those who are not “Rationally Paranoid” (which is the name of the site). The key questions to answer with appropriate answers are :-

1. “Encrypt your home directory”: No. As we are going to select an alternative method of encryption, this is unnecessary.
2. In the partitioning section, select “Guided – use entire disk and set up encrypted LVM”. This will erase your entire hard disk including any Windows partitions. If you wish to retain your Windows partitions, then you will need to try partitioning method.

Shortly after configuring the partitioning, you will be asked for the encryption passphrase. This should be written down in a safe location.

If this all sounds a bit technical, it is worth trying out the installation with a virtual machine (such as VirtualBox); which is of course how I wrote this section.

Don’t Forget Your Manager!

Finally if the laptop is a University laptop, you should really let your line manager have a copy of the encryption passphrase so that any information belonging to the University can be obtained from your laptop in case you go missing – hopefully a lottery win disaster!