Because of this:

If a site is using plaintext password often the owner asked for it. They wanted their users to be able to recover their passwords. And the dev didn't understand why this was a bad idea. They need to be educated, convinced and then convinced that the time you're about to spend on fixing this is more important than the 101 other things going wrong because the original dev wasn't very good. And isn't actually causing a single problem right now.

That also means that the password recovery function uses this code. Maybe there's an auto-user generator when you sign up for the newsletter. The email system obviously also uses that code. That also sometimes even means the password is stored twice, once in the framework's user mgmt tables and once in a user or person or the tblPRSN_UPDATED_OPTIMIZED_mc table. And just deleting that column might cause all sorts of other problems. Setting it null might cause bugs. Setting it empty string might cause a massive security hole as there's a login mechanism you haven't even found yet. (remember the dropbox breach?)

It's never a 3 hour job to fix unless you're very bad at estimating, are working on something extremely trivial or do a half-ass job, potentially introducing a far worse security hole.

It's quite possible the dev knew it was a bad idea and maybe even argued against it but was told to implement it this way anyway.

The problem a dating site probably has is people who sign up accounts and then stop using them. They want to send these users reminder emails in the hope that some of them re-engage.

Problem is that some of these users have probably forgotten which password they use for that website, and some % of those will not bother using the password reset mechanism.

So someone in marketing has the bright idea of sending emails that include the username/password combo, the dev explains why this is a terrible idea and then gets overruled.

I include an "Instant Login" link in each mail so the users don't need to remember their password. It contains a unique time-sensitive token to identify the user and instantly sign them in (much like a password reset). I learned this technique from OKCupid, so no idea why they still had plaintext passwords.

It turns out Cupid Media is unrelated to OkCupid.

Maybe simply emailing the password still has a higher conversion rate than the one time link, for example if the user does not see or understand the link or perhaps they want to login later when their email is not open.

It can be difficult to argue for security in cases where even small % of short term revenue might be affected.

I hope you educated your users not to forward any of that mail.

After how much time will the token expire?

Yeah, I'm being a bit hard on the original dev!

Most of the times I think it's due to owner and/or developer wanting to harvest passwords. I've seen it happen.

Sure, it's not hard to use bcrypt for passwords. It's also not hard to make your login forms use https, or to do weekly backups, or to use source control, or to keep Wordpress up to date. Yet many many websites/apps/companies do not get these right.

The barrier is not difficulty. The barriers are lack of time to spend on infrastructure/security improvements, lack of motivation, and distraction due to new feature requests.

Of course forgoing these things will bite you in the end, but this is the internet age; people don't tend to plan that far in advance.

Well they were lucky you fixed it.

There are loads of sites built year ago that just work so nobody is looking into the code base ever.