

Smart Enough Not To Build This Website - bdfh42
http://www.codinghorror.com/blog/archives/001140.html

======
jauco
from the comments:

 _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 :)

~~~
babul
...or a good marketing(/recruitment/etc) mind.

~~~
jcl
Or a good security mind:

<http://www.schneier.com/essay-210.html>

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

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

~~~
swombat
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
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
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
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
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
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.

~~~
ajross
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.

~~~
swombat
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.

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

~~~
natrius
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.

~~~
dgabriel
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_?

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

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

~~~
jraines
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?

~~~
DTrejo
Are you sure that you were happy because the people around you were
intelligent? Or was it because you were in an intellectual environment where
people discussed interesting topics?*

*free of inane comments

~~~
jraines
The latter really doesn't happen without the former, in my opinion.

------
babul
The now defunct Active Matter (who built the site, in 2003) were hopefully not
members of Mensa.

------
gruseom
One of the funniest things I ever saw: a bumper sticker that said "Mensa" and
was upside down.

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

------
aasarava
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/>

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

~~~
jonknee
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.

