BT caught in data gaffe drama: Whistleblower squeals over alleged email fail BT is being investigated by the UK's data regulator after a whistleblower exposed evidence that allegedly showed the one-time national telco's customer email accounts were being compromised by spammers, The Register has learned. In May last year, BT unceremoniously ditched Yahoo! Mail in favour of a white label product from …
From what I can see, from the user end the logon credentials for btinternet are HTTPS. Of course, that doesn't means it's HTTPS end-to-end. The HTTPS termination point can easily be at a different point in the communication chain to the actual email web server - it just goes through some form of proxy service. However, it's unclear from the article where the exposure is meant to be.
BT used Critical Path software for scanning and load-balancing circa 10 meeellion X.400 and eSMTP mails when it managed the NHS Messaging Service. The s/w was as good as anything on the market at the time, early 2000s, for performance and virus detection, especially when minimising false-positives.
Seems CP may have gone down-hill a bit since then.
BT used Critical Path software for scanning and load-balancing circa 10 meeellion X.400 and eSMTP mails when it managed the NHS Messaging Service
Is that the same X400 service that would either wait for a couple of days to process an email or barf at any one over 2MB and then still charge the translation costs despite the message failing?
I must thank them for that, because switching the service for one department to an SMTP based platform (on a protected network) had as a consequence an ROI time of only 2 months. I have rarely seen a project signed off so quickly, ever :).
As the X.400 service had a 24hr timeout, you would have got an NDR sooner than 2 days! At least you would get a NDR, with SMTP you don't know whether the message has got there or not. It was hardly the fault of BT (Syntegra) if the end-site system wasn't configured correctly and wouldn't accept a message.
As for the message size limit, that was the NHSs decision. As least this was abolished when per-message charges were abolished.
There is no doubt that in the early days of the NHS Messaging Service, the DEC MAILbus X.400 MTAs were 'bleading edge' and the registration and charging systems were crazy.
Ah, no - I used this *cough* "service" *cough* in government, and came away seriously unimpressed.
Sure, security and delivery were assured (when it actually worked) but it was WAY over the top for the division I worked for, and massively expensive compared to the alternative (switching to SMTP carried inside the Government Secure intranet). Also, whoever implemented the department end was, umm, competence challenged as far as I could detect, so just cleaning up the mess improved matters.
As said, an ROI of 2 months was exceptional, but the funniest was the user reaction when they had near instant email instead of the usual delays: we were asked if the system was BROKEN :). Given the normally glacial pace that department worked at, I suspect we may have frightened some people :)
Having discussed this with senior BT UK support, approximately 600k BTYahoo accounts have been "done over". It also seems that user profie information stored against accounts and used for password resets etc. was also compromised.
I assume that is the case because when the online pw reset process had failed for the second time in three weeks and I was moaning like f**k about the time taken to carry out all the recommended actions (scan all systems with AV etc, change pw's for every service I had mail for in my BTYahoo mail folders) I was talked through the pw reset process by India support (quite efficient actually), and discovered that appended to the beginning of each field containing my security profile data was the word "COMPROMISED_" .
Address, mother's maiden name, first school etc. All the kind of information you do not want to have slurped up willy nilly by script kiddies and worse, alongside your email coms for the last xx years.
The penny dropped as to how someone could compromise my account so quickly and repeatedly. Not much point having a half decent password when Jonny Scriptkid has downloaded all your security profile info and can reset it at will. BT and others demand ever more personal data supposedly to help secure your services then they end up dishing it out for free to save a few bucks.
I usd to assume BT at least were going to be (or ensure any service provider they use would be) carefull with the security profile information, but apparently not.
If you have a BTYahoo account you might care to check this out and then change any passwords for any other facility that has ever been in contact with your email service. You might also change your security information, and if you have not already, construct a fictitious set of information to protect your real idenity information. Having not lost a password for many years, I had avoided having to enter much of this anyhow. Frustrated at the delay in being able to access my own email and lulled into a false sense of security dealing with BT, I foolishly added some real data to my profile, only for this to be snaffled of my profile by some skanky sod. Talk about cobblers boots...:(
The reason for using different wrong answers is precisely to limit the pwnage as far as possible (preferably to that one service)
There may be some services where providing some(*) correct answers is unavoidable. These services will hopefully be slightly better defended by the fact that they do not share "security answers" with your less critical services.
(*) for varying values of some.
Another pair of words rendered meaningless by PR wankers, since now any time they're deployed in series by a company employing more that 4 people, they pretty much point to the fact that the reality is the exact opposite.
Perhaps PR types ought to develop their own language entirely and leave English unsullied for the rest of us; something perhaps with the built in ooze of greasiness and insincerity they all seem to wear as after shave. A nice side effect is they'd be easier to ignore.
I await the less than resounding 'thwock" of a quiet tap on BTs wrist.
I have a customer who has had their BT email account hacked at least 5 times in the past two years.
He won't give it up, though I have moved him to a new email service to use as well. I think the last two times we reset the account with complex 20+ digit passwords but still they got round it. So I guess the previous post mentioning that all the security data questions have been slurped rings true.
Edit: In fact just logged into my BT email account (I dont use it, ISP provided) and in the settings I clicked on Edit Security details. It then came up with a window saying the content and location isn't trusted.
I received a phishing attack on my BTmail account claiming that it was about to be suspended. Contacting BT about it, I was instructed to change my password, trying to do so I was bounced by the system because it thought I had already been compromised.
20 minutes on the phone to India got that fixed and I managed to remind them about the £50 voucher they had forgotten to send me when I signed up for Infinity.
Guilty consciences must have kicked in cos the voucher arrived today.
... the ICO blamed BT's own customers for the Phorm affair (claiming there was a measure of "implied consent" for private/confidential telecommunications to be covertly intercepted & secretly sold to Phorm).
And also the same ICO that blamed ACS:Law for *receiving* unencrypted emails from a lawyer in BT (whereas BT were supposed to comply with a court order instructing them to encrypt the data *before sending* it via CD/media). Not that ACS:Law were blameless, but if the data had been encrypted as instructed by the judge, it would probably never have been hacked. BT escaped any penality in that instance too.
So sadly... I expect the ICO's conclusions to be that BT customers were somehow to blame... and BT Directors to be completely exhonerated :(
I call it Muffins Law (cf Tea & Muffins at the ICO).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
