Slashdot Mirror
ISP Emails Customer Database To Thousands
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"."
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.
If you're a zombie and you know it, bite your friend!
Demon wanted all customers to take up eBilling several years ago. You had to opt out of eBilling. I opted out because I wanted a printed invoice to give to the accountants and because I thought sooner or later so cockup like this would happen. My choice has been vindicated. And no, I won't be looking for another vendor. Demon are more expensive than other vendors, but other than the eBilling foulup, they are generally good and no bandwidth restrictions or upper limits at all. And that is what I want.
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.
Give me Classic Slashdot or give me death!
Their biggest competitor is BT ... Not quite seeing a stampede happening in that direction.
There's always Orange, I guess...
(...and to think that I bitch about Comcast...)
Quo usque tandem abutere, Nimbus, patientia nostra?
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.)
Nothing for 6-digit uids?
I'm amazed that you never heard complaints. I was with them for 14 years, but left a few months ago, as their service deteriorated to a level that was completely intolerable. The original company was good, but was successively taken over several times, and all the competent people left. Have a look at the Usenet newsgroup demon.service and you will find plenty of complaints...
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.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Apparently you've never worked at an office. A bulk of computer complaints at such corporations tends to be from a combination of boredom and stupidity. Frankly, it's amazing that the entire world hasn't collapsed given the sheer number of "why can't I watch porn on our secure network??!!!11!!" type of inquiries; now imagine the same average cubicle corp running your internet.
(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.
(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.
http://michaelsmith.id.au
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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?
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.
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.