Smart Enough Not To Build This Website(codinghorror.com)
codinghorror.com
Smart Enough Not To Build This Website
http://www.codinghorror.com/blog/archives/001140.html
42 comments
The vast majority of web sites that allow sign ups will prevent you from joining with an existing email address.
Almost none of them limit the number of times you can try to sign up. Obviously from a security perspective it's probably a good idea to limit this. In practice though, who's really been bitten by this problem?
The search space for valid email addresses is super large. There are much easier ways to get lists of valid email addresses. The most useful thing you could learn (I think) is that an email address you already know is in their database. But, that would be possible even if you were limited to a small number of attempts.
Almost none of them limit the number of times you can try to sign up. Obviously from a security perspective it's probably a good idea to limit this. In practice though, who's really been bitten by this problem?
The search space for valid email addresses is super large. There are much easier ways to get lists of valid email addresses. The most useful thing you could learn (I think) is that an email address you already know is in their database. But, that would be possible even if you were limited to a small number of attempts.
...or a good marketing(/recruitment/etc) mind.
[deleted]
Or a good security mind:
http://www.schneier.com/essay-210.html
http://www.schneier.com/essay-210.html
Old timers remember the exact same issue with reddit.com, only they went the extra distance and had their servers stolen with passwords on them.
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'll of course grant that it is a far from ideal state of affairs and should be fixed. But, I think we can pretty safely assume that if an attacker has unfettered access to your server, you have bigger things to worry about.
I'll of course grant that it is a far from ideal state of affairs and should be fixed. But, I think we can pretty safely assume that if an attacker has unfettered access to your server, you have bigger things to worry about.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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?
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 :-(.
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.
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.
Does mensa store sensitive user data (financial info/ssn/naked pictures), or is it like most sites that store maybe customization options, possibly a calendar, possibly grant access to a forum? Unless there's sensitive data, it doesn't seem all that incredibly stupid to me. Am I missing something?
Of course, I would prefer to generate my own password, rather than using one created for me.
Of course, I would prefer to generate my own password, rather than using one created for me.
It doesn't matter how sensitive the data you're storing is. It matters how many other sites your users have used the same password on, and what those sites have stored on them. If salting and hashing passwords is all you need to do to help protect your users from their bad security decisions, I don't see why anyone wouldn't do it.
It doesn't really apply here, because the user obviously has an assigned password. Users are quite unlikely to change their other passwords to match their mensa-assigned password.
However, it's an interesting point, and possibly deserves debate. How responsible am I for ensuring a user's security on other sites? Should all password fields be flanked by a flashing message that reads something like: Do not use your online banking password here?
However, it's an interesting point, and possibly deserves debate. How responsible am I for ensuring a user's security on other sites? Should all password fields be flanked by a flashing message that reads something like: Do not use your online banking password here?
I realize it's a colloquialism and not to be taken too literally, but I don't care for the premise of Jeff's opening line:
I may not be smart enough to join Mensa, but I am smart enough not to build websites like the American Mensa website.
It implies that smartness is a single continuum (maybe, maybe not), and that you can measure it by looking at single actions like whether someone implements security feature X in a web site.
My feeling about something like this is that most people who get it right are probably people who have heard or read about the issues regarding plaintext passwords. That makes them more knowledgeable, which is a fine thing if you are hiring them to build a web application, but not the same thing as smart in this sense.
True, some people can work out the issues from first principles, which is definitely evidence of smartness, but I have strong doubts that you can get an accurate measure of smartness from just one "test" like this.
Overall, it would be a far better "zinger" if it were a security web site with a security flaw, something like the story of the identity protection company whose CEO had his identity stolen.
All that being said, I still upmodded the story. Blogging this kind of thing is a public service and a reminder for hackers doing start-ups can't hurt.
It would be terrible if you built a great service, were just about to raise a substantial round, and some know-it-all technoid working with the VC flipped your bozo bit because you stored passwords in plain text.
I may not be smart enough to join Mensa, but I am smart enough not to build websites like the American Mensa website.
It implies that smartness is a single continuum (maybe, maybe not), and that you can measure it by looking at single actions like whether someone implements security feature X in a web site.
My feeling about something like this is that most people who get it right are probably people who have heard or read about the issues regarding plaintext passwords. That makes them more knowledgeable, which is a fine thing if you are hiring them to build a web application, but not the same thing as smart in this sense.
True, some people can work out the issues from first principles, which is definitely evidence of smartness, but I have strong doubts that you can get an accurate measure of smartness from just one "test" like this.
Overall, it would be a far better "zinger" if it were a security web site with a security flaw, something like the story of the identity protection company whose CEO had his identity stolen.
All that being said, I still upmodded the story. Blogging this kind of thing is a public service and a reminder for hackers doing start-ups can't hurt.
It would be terrible if you built a great service, were just about to raise a substantial round, and some know-it-all technoid working with the VC flipped your bozo bit because you stored passwords in plain text.
The idea behind mensa is that people with high IQ's need to associate with their own kind to feel comfortable. This is elitist crap. People who are truly intelligent are able to effectively communicate with the largest variety of people. In fact I would define that as a dimension of intelligence.
Well, you can call me an elitist (though I've never been a member of or interested in Mensa), but I don't think this is crap. Happiest times of my life were when I was among high concentrations of intelligent people on a daily basis.
The very existence of this community is evidence against your point. Or are all the truly intelligent people out there happily communicating with YouTube commenters?
The very existence of this community is evidence against your point. Or are all the truly intelligent people out there happily communicating with YouTube commenters?
I once had a girlfriend who had joined Mensa to meet "smart guys". She said all she ever met were geeks and ADD freaks. Then she ended up with me. </irony>
The now defunct Active Matter (who built the site, in 2003) were hopefully not members of Mensa.
One of the funniest things I ever saw: a bumper sticker that said "Mensa" and was upside down.
Without looking at the answer, I couldn't figure out what the problem with the site was. Could it be that the password is sent to the email? No, that's probably just how they worded the command button. Of course they'd hash a new password and send that to my email. And Atwood wouldn't repeat himself yet again, would he? After a few minutes, I finally guessed: the feature is much too wordy. The entire paragraph under the text field is completely unnecessary. I guess I would want to avoid websites that make this mistake because I don't like poor design and pointless text. Apparently I have more of a mind for design than security.
By the way, the comment from Aaron G on the original article is right on: Don't think you've got better security than Mensa if you're using MD5 to hash your users' password -- you should be using something along the lines of bcrypt.
http://openwall.com/phpass/
http://openwall.com/phpass/
The vast majority of web sites have this privacy/security flaw in their password recovery systems: they respond by saying if they have the email address or not in the database, which means, anyone can check out if you are a member of a service or not by trying out your email.
I've done it both ways and the customer service reps much prefer when it lets you know if the email was sent or not. Otherwise they get lots of calls from unhappy people who put in their old email address and didn't get their login info. It's a usability trade off.
I think a good compromise is limiting to a few attempts within a time period. That way you won't get a dictionary attack, but if someone has to try a few email addresses they can.
I think a good compromise is limiting to a few attempts within a time period. That way you won't get a dictionary attack, but if someone has to try a few email addresses they can.
The plaintext passwords are bad enough, but I think the biggest WTF here is that they give you the "Sorry, we don't recognize that email address." error if you enter an address not in their database.
I hit it about 20 times and it doesn't lock you out or add a delay. It would be trivial to write something to datamine valid addresses. Seems like a valuable mailing list to build!
Now that's a criminal mind :)