DO NOT STORE PASSWORDS IN PLAIN TEXT

DO NOT STORE PASSWORDS IN PLAIN TEXT

DO NOT STORE PASSWORDS IN PLAIN TEXT

DO NOT STORE PASSWORDS IN PLAIN TEXT

Obviously, this still needs to be said. Every modern database has an encrypt function that you can build right into the SQL string.

Reddit did it. There's a valid user happiness story to tell there, when you can actually give a person back the password they were using.

What you really mean is, don't insert user-submitted content into SQL queries. And in reddit's case, don't keep user data on local storage.

I hate when websites store my password. It's quite irksome when, if you forget your password, they send it to you plain, in an email, instead of just sending you a reset link. When I get these emails, I know they are storing my password, and in all likelihood, they are storing it in plain text. The worst offense was when I once ordered some business cards: Packed in with my shipment was an invoice with my password on it. Huh?

We never know our users' passwords. There's a brief moment, during registration, when we technically have their password, but it is immediately thrown away after we store the hash of it in the DB.

>to figure out what users want.

Most of them prefer secure systems.

That's a meaningless statement. Are you implying there is a definite line between secure and insecure systems? That's false. Are you saying that given a choice between a security feature and a convenience feature, most users will choose the security one? That's false too. Are you saying that if you ask a user, "do you prefer secure or insecure systems?", he'll say "secure"? That's true, but irrelevant. There are a dozen more ways that could be interpreted.

I'm saying that if you gave the option to users about whether they would like the site to store their passwords in plain text or encrypted, most would choose the latter.

The argument that "we can give the the same password" is bunk. You don't even know if that's the user you're giving the password to!

The password could be reset and the user could change it back to the one they were using previously. Clearly, if they've forgotten it, I'm not sure why you figure it's so important for the password to stay the same.

And if you gave the option to users of being able to retrieve their old password or have a new one generated, most would choose the former. And if you explained the drawbacks and advantages of each approach and made the user make an informed decision, most users would just click the Back button.

>And if you gave the option to users of being able to retrieve their old password or have a new one generated, most would choose the former

Do you have any evidence at all to support that?

No, i don't have any evidence, other than anecdotal. It's what I would prefer, because changing the password from random to something that I might remember is an extra step, and an unnecessary one unless security really matters (e.g. money is involved). I took it as given that people prefer less work over more work.

>Reddit did it.

Yeah, exactly, and created a massive privacy breach for themselves and more importantly their users when they were exposed.

Storing plain text passwords is a symptom of bad programming, end of story.

It has nothing to do with programming. It's a design choice that has only a few downfalls which basically coincide with huge security problems.

If a user has the ability to run a query on your DB, I doubt the dangerous one is to log in as a user... Same goes with swiping your laptop.

>It's a design choice that has only a few downfalls

One of those downfalls is exposing your user to a host of vulnerabilities should one of those other "security problems" happen.

Why would you figure that the user is only using your DB? Websites are plentiful, and the "typical" user has one password for many sites. If they don't, they're hardly attached to the current one - they forgot it after all! It's understanding that your app doesn't exist in a bubble and looking out for the best interests of your users that leads to storing passwords in a hash. When you have "design decisions" that put marginal convenience over security, I honestly question the integrity of you as the owner operator.

Why exactly do you need to see my password anyway?

I think retrieving a password is more than a marginal convenience for some audiences. And again, off all the things in a database you don't want the world to see or manipulate, a user's password is pretty low down on the list.

No matter what, as the operator of a website, you'll need to make your own decisions about the various tradeoffs involved.

edit: If, as you asserted, a user forgetting a password means that they're not attached to it, that's all the more reason to keep it around, since they aren't using it elsewhere. I don't think it's unreasonable to assume that people won't break in and see the database (short of you screwing something more important up).

>off all the things in a database you don't want the world to see or manipulate, a user's password is pretty low down on the list.

Clearly, we disagree philosophically on this point. I just hope my bank never starts thinking like that.

If I were your bank, I wouldn't even be relying on passwords alone. Like I said, per application decision-making is the only 'right' approach here.