ISP Emails Customer Database To Thousands 259
Barence writes "British ISP Demon Internet has mistakenly sent out a spreadsheet containing the personal details of more than 3,600 customers with one of its new ebills. The spreadsheet contains email addresses, telephone numbers and what appears to be usernames and passwords for the ebilling system. It was attached to an email explaining how to use the new system. Police forces and NHS trusts are among the email addresses listed in the database. A spokesman for Demon Internet confirmed that the company "was aware this happened this morning"."
computer billing story (Score:5, Interesting)
I run a movie theatre and send and receive a lot of freight (film cans and advertising materials) by bus. I have an account with the provincial bus company so they send me a bill once per month containing all of the waybills for that month.
This story goes back several years, as you will see.
Originally, I got a monthly bill that consisted of a strip of adding machine paper stapled to an invoice that totalled up my waybills for the month. Then the bus company decided to modernize and send out bills printed by computer, which were apparently aggregated by having a computer in each bus depot send in each days transactions by modem to a central computer that printed the monthly bills.
For the next year and a half, I got bills for anywhere from $10 to $30/month, nowhere near the $600-plus that I usually spent on bus freight.
18 months later I got a (manually generated) bill for $13,000.
The bus company has since stayed with manually generated bills and has never tried to computerize that part of their operation again.
And this is partly why I refused eBilling (Score:4, Interesting)
Re:To err is human... (Score:3, Interesting)
There's absolutely no reason to store passwords in the first place. In fact, in a well designed system it would be impossible for the ISP to know the passwords. They'd be hashed and salted first. This is so obvious and simple to do that failing to do so should be considered criminally negligent.
Re:Free market will fix this (Score:5, Interesting)
Their biggest competitor is BT [bt.co.uk] ... Not quite seeing a stampede happening in that direction.
There's always Orange, I guess...
(...and to think that I bitch about Comcast...)
Looking forward (Score:5, Interesting)
I think that we should start putting ficticious information (something blob-like, like a customer name) into sensitive databases that matches one or more virus signatures. This would cause email filters to block the content before it leaves the premises. (Yes, I realize that we'd need to be filtering out-going mail, but unless you're a spam generator, that's a small fractgion of your incoming email. Some of use are already doing this, although not for this reason.)
Re:Free market will fix this (Score:4, Interesting)
Re:And this is partly why I refused eBilling (Score:2, Interesting)
My experience of the same thing... (Score:5, Interesting)
Yes some asshat will accidentally forward whatever. How this occurs is demonstrated by my example below (I witnessed this, details altered). I've see co-workers make this mistake, and I've been a customer when the same fault happend and I got sent a 700kb spreadsheet of confidental information. But anyway, here is the two step method to epic fail:
Step 1: Email staff with a template for them to send, and attach a spreadsheet of the customers
-----Original Message-----
From: Bob Smart [mailto: Bob.Smart@[-------].co.--]
Sent: Thursday, 23 September 2008 10:53
To: [-------] Outbound Contact Team
Subject: FW: eBill template
Hi Team,
Please send this template below to all customers in the attached spreadsheet. You three can divide the work amongst yourselves.
>
Dear customer-name-here,
[etc..]
Step 2: Your keyboard jockeys forward the email, deletes the header and Boss's message. Inserts customer details into template. Send, Boom, Done.
By default, forwarding in pretty much all mail applications keeps the attachment.
I'm sure this is the principal way documents are leaked from just about any organisation.
Re:Someone had better lose their job. (Score:2, Interesting)
Re:They shouldn't even have the passwords (Score:1, Interesting)
(and spreadsheets aren't databases, you can't write SQL queries against them)
A. Just because Excel isn't an SQL database doesn't mean it's not a database.
B. Who says you can't write SQL queries against a spreadsheet? Give me 20 minutes and I can write up a simple program that will accept basic SQL input to modify an XLS file. Spreadsheets are simply tables, columns, and rows, after all... just like SQL databases.
Re:They shouldn't even have the passwords (Score:4, Interesting)
(and spreadsheets aren't databases, you can't write SQL queries against them)
I know. Where I work they would probably employ an intern to copy and paste passwords between the database and the spreadsheet because the database in complicated while everybody understands excel. SQL has been pretty much replaced by the scripting and macro languages supported by excel anyway.
Re:Free market will fix this (Score:4, Interesting)
Anyways, yes, if someone finds a decent ISP let us know please.
I've been with Zen's ADSL service for a couple of years now, since moving house. Give or take rare small glitches (and even then, they've had fewer of those than anyone else I've used) their service has always been fast and reliable. They don't have 24/7 tech support available, which did worry me to start with, but since I've never needed to call tech support once the service was set up that no longer bothers me. It does cost significantly more than the cheap providers as well, but I guess you get what you pay for. YMMV, caveat emptor, etc., but I'd sign up with them again.
Why is this even available? (Score:2, Interesting)
I realize most people don't use negabases or other things that would prevent marketing twats from getting their filthy grubby hands on information--but why was there a password field even available to anybody to start with?
Four years ago I inherited an application with plaintext passwords. Yes, it took me *two years* to fix it because of other even worse problems--but it was fixed in the end (SHA1, salted per user in the front and tail).
Our support team bitched and moaned that they could no longer troubleshoot problems by looking up the user's password to login as them--then moaned even louder when I took away their database access entirely (I would have done that *first* if I could have gotten away with it). Now they log in as an admin and switch to a "user view" where they can't break anything without clicking an "edit account" button, and have read-only access to some predefined views on the database they can't edit. No more worrying about IT writing to my database or starting transactions they don't finish. No more tools playing with SQL on their lunch hour taking down production by dropping the wrong table... Best practices exist for a reason. Because sooner or later you grow, and the new guys don't get properly indoctrinated and do something stupid.
Our old supportteam staff wouldn't even be able to find the password column in the account table anymore--because it *doesn't exist*. It's basically a "passwordImage" table joined on accountids, with permissions set on the entire table such that only the authenticator service can read it.
For a company with an actual budget--it just seems inexcusable that plaintext passwords could be made available, much less were given to somebody who was foolish enough to let it leave a terminal.
When will people be held accountable for their complete absence of best practices and willful ignorance?
Really! (Score:4, Interesting)
This reminds me of when I was hired to do some maintenance on a small fantasy racing team website. The website seemed pretty well implemented and the database seemed reasonable. I then took a look at the account info table and was horrified to find that everything was stored in plain text, passwords, real names, user names, CC numbers, addresses, etc. I'm not exactly a database/web guru, but come on! How hard is it to use md5() to store passwords?? And I don't like the idea of some random guy (me in this case) being entrusted with everyone's credit info. There has to be a better way.
I learned my lesson though. I will never pass my credit info to a small-time website. To think that a fairly large ISP would be this stupid in the year 2009 is mind boggling.
Re:To err is human... (Score:2, Interesting)
I used Three in Australia, the PAP login was a dummy - set by them, the user doesn't need to know this one.
It may be true that most ISPs do use this as the only password - that's their risk.