Data loss, Information Security, Password Hashing, passwords, plaintext, plaintext passwords, Privacy, salting, Security threats, Top News, unencrypted

Millions of utilities customers’ passwords stored in plain text

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 payment, 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!

Source : Naked Security

Previous ArticleNext Article
Founder and Editor-in-Chief of 'Professional Hackers India'. Technology Evangelist, Security Analyst, Cyber Security Expert, PHP Developer and Part time hacker.

Send this to a friend