[hnaj]

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.

[rwbhn]

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

[heavenlyblue]

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

[Arnt]

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.

[onion2k]

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.

[Arnt]

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.

[imtringued]

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.

[heavenlyblue]

>> 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.

[Arnt]

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

[johannes1234321]

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

[heavenlyblue]

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

[folkrav]

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.

[rocqua]

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.

[icebraining]

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

[heavenlyblue]

>> 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.

[donatj]

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.