10 ms·

I hate to say it, but storing users' passwords in plaintext in your internal db/filesystem isn't that bad ... (relative to a lot of other snafus we've seen). I

• swombat 18y ago
  Don't hate to say it. It's a reality of the web that usability trumps security. And those who disagree should unplug their computer now, because it's not secure. This is really missing the forest for the trees though. If you log in via a plain text form, who cares that your password gets sent in a plain text email? There are easier ways to get people's passwords than to sniff plain text emails - phishing, for example, or social engineering, both of which are much easier to implement than an email-sniffing man-in-the-middle server.
  • jaf656s 18y ago
    the problem isn't entirely with sending a plain text password in an email. It is that the passwords are being stored in plain text in the database. This is just an SQL injection away from gaining an email-password list of all members of the site. Couple this with the fact that many people use the same password for other accounts, including email, and you have a definite security problem for the users.
    • swombat 18y ago
      How do you know they're stored in plain text in the db? I have that same functionality in my start-up, but we encrypt the passwords in the db. We just don't one-way-hash them.
      • jeremytliles 18y ago
        Exactly. It seems that about 75% of the commenters here and on CodingHorror are making this leap from "System can send password to user" to "System is storing password in clear text." Maybe Jeff's next post should be focused on how many "hackers" are unable to perform simple logical analysis. I believe the flaw here is that it sends your existing password rather than sending you an email link to create a new one. Not really worth a post (and all the ensuing discussion).
        • ajross 18y ago
          No, no, no, no. What you are describing is just obfuscation. It's the same thing web browsers do with the password list on the local machine, and it DOES NOT provide protection against theft. It just makes that theft slightly harder. If the key isn't in the database, it's in the code somewhere, probably in one or several utility script on the same box containing the database. Yeah, that's really going to slow an attacker down. Guys, this stuff was known and very well understood 30 years ago. Please, please, please stop trying to do security architecture if you don't understand it. This is the reason web security is as bad as it is. If you aren't 100% sure you understand the thread model perfectly, just follow the advice you read from trusted sources on the web. I'm not aware of anyone sane that is recommending storing unhashed/recoverable passwords.
          • swombat 18y ago
            As I said in my original post, usability trumps security. Also, it may sound defeatist, but I think that if a determined, highly skilled and competent hacker wants to fuck you up and steal the passwords, they will. Even if you salted and hashed all your passwords, there's always brute force, sniffing, etc. If they're on your servers reading your code, you're pretty screwed already.
            • jcl 18y ago
              How exactly is keeping the passwords more "usable" than keeping only hashes?
      • xirium 18y ago
        Why are you not performing a one way hash on passwords?
  • xirium 18y ago
    Sending passwords via plain text forms and plain text emails are both bad practices. However, plain text email is distinctly worse because the data can linger for months or years in less secure systems. A credit card number sent over unencrypted HTTP may only be vulnerable for a brief period. However, a credit card number sent over SSL and forwarded as a plain text email may be vulnerable until the credit card expires.
• tom 18y ago
  Yes, but you want it to be YOU that are worrying about it, not every one of your users! Yes, capitals and an exclamation point - I must really mean it. If someone gains access to your db, what do you want them to find - A: a users table with an email column and a plain text password column or B: a users table with an email column and a salted hash of gobblygook (please pardon my use of such heavy techno-jargon) instead of plain text password? I'd choose option B - email addresses just aren't as valuable as email addresses and their associated passwords.
• ojbyrne 18y ago
  I just finished building something with a nice salted hash for storing the passwords. The client complained that it was too "confusing" for him, and asked me to change it to storing the password in plaintext :-(.
  • simonw 18y ago
    If your client is confused by a salted hash, I certainly wouldn't trust them to keep their database secured.
    • ojbyrne 18y ago
      And yet a fairly large company does trust him to keep their database secured. All I can do is present the argument, and then acquiesce. That's why they call them "clients."
• ajross 18y ago
  No, you're misunderstanding the threat model. The problem with plaintext passwords isn't the danger to you, it's the danger to your users. Users reuse passwords, they just do, and you can't stop them. Storing those passwords in plaintext means that when (yes, when) your site is compromised, the attacker (an employee, for example) can get a pre-validated list of emails and passwords that they can try on other sites. I, personally, watched an ancient Western Union account of mine (no doubt created with a repeated password that I used for other services, like mailman lists, which store them in plaintext) used for fraud. Someone found another user with the same name, put their credit card on the account and stole $1000US. Just don't do this. Just don't. Don't excuse it. Don't pretend you understand why you can get away with it. JUST DON'T DO IT.
• dangoldin 18y ago
  The halfway point between salting/hashing a password and storing it as plain text would be having functions that encode/decode the password. This way you are not actually storing the actual password in the DB but just it's transformation. Although if you are gonna take this step you might as well do the salting/hashing so some rogue programmer doesn't steal your functions. The nice thing about salting/hashing is that even the guys running the site don't know what the password is.