Web Passwords

Passwords can be a pain. There are thousands of websites across the Internet that require passwords. Traditional advice has been to use different passwords for different applications. This is plainly impossible. A typical user of the Internet probably has passwords for their MSN, Gmail, YahooMail, Flickr, Picassa, Facebook, MySpace, Bebo accounts, as well as for their bank, mobile phone company, energy company, and innumerable other sites, some of which they've probably forgotten that they signed up for.

So, instead of saying each account should have a different password, I'd suggest that the best thing to do is to have a few passwords, but to have some rules around the ones that you use regularly.

1. Always pick a good password. There's a guide here that offers some ideas.
   
2. Don't use the same password for a mail account that you used to set up a social networking account with. For example, if you use the same password for Hotmail as you do Facebook, and one or the other gets "broken in to", it's likely the other will, too. And then it's incredibly difficult to regain control of either.
   
3. Do change them occasionally.
   
4. Consider what you're protecting. Don't use the same password for all your important accounts (e.g. bank, email) and use a separate password for account for sites you're not overly bothered about (e.g. that Fraggle Rock appreciation site you signed up to)
   
5. Don't share them! I know this sounds obvious but don't let anyone else have your password – think about what you're giving the access to. This is especially true for passwords at university or in the workplace – the risk is much greater than simply to your data as it could impact the whole organisation.
   

These aren't simply theoretical risks. In the last few months, I have dealt with situations including the hijacking of a Facebook and related Hotmail account – believe me when I say that this is not easy to resolve – and several instances where people have sent their usernames and passwords to scammers.

The reason scammers want your username and password in a place like a university is because they want to send spam through the universities mail system. Unfortunately, this can lead to the whole university being blacklisted as a spammer and no-one will be able to send or receive email.

Please take care of your passwords.

Webmail Passwords

It was bound to happen. Large lists of account details have been leaked that were compromised through phishing, where the owners of the accounts replied to emails requesting their passwords and, in some cases, the login details to alternative accounts. We put out a message at LSE fairly frequently that people should never hand out their usernames and passwords to anyone – hopefully a fairly unambiguous statement. And yet, we still get people doing it.

I have tried to do a little research into why people continually reply to these messages, and the answer I usually get is that the email making the request "looked official".

If you have any ideas on how to get the message across, I'd be very interested.

Hacking Facebook

I just got pointed towards an article that shows that your Facebook account password is worth $100. It's impossible to tell whether this is genuine or not without sending $100 via Western Union to the Ukraine (and what is it about Western Union and scams??) but it does raise some interesting questions about how much people would be willing to pay to hack into someone else's account. I have had people come to me with this same issue and it's really difficult to regain control - it is a free service, after all.

More on this soon...

Digital Certificates

Lots of people have been discussing digital certificates with me lately, with several certificates having to be re-issued due to certificate chain problems. I thought I'd take the time to explain how these things work in simple terms.

Most people come into contact with certificates when either setting up a web server that uses SSL (Secure Sockets Layer) to encrypt data in transit or encrypted e-mail. The two main functions of a certificate are to provide encryption using the keys contained with them and provide assurance that the owner of the certificate is who they say they are. Certificates issued inside an organisation for solely internal use, the second point might not be so important as assurance can be gained through talking to the person who issued the certificate. However, under most circumstances, people need independent assurance that the owner is who they say they are.

Certificate Authorities

A request can be made to have a certificate digitally signed by an independent organisation (certificate authority) which people already trust, making the process of accepting a certificate as valid seamless. However, how does an end user trust the certificate authority? Surely, we still have the same problem in providing identity assurance with these organisations, otherwise we wouldn't be able trust their digital signatures? This has, in the most part, been solved by pre-installing the certificates of these organisations into applications like e-mail clients and web browsers that are likely to come across these signatures. If you want to take a look to see who you trust by default, try going into Tools -> Internet Options -> Content and click on the "Certificates…" button. One of the tabs across the top will be labelled "Trusted Root Certification Authorities". In Firefox in Windows, simply go to Tools -> Options -> Advanced -> Encryption (on a Mac, just go to Preferences -> Advanced -> Encryption) and click on the "View Certificates" button. One of the tabs will be entitled "Authorities". Different browsers and e-mail clients will have similar options.

The reason that these authorities are trusted is because they have stringent verification methods to ensure that certificates are only issued to the correct people or organisations.

However, there is a problem with this model, one which manifested itself at LSE, where a root Certification Authority changes its signing key and certificate pair to one that is not already present in all browsers or clients. The only way to automatically trust certificates signed with the Certificate Authority's new key is to manually install it, which is not recommended. Apart from the obvious danger that the person doing the installing has to do equivalent checks on the identity of the certificate to provide the same level of assurance as the other certificates in the root Certificate Authority list, having to get every client that may connect to that device is a nightmare.

It is by far safer to have certificates signed by a key that is already in the client. This is why most Certificate Authority's certificates have very long lifetimes, equivalent to the expected lifetime of the equipment of the client, to prevent manual updates.

The point of all this is that the client doesn't need to refer back to the root Certificate Authority every time it comes across a certificate signed by that particular CA. Nor do they even, necessarily, require a route back to the CA at any point, as long as the CA's credentials are held locally.

Expiry and revocation

Certificates all have an expiry date. It is assumed that the "private key" (that which is used to decrypt information or digitally sign other messages/certificates) will get compromised at some point. The more protection given to a certificate, the less likely it will be compromised and, therefore, the safer those certificates dependent on it will be. This paper describes the ways in which an organisation might protect its own certificate signing key.

If a private key does get compromised, it is possible (albeit hard) to revoke that certificate and any child certificates using a certificate revocation list (CRL) that is incorporated into the certificate itself. This process is, however, a bit flakey, as it defeats the purpose of being able to do offline verification of certificates based on locally-held, trusted credentials of CAs.

Trouble with unsolicited email

Many organisations have policies that state that it is unacceptable to send emails to large numbers of users either inside or outside the organisations if you don't have the recipients' consent. Mass emails present their own problems, especially with attachments. Here's a quick run down as to why.

Spam

The general term for mass unsolicited emails is "spam". The sorts of emails typically associated with spam are those for dodgy investments ("pump and dump" schemes), growth pills, religious messages, phishing attempts, viruses and everything in between. Many organisations have invested in anti-spam filtering technologies to reduce the amount of junk that they receive (see my previous posting relating to scam/phishing emails for some statistics). The technologies to identify spam is always a "best guess", using a variety of techniques, which means that some spam gets through and some legitimate emails get blocked.

At a very basic level, there are two main methods for preventing spam. Firstly, there are blacklists where servers who are known to send spam are prevented from sending any emails whatsoever to the organisation protected by anti-spam filtering. Secondly, emails that are received from "clean" servers have their content assessed to see if it matches the profile of known spam. If the score from this assessment is higher than the threshold decided upon by the protected organisation, it won't get through and, in many cases, the sender's servers are automatically added to the blacklist (or "greylist"). Rules vary for different products, but may include:

• Sending to a large number of people
  
• BCC'ing instead of sending to explicit addresses
  
• Not including a standard greeting ("Dear Sue," for example)
  
• Having a reply-to set differently to the sender's address
  

Organisation impact

A key point is that black-and greylists are shared and so if an organisation gets blacklisted it won't be able to communicate with any organisation using that black- or greylist. Members of an organisation can, quite unwittingly, get their organisation blacklisted, thereby causing a lot of inconvenience to their colleagues.

Which is why organisations take it seriously.

Data Protection

All of the discussion above is quite apart from whether the email addresses should have been collected in the first place and then used for the purpose of sending emails. If in doubt, talk to your data protection manager.

Disk Space

I also have to put a short note in here about disk space. While most modern email systems will store a single copy of an email destined for multiple recipients on an email server, as soon as the email is copied off, forwarded or archived, a copy is made and the amount of space it takes up doubles. So, mass emails that have 1MB attachments can take up significant amounts of space if sent to a large number of people. And disk space is not free.

LSE resources

If you're at the LSE and do want to send emails to large numbers of people, please see the LSE's policy on internal email communications and the Conditions of Use for IT Facilities.