Skip to content
Naked Security Naked Security

Millions of utilities customers’ passwords stored in plain text

Plain-text, unencrypted passwords were sent instead of having users reset them. There was no breach, the firm claims, but how would it know?

In September, a security researcher discovered that their power company’s website was offering to email passwords to users who lost or forgot them…

…as in, emailing in unencrypted plain text, with no salting and nary a dab of hash, to whoever might pop in a given user’s email address, instead of offering the far more secure “password reset” option.

The independent security researcher, who chose to remain anonymous, told the story to Ars Technica contributor Jim Salter, who referred to the researcher as “X” in his writeup of what ensued.

Namely, a months-long saga of trying to get the software company behind the website to realize that it was jeopardizing customers’ security and to actually do something about it… which only happened after it had refused to answer X, then finally sent X to its lawyer, who requested that X stop talking to anybody else about it and who insisted that the company’s process of handling passwords was just fine.

The company in question is SEDC: an Atlanta firm that offers “Cyber Resilience Initiative Services and Solutions” – a bit of a confusing mouthful that translates into software that handles bill payments, cybersecurity and other services for utilities providers.

After X found SEDC’s copyright in the footer of the utility company’s website, the researcher went off in search of more customer-facing sites designed by SEDC. X found plenty: in fact, the researcher found more than 80 utility company sites that all offered to email plain-text passwords.

Ars estimates that those companies service some 15 million customers, but that number could be multiple times larger: SEDC itself claims that more than 250 utility companies use its software.

X didn’t attempt to exploit any of those utilities firms’ sites. If they had, the sites’ databases would have been chock-full of credentials that weren’t obscured via encryption. Such an unlocked treasure chest could have been drained by attackers and used for credential stuffing: a well-known attack in which credentials exposed in one breach get stuffed into other websites until an attacker gets in, be it to our online bank accounts, our social media accounts, our email accounts, our smart-home gadgets, or the plethora of other places and things we want to keep locked up.

Unfortunately, people’s lamentable tendency to reuse passwords makes it an extremely common attack.

Also on the lamentable side of the ledger was the response that X got from SEDC.

From chirping crickets to a lawyerly shrug

From Salter’s writeup, who says he’s done numerous PCI-DSS (Payment Card Industry Data Security Standard) audits for clients over the years:

When X informed SEDC there was a security problem, the corporate response varied from crickets chirping to cold shoulders. Eventually, SEDC’s attorney sent X an email that could reasonably be paraphrased as: ‘there’s no problem with what SEDC is doing, stop bothering SEDC, and you’re only allowed to talk to me from now on.’

The email, from Mark Cole, General Counsel for SEDC:

We were especially surprised by your accusation because SEDC and many of our customers undergo annual PCI assessments, annual PCI penetration tests, and quarterly PCI ASV scans, none of which have identified as a PCI DSS vulnerability the practice of which you have complained. After your initial calls to [redacted] Electric Cooperative, we expressly raised your concern with a certified PCI Qualified Security Assessor who confirmed that your issue does not present a PCI violation: the password attached to a non-administrator end user userid simply does not allow access to credit card information in a manner that violates PCI DSS.


Finally, I must request that you cease contacting SEDC employees, customers (other than any utility of which you may be an end-user), and third parties to repeat your erroneous assertions about this matter.

”Ridiculous” to say “talk to my lawyer” instead of “thank you”

During their attempt to get SEDC to acknowledge and fix this security lapse, X has been getting counseling from Electronic Frontier Foundation (EFF) Senior Information Security Counsel Nate Cardozo and EFF attorney Jamie Williams about legal and ethical disclosure responsibilities. This is what Cardozo had to say to Ars:

In 2019, it’s ridiculous that vendors are replying to security researchers via general counsel, not a bug bounty program.

Cole’s final email to X again refers to there being nothing wrong with plain-text passwords as far as PCI-DSS is concerned… but that SEDC has fixed it anyway.

Sort of. Maybe.

I wanted to let you know SEDC has changed the way our software handles “forgotten password” requests for the payment portal, and we have disclosed the change to all our Customers. We also have disclosed this change and the history of your communications of which we are aware – with SEDC and our employees, with some of our Customers, and with social media generally – in detail to our Board of Directors, which is comprised of a dozen of our Customer-Members. They do not believe any further “disclosure” by SEDC is needed or appropriate.

Given that there has been no PCI violation nor any indication of third party access to anyone’s PII (in fact, the plain-text password at issue does not enable such access), it is unclear what “disclosure” you think should be made, much less under what authority you think such a disclosure would be required.

As Salter points out, SEDC isn’t saying that the passwords are now encrypted, with a strong hash, with cryptographic salt unique to each record. That means that we don’t know if these passwords are being stored securely. All we know is that SEDC’s clients’ sites are now prompting people to reset lost or forgotten passwords, instead of emailing them in plain text.

Salting and hashing

Those who shrug off the implications of storing passwords in plain text, without proper salting and hashing, might not be aware of potential legal ramifications if this industry-standard level of security is shrugged off.

One example is LinkedIn, which got itself sued not for skipping salting and hashing entirely, but rather for doing a half-job of it. In 2012, LinkedIn suffered a massive breach that led to the leak of millions of unsalted SHA-1 password hashes that were subsequently posted online and cracked within hours.

A salt is a random string added to a password before it’s cryptographically hashed.

The salt isn’t a secret, it’s just there to make sure that two people with the same password get different hashes. That stops hackers from using rainbow tables of pre-computed hashes to crack passwords, and from cross-checking hash frequency against password popularity. (In a database of unsalted hashes the hash that occurs most frequently is likely to be the hashed version of the notoriously popular “123456”, for example.)

Salting and hashing a password just once isn’t nearly enough, though. To stand up against a password cracking attack, a password needs to be salted and hashed over and over again, many thousands of times.

Failing to do so “runs afoul of conventional data protection methods, and poses significant risks to the integrity [of] users’ sensitive data”, as a $5 million class action lawsuit against LinkedIn charged.

Better safe with unique passwords than sorry with password123

We don’t know if SEDC has seen the error of its salting/hashing-free ways, but we do know that the way for users to stay safe in this situation is to make sure you use one unique, strong set of credentials for every site and every service.

Passwords should be at least 12 characters long and should mix letters, numbers and special characters, though it’s even better if you use a password manager or a hardware-based security key, such as Yubico’s YubiKey or Google’s Titan.

That, and pray that the passwordless web comes soon!


On the linked SECD page, under “Cyber Awareness Education”
people are a company’s biggest vulnerability

Rather prescient I’d say.


This a quite common. Some other websites that have e-mailed me back a helpful copy of my password:-
[7 Dutch sites redacted]


Another great exposure. The article does not say which counteries are affected but if any are in Europe then the GDPR would apply. It is a shame that when Parliament passed the Data Protection Act 2018 they did not implment Artilce 80(2) of the GDPR. Had they done so then a charitable organisation that represents data subjects could bring the matter before the Information Commissioner who has the powers to demand that appripriate security is applied. Without a breach a fine would not follow – at least initially – but the Commissioner can still instruct that processing cease until the defect is fixed and faliure would open the purpertrator to fines and prosecuition.

I mention this becuase the minister has to report to Parliament on the possible implementation of Article 80(2) and this provides an excellent example of why it is needed. In the meantime perhaps it could be taken up in another Euopean country if it is so affected. I wonder if they operate in Carlifornia!
Keep it coming.


In fairness to SEDC, this story is interesting, but ultimately pointless. Receiving power company customer passwords gets a hacker nowhere.

Customer accounts display things available in a deed search of public records and a stroll through a neighborhood to look at meters outside homes: power usage, homeowner name, and address.

Amount due isn’t secret, confidential, or proprietary information. In fact, it’s relatively easy to estimate by looking at the meters in the neighborhood periodically, then multiplying by the power rate set by the public power commission.

These aren’t medical or financial records. No credit card or banking information is exposed.

While the passwords themselves can be reused for hacking other sites, that’s not Sedc’s problem.

It’s the customers’ problem, for which the customers are solely responsible, if they reused their own passwords.


I’m sorry to be so blunt in my reply, but this sort of attitude is part of the problem.

If you can’t be bothered to take even the most modest and reasonable precautions in storing my password – and this is a billing company, not a public records office – then why should I trust you on more important matters, such as billing me fairly, processing my payments securely, not storing my CVV security code after you’ve processed my transaction, keeping my payment schedule private, handling any disputes confidentially and decently, and so on?

The idea that a company that collects, processes and stores billing data on a huge number of customers shouldn’t have to care about computer security because – in theory at least – you could visit every household on the list, break into their property, peek in the cupboard under the stairs, take a meter reading of your own, and estimate their bill…

…unusually for me, words fail me so I shall stop here.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!