Four million TalkTalk customers are worried that *their* details might be amongst the information stolen by hackers.
There is a dearth of information at the moment, as TalkTalk scrabbles to work out what’s happened. The last thing I imagine it wants to do is go public with details only to have to come back later and say “errr.. sorry.. it’s actually worse than we thought”.
So, I have some sympathy with the position of TalkTalk’s CEO Dido Harding, who clearly looks anguished as she was interviewed live on BBC News, and found herself on the receiving end of customers’ questions.
All the same, with so many customers concerned – it’s important not to give them *bad* advice.
Watch my latest video to find out what she said, and subscribe to my YouTube channel if you’d like me to make more like this.
Remember, it’s child’s play for phishers to forge the from: address in an email. Never use a correct from: address as an indicator that an email is legitimate.
Found this article interesting? Follow Graham Cluley on Twitter or Mastodon to read more of the exclusive content we post.
12 comments on “VIDEO: TalkTalk’s CEO offers some poor advice, following hack”
Checking talktalk.co.uk for an SPF record finds nothing. If that's the domain they use for email, they apparently don't care if spoof messages are sent to their customers.
There is zero excuse for not using an email security mechanism, such as SPF – with hard failure, DKIM, DMARC. (SPF with soft fail is useless.)
There should be a day very soon where domains with insecure email should have their messages refused.
Well their DNS is completely broken, anyway, so whether they have an SPF RR is rather besides the point. talktalk.co.uk is a CNAME to an IP address and CNAMEs are aliases to an A/AAAA record, not an IP address. Is it actually their domain ? If it is they have more problems than being compromised (unless it was done by said attacker – but I doubt it). SPF is irrelevant here because of this.
Also: SPF with soft-fail isn't completely useless – it can be useful in testing (just like when testing MTAs some people might rely on soft errors versus hard, when initially deploying the server). If you consider mail providers, you will understand they have to be really careful with just how strict they are (as below). But you're ignoring something else. SPF doesn't have to be honoured by the servers (and it isn't like a spoofer would use the actual host they are spoofing!). Whether it is soft or hard failure is irrelevant if it isn't being checked.
Also, did you check 'SPF', 'TXT' or both (though as I already indicated it is rather a moot point) ? As I recall, the RR SPF was deprecated, for example. But even if SPF was honoured 100% of the time, the fact is it is a syntax that is easy to make mistakes, and this would lead to a lot of lost mail. I'm sorry to tell you this, but your users won't at all appreciate or accept lost mail. There is no getting around to it. All administrators know this.
Thing is filtering will never be perfect. Spam filtering is far from perfect, for example, and that's how it will always be; there will always be false positives just as there will always be false-negatives.
So there definitely should not be a day where email is refused simply because of lack of SPF/etc. Besides that, even if SPF/etc is in use, it still is INSECURE if it is in plaintext, which funnily enough, almost all emails are. It also isn't secure if it is spreading malware, and your suggestions are irrelevant to this, too.
@Mike 1 October 23, 2015 at 8:35 pm #
'There is zero excuse for not using an email security mechanism, such as SPF – with hard failure, DKIM, DMARC.'
'There should be a day very soon where domains with insecure email should have their messages refused.'
In a perfect world, yes… Having every email host/domain restraint mandated to comply with mitigating against spoofing would be great, but who'll govern this?
@coyote 582 October 24, 2015 at 2:10 am #
'Also: SPF with soft-fail isn't completely useless' … 'but your users won't at all appreciate or accept lost mail.'
Having to rely on SmartHosts or external MTA's is one of the reasons to have a 'laxed' SPF. If changes occurs without your knowledge, as you mentioned, you'd hope outgoing emails are being delivered.
I've seen examples where receiving ends don't even check for PTR, let alone SPF, DKIM and DMARC, but rely on weeding out nasties based on attachment sizes, content, phrases, words, etc… Some smaller organizations probably don't even have this luxury…
'Thing is filtering will never be perfect.'
Agreed. 99% it 'may' work well, depending on the volume of inbound traffic, products and personal involved.
I've seen the likes of Google/Microsoft plainly block all inbound traffic from an entire Class A IP block! (With the exception of a handful, but even still…). Fighting battles with these juggernauts is like pushing the preverbal up hill.
'it still is INSECURE if it is in plaintext'
Very true. I've only seen limited uses of encrypted email. Something that isn't mandated and widely implemented.
Graham, I think you're a little hard on Dido Harding. She did say "check the email header", and not the email From: address. Getting at the email header may be a little difficult for some users, especially if using Outlook, OutlookExpress, or whatever MS's latest "email" client is. Much easier in Thunderbird, TheBat!, or AMEOL. And once reading the email header the member of the public does need to know what they are looking for in the Received: lines.
Checking 'the' email header would imply A email header, of which there are many different kinds.
Yes, most wouldn't understand how to read any of the headers, let alone the way each host adds another header, or whatever else.
But still, it is a lot more complicated than just checking a header and the point he is making is that it is incredibly easy to spoof mail headers. You can even add your own headers although some MTAs are (justifiably so) configured to reject mail with bad headers.
The problem is simply that there is a desperate shortage of experienced software developers.
At my employer we have a senior developer who doesn't understand the principles of OOP, and we've seen a lead developer in India who couldn't concatenate a string. I have an acquanitance who is a consultant for a major high street bank who is regualrly seeing code that he regards as of being appalling quality.
The public demand for the technology is simply advancing too fast and the staff just aren't there for it. It might help if corporations took IT more seriously and paid developers more (it is still a comparatively badly paid profession), and ran training schemes rather than just trying to outsource it all to developing countries. Maybe if their bootom line is threatened consistently they might think more long term but I am not holding my breath.
To judge a programmer by them not understanding OO isn't entirely fair (whether they should know it or not is subjective bias). It is just one way of solving a problem and it isn't the right or wrong approach. This is just like you can accomplish something in different languages but with the exception of performance (and/or restrictions e.g. because of embedded systems), there isn't a right or wrong language. For instance, while many would go for C++ over C, C is generally more efficient, smaller and for those who understand it, easy to write in. Many will claim it is easier to make a mistake but the alternative is what many others would say (e.g. as I would) – those making the mistakes could do well to learn more and gain more experience. Oh, and please don't touch assembly, because if you can't handle C you won't be able to handle assembly.
Put another way, OO isn't programming and therefore, OO isn't an indication of experience in programming, algorithms or anything else that matters. Programming is much more than that.
No comment on concatenation.
It is also worth pointing out, on the subject of email headers, that there is a difference between:
MAIL FROM <[email protected]>
From: <[email protected]>
.. which makes it more complicated for those unaware of this fact. Specifically, if you were to send from (MAIL FROM) one address and then add From: (under DATA) as another address, the mail client would see the latter as the sender.
"Remember, it's child's play for phishers to forge the from: address in an email. Never use a correct from: address as an indicator that an email is legitimate."
Two thing first :-
1/ Apologies to clued up people to whom this question will sound daft.
2/ Graham will you answer questions for free?
I use windows vista mail , and have found that if I select an email,right click on it, then left click properties then click details then click message source, I get a box that lets me read what's in the email and the envelope icon on the email still shows an unopened email.
Question , is this a safe way to read emails that might be unsafe , or is it just a spurious hiccup and I am still opening the email which might be harmful.
Yes, what you describe should be safe. You generally have to click on a link or open an attachment to be infected.
Of course, there have been vulnerabilities found in email clients in the past which have allowed malicious code to run just by *previewing* a message – but that's thankfully rare.
By the way, a good place to ask questions is in our Q&A forum:
Thanks for your answer it's put my mind at rest somewhat (and I will use the forum in future) , I'll now go on to read what t/t sent me , there's nothing wrong with being paranoid you know I see it as a natural defence mechanism ;-)