Hacker News Reader

Comment by dorianm | Hacker News Reader

Full list of 5000+ websites that store their passwords in plain text: https://github.com/plaintextoffenders/plaintextoffenders/blo...

View on HN

That list is very out of date. One of my clients appears on there and when we took over in 2012 we encrypted all their user credentials.

Encrypting passwords isn't really much better, though, is it? It's still reversible as there has to be a key somewhere.

Their FAQ [1, 2] suggests that using an encrypted password still warrants an entry.

[1] http://plaintextoffenders.com/faq/devs

[2] http://plaintextoffenders.com/faq/non-devs

Well you took over and did a terrible job.

Hash passwords, not encrypt.

An encryption is reversible, a hash result isn't.

http://plaintextoffenders.com/post/4629405305/discovercardco...

Ugh. A credit card company...really?

IME banks often have poor security. And why not? They managed to rebrand robbery as identity fraud.

It's just infuriating, because credit card companies are the ones behind, for example, PCI. Which has guidance like:

"8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography"

This requirement is technically fulfilled by encrypting transmissions with TLS and storage with disk encryption like LUKS or Veracrypt. It does not really say anything about password hashing.

The screenshot shows that the plaintext password was sent over SMTP. So it isn't meeting that bar either.

What makes you think it's SMTP and not SMTPS?

Because you can't force the endpoints of your customers to all support that.

ironic how the linked website itself is a "plain text offender" by not using HTTPS, causing HTTP requests to be sent over plain text.

Someone should send a friendly email to each of those offenders, linking the ruling.

It's also fair to say that the next few years will be a busy time for the government agencies tasked with GDRP enforcement.

(Assuming they do it properly, which falls within the responsibility of the relevant country)

They should, though assuming a bloated org structure and process, fixing it now is probably more expensive than the €20000 fine.

Note that the actual cost to Knuddels is much higher, because you also have to include the cost of implementing proper security measures. The Data Protection Officer's statement (https://www.baden-wuerttemberg.datenschutz.de/lfdi-baden-wue..., in German) states that the total cost to Knuddels is a six figure sum.

But the fine would have been more if they had refused to fix it. So the calculus isn’t straightforward.

For a larger company, should be considerably higher.

Also, the ruling mentioned a reduced fine for cooperation and quick remediation. This probably wouldn't play out so well with a bloated structure and process, as you mentioned.

I've looked at many of those Tumblr posts; most of them show that the website sends you a welcome email with your password in plain text, which is bad practice, but doesn't prove that the password is stored in plain text in the database.

But which proves that access to the website codebase will grant you access to those passwords.

Access to the code base, gives you access to the login form. And gives access to all data.

I did not imply you can change the codebase, by the way.

No. I've implemented precisely that and it doesn't prove what you think.

What you do is have one single function create the user, pick a random password, set it in the database (which in my case uses a perfectly sensible hash) and send the user email. The cleartext password in the mail comes from the function's local string variable, not from the database.

Whether doing this is a good idea is another question. IMO it usually isn't. But this kind of mail does not prove cleartext access.

What if the email with the plain text password is sent after a user pressed on the "I forgot my password button"? Because so far I only have encountered this type of email where the password is sent in plain text.

>> No. I've implemented precisely that and it doesn't prove what you think.

Well, the way I read the parent is that you can request a previously set password to be sent to your e-mail.

GP said … "sends you a welcome email with your password in plain text" … which seems clear enough.

How often do you purge your mailserver's logs (or if you use a mail API, how often do they purge their logs)? If it's "Never, I didn't think of that." then all your user's inital passwords are sitting there for the taking.

Of course, you may have a system that forces a password reset on login. That won't help the users who have never logged in. Those accounts are freely available to a hacker.

Plaintext passwords anywhere are a really bad idea.

You make it sound as if most mail servers log message contents. None of the servers I've used in the past 25 years did that (sendmail 5 on ultrix, later smail 3, then zmailer, then postfix).

The recipients' servers store the message with the password, of course, but they also store the other messages the same user has received from the same server, which in my case contain the same information as what could be accessed with the password. So the password offers very little additional value to an attacker, compared to just reading the mail.

Presuming you mean Access to change the codebase, this would also be access to add a key logger. If someone has write access to your production codebase you’ve lost all data.

It's a matter of storing it in plaintext or not, which any sane developer knows not to. The codebase will always have access to your plaintext password at one point or another, whether it's on signup before they hash and store it, or when you login before comparing hashes.

If someone has access to your codebase you've got bigger problems than plaintext passwords anyway.

The codebase will always have access to your plaintext password at one point or another.

Not necessarily. The simple solution is client-side hashing. You could combine that with challenge-response to only reveal the password hash to the server once.

The client-side code that does the hashing is part of the codebase.

>> If someone has access to your codebase you've got bigger problems than plaintext passwords anyway.

You're joking, right? The context of the discussion is when your database is already leaked. Then the chance is that your e-mail database is leaked, too. You may leak code, too. It doesn't necessarily mean someone can execute arbitrary code on your server though, yet.

The discover card email reads "Here's your _existing_ password".

Reply on news.ycombinator.com