Smart Enough Not To Build This Website
codinghorror.com
codinghorror.com
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 :)
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
Of course, I would prefer to generate my own password, rather than using one created for me.
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 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 very existence of this community is evidence against your point. Or are all the truly intelligent people out there happily communicating with YouTube commenters?
*free of inane comments
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.