@dang (?) this is not a dupe, it contains a lot of various interesting information not only related to Cloudbleed, especially in the second part of the video when they eliminate all the core dumps (going as far as updating micro code because of an hardware issue)
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.
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.
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.
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.
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.
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.
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.
>> 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.
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.
