Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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


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.


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.


Sorry, but the very fact that you're arguing that (1) "brute force" is a plausible attack against a salted, SHA-1 hashed password, or (2) "sniffing" a hashed password on the network from a HTTPS transaction (!!) are plausible attacks shows your level of misunderstanding.

Look, just read a book or two on the subject. You don't have to believe me, but please stop arguing about stuff you clearly don't understand.


You're not reading what I'm saying, either that or you're choosing to misinterpret me.

Brute force is a plausible attack against anything. No, doofus, I don't mean that you sit there and try to decrypt the SHA-1 - that's impossible. Instead, once you have the salt (which you can have easily since it's in the code which we've already surmised you have access to), you start with the dict database, and then various crack databases out there. In comparatively little time, you're likely to have cracked some 50+% of the passwords in that salted, SHA-1'ed database.

Unless, of course, the cretinously short-sighted designers of the system were so up their own arses about security that they put in all sorts of rules about what you can put in your passwords, requiring symbols, numbers, and no recognisable words, etc. In those cases, we can safely assume that the system is indeed secure - it's also secure from quite a sizeable percentage of users, who won't bother themselves with it.

2) Who said anything about HTTPS transactions? 99.9% of the logins are not HTTPS'ed. If I really want to sniff your fucking password that you use for everything, I'll sniff it from one of those other sites that don't have HTTPS login forms.

Now please stop assuming that everyone is as dumb as you and understand that there are people out there who are vastly more skilled at cracking systems than you can contemplate, and they will fuck you sideways should they really want to. And no, there's nothing you can do to protect yourself against them, other than not be online.

This should not be so surprising. It's the same offline. If someone really wants to kill you, particularly if you don't know that they do, and they're skilled enough at it, you're dead.


How exactly is keeping the passwords more "usable" than keeping only hashes?


1) When the user forgets their password, you can send it back to them instead of them having to come up with a new one again

2) When you send emails to a user who hasn't logged in for a while, you can include their details so they're that much more likely to actually log in

Not being able to do these things costs users.


i will concede that my assumption about plain text storage in a database may have been a poor assumption, but it has happened before, and popular sites have been guilty. Reversibly encrypting your passwords isn't best practice, either.


Why are you not performing a one way hash on passwords?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: