Wednesday, 13 January 2010
Webamil insecurity
You get what you pay for
It’s true: if you don’t pay for a service, why should you have any expectation that the provider is under any obligation to you? If you look at Microsoft’s “Terms of Service” for Hotmail, it clearly states that it provides no warranties for the service. In addition, the content may be stored pretty much anywhere in the world. So, how can people assess the risk of storing confidential information in these systems?
Auto forwarding mail
I have also come across people who automatically forward all of their work emails to an external Gmail or Hotmail account as they find it easier to use than the company-provided mail system. It might have more features; have a prettier user interface; whatever... However, this could potentially create a serious headache for the company or organisation concerned. Authentication to web-based mail systems is usually weaker, employing simple password-reset routines, where people can set their own questions (I saw one who had written, as his secret question “What is Captain Kirk’s middle name”. Not exactly the hardest thing to find out).
People routinely using webmail for very sensitive information, where the implications of disclosure include risks to people’s lives, should really reconsider whether using something like Gmail, Yahoo mail or Hotmail is a good idea in the first place.
There are a few solutions. Stick to your company’s mail system and consider using encryption, or try to use encrypted mail with webmail accounts. Encryption brings a whole new raft of issues I won’t go into here, but some companies already provide an integrated, but paid for, service to do this, like Hushmail.
But never forward email out of a company automatically to an external source without checking with your IT department first – there may be many more serious implications than you might realise.
Friday, 9 October 2009
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.
- Always pick a good password. There's a guide here that offers some ideas.
- 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.
- Do change them occasionally.
- 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)
- 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.
Wednesday, 7 October 2009
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.
Monday, 5 January 2009
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.
Friday, 5 December 2008
The Anatomy of a Phishing Scam
We've been suffering from a plethora of phishing scams over the last few weeks at LSE. To put this into context, Messagelabs stop in excess of 250,000 spam e-mails from arriving at our mailboxes every week, which represents 25% of the total (1,108,000). So, when one does get through, it is a bit unusual. In the main, these don't cause a lot of disruption as most people are conditioned to ignore them. However, there's always someone who does reply and the IT department spends quite a bit of time clearing up the aftermath.
So, here is my one top tip to not getting caught:
Never, ever send your password to anyone by e-mail.
It's quite simple. No-one should ever ask you to disclose your password by e-mail and you should never, under any circumstances, give it to anyone.
What happens if you do
Here at LSE, we have a set of Conditions of Use for IT Facilities which clearly state that you shouldn't do this. Most organisations with an information security policy say the same thing. Generally, you can expect your account to be suspended as a minimum.
However, that's not all. Scammers will use the details that they have gained to abuse the account they have access to steal information and, most likely, send spam out from the account. This means that the account gets blacklisted. Which is a pain.
Phishing for Bank Details
This is obviously a subset of a much wider attempt to con people into handing out personal detail, either directly or trying to convince them that they are on a legitimate site. Many people have received e-mails, purportedly from their bank, asking them to log in by clicking a link in the e-mail and filling in all of their authentication information.
There is a simple way to avoid being duped by one of these e-mails. Never click on the links in the e-mail: always go directly to your bank by manually typing their website address in the address box of your browser.
Browser defences
On top of this, many web browsers now (or will soon) incorporate anti-phishing tools. For example, Mozilla Firefox has a feature that, if turned on, automatically blocks access to known phishing site.
If in doubt, don't click. And another tip: don't reply to these scam e-mails with some sarcastic comment: it only confirms your address and you'll end up getting more spam.
Monday, 1 December 2008
Encryption issues
Many people ask me about the issues surrounding encrypted devices and whether they can (or should) encrypt data. So, to clear up any confusion, here's my take on this issue.
First point: Encrypting data, especially on removable devices, is a good idea
Given recent events relating to the loss of sensitive data (like, the loss of nursery data on a USB stick, Government user IDs stolen from a parked car, the banks losing customer data, Number 10 staff losing their Blackberry's in China… This list is endless), it is blindingly obvious that some form of protection for data while not stored in a physically secure environment is needed. The losses actually reported are dwarfed by those that companies elect not to report. There is a great debate going on about whether companies should be compelled to report these sort of breaches under Data Protection legislation, as currently most organisations don't have to.
In addition, individuals should ensure that their own data is adequately secured. It's not just companies that have this problem. How many people store their passwords to their online banking on their laptops and then carry them around with them all over the place? And, given that most operating systems have built in encryption capabilities these days (Microsoft Windows XP and Vista do, as does Mac OS X), people should really consider turning these on.
Second point: There are lots of different applications for encryption
There's device encryption, full disk encryption, e-mail encryption, SSL encryption for websites and other types of traffic, VPNs… Plenty of different applications for very different purposes. And managing this becomes a bit of headache…
Third point: In an organisation, it's not that simple…
Having said all of the above, it would easy (but wrong) to assume that it's very simple to implement encryption in an organisation. It isn't. There are three choices: 1. Implement stand alone encryption for everyone who needs it, using a variety of different standards and without the capability to access these in the event of a disclosure requirement; 2. Implement an integrated encryption service, managing people's keys centrally (or at least having an administrative key for access in the event of a disclosure requirement), or; 3. Take the risk and don't do anything.
The trouble with option 1 is that the organisation is liable for everything that gets sent or stored from or on its systems. In the event that a request to disclose some information stored in an encrypted file or e-mail is made by the authorities, it is essential that, given the right safeguards, an organisation can access that data. If everything is set up in a standalone fashion, this becomes difficult.
Option 2, therefore, looks much more attractive, but it does come at a cost, both in terms of infrastructure and management. Many organisations opt for option 1, but ensure that each user of encryption software sign a disclosure agreement that warrants their co-operation in the event the organisation is requested for data held in a system that they, themselves, control.
Finally, option 3. I would not recommend going down this route. The Information Commissioner seems to be blowing hot and cold over the absolute requirement for device encryption, but it looks likely that principle 7 of the Data Protection Act 1998 will be breached if laptops and other personal data aren't encrypted.
Fourth point: Travelling with encrypted files
This may come as a bit of a surprise, but different countries have wildly different laws about encryption, so it is essential that people check out what the legislation is in the country that they are travelling to, in case they are accused of espionage activities (I'm not kidding!). For a comprehensive overview, the University of Tilburg, in the Netherlands, is hosting a page on the Wassenaar Arrangement. This details how different countries license the export and import of different levels of military materials. To quote:
"The Wassenaar Arrangement controls the export of weapons and of dual-use goods, that is, goods that can be used both for a military and for a civil purpose; cryptography is such a dual-use good."
As an example, I've picked Russia. It states: "A license is required for the importation of encryption facilities manufactured abroad. The export of cryptography is subjected to a tightened state control. Importers and exporters need licenses by the Ministry of Trade."
I am not a lawyer, and I suggest getting legal advice rather than ever relying on something you've read in a blog.
More information: