
How Not to Do Web Site User Registration - vollmond
http://appsecstreetfighter.com/2009/05/23/how-not-to-do-web-site-user-registrationndl/
======
jellicle
Sigh. Everyone has an opinion about website registration and password storage,
and most of them have never actually administered a large website.

Was your original signup https? No? Then the hypothetical attacker who is
reading all the traffic on your connection already has your password. Would
you happily login to your account from the WiFi at Starbucks, or from the
public machine at the local library? Yes? Then the hypothetical attacker
already has your password.

Emailing passwords to new users is USEFUL. It undoubtedly saves Wordpress
hundreds of support requests PER DAY. That is real money saved, and it must be
balanced against the insignificant risk of being "hacked" by someone reading
your email on the wire.

ANY ability to reset a password via email is insecure. The email is plaintext;
it must contain enough information for the recipient to get into his account;
therefore, an attacker on the wire can get into the account. It doesn't matter
how the password is stored or how the password reset is accomplished, it's
equally insecure. There is NO SECURITY DOWNSIDE to emailing a user's password
to them vs. having some multi-step reset procedure.

An attacker which can read out the passwords from your database already owns
your site.

Finally, complaining about the activation key (which is a hexidecimal hash
value) is insane. It's far more secure than any other passwords on the site at
all.

Finally finally, I think Wordpress does store passwords as one-way hashes, so
most of this guy's argument is moot anyway.

~~~
jmillikin
> Was your original signup https? No? Then [...]

Sounds like a good reason to use HTTPS for registration and authentication, as
stated in the article.

> Would you happily login to your account from the WiFi at Starbucks

Sure, as long as the site uses HTTPS.

> or from the public machine at the local library?

Never, never, never.

> Emailing passwords to new users is USEFUL [...]

Allowing anybody to login without a password would doubtless save them even
more support requests, but that doesn't mean it's a good idea. Sometimes the
developer's responsibility to protect a user's information outweighs a desire
for lower support costs.

> ANY ability to reset a password via email is insecure. [...]

Not so; additional information, such as user-defined security questions or
verification, is usually required before a user is allowed to reset their
password. Furthermore, a theoretical weak reset procedure only exposes the
weak site. It doesn't expose the user's password.

> An attacker which can read out the passwords from your database already owns
> your site.

This isn't about protecting _your_ site, it's about protecting _users_. Many
people, despite decades of warnings, use the same password on multiple sites.
If your site stores the user's authentication information in a way that can be
accessed later, then you are violating the user's security.

~~~
buugs
>Sure, as long as the site uses HTTPS.

You really should think again about your logins especially if you are near a
college campus and especially if you aren't using firefox (which will pop up
with a warning on an https site when you are tunneled through someone else's
computer).

~~~
jmillikin
Are there truly any major browsers that won't display an error page on bad
(spoofed, self-signed, invalid, etc) certificates? A cursory Google search
suggests that at least FF, IE, Chrome, and Opera will refuse to load such a
page unless the user clicks through.

Unless the attacker obtains the private key for a root certificate, HTTPS
remains secure no matter what location it's used from.

------
pj
I think it is okay to email the user a new randomly generated password.
There's not much difference between that and a link the user can click to
create a new password. I suggest not putting the username and the password in
the same email -- ever -- even if it is randomly generated.

It actually may be better to send a random new password, rather than a link,
because then the hacker needs to at least guess something, in this case, the
username, so it may be more secure.

For added security, you can make the random password (or the link if you want
to do it that way) expire so the user has to be a bit prepared. That reduces
the window for someone reading their emails to jump in and steal the account.

~~~
jonknee
Except that if you email a new password anyone can reset someone's password by
only knowing the email. It can be a real pain. Imagine being on the customer
support side when an unknown third party keeps resetting someone's password.

~~~
sounddust
You don't reset the user's password when he/she requests it via a web form.
You send the user an e-mail with a cryptographically secure token (rather, a
URL containing the token) that allows them to reset their password. You keep a
table of valid tokens and expire them regularly. That will serve the same
purpose without causing an inconvenience to the user.

~~~
jonknee
Some people do reset the password when requested via a web form though, that's
what I was replying to. For my own projects I do what you suggested.

------
theBobMcCormick
There's no two ways about it. If you _don't_ take reasonable care with your
users sensitive data, especially things like passwords, security questions,
credit card information, etc. then you are an _completely incompetent
unprofessional hack_ and also a creep, a jerk, and a generally miserable
person to boot.

That means you don't store passwords in an unhashed format (plaintext or
encrypted). You don't store credit cards _at all_ unless you've can't find any
other design options. And if you _do_ store them, you take great pains to meet
or exceed reasonable standards (like PCI) for storing them safely and
properly.

This is vastly more important than what language or framework you use. Vastly
more important than whether you use CCS or tables. Vastly more important than
whether you use a SQL database or a hip new RESTFUL key-value store.

This is about trust. This is about integrity. This is about professionalism.
Are you trustworthy? Are you a professional? Then do the right thing damn it!

------
run4yourlives
For reference I give you: Reddit and their password losing debacle.
([http://blog.moertel.com/articles/2006/12/15/never-store-
pass...](http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-
a-database))

------
aditya
Honestly, this is a classic usability vs security question. All the other
suggestions (other than the over the top I'm flipping out because this is so
insecure stuff) are ok, except for #5.

Are you seriously telling me that there are hackers out there waiting to break
into a blog that you might never edit? No. But, if you do forget your
password, and they sent it to you in an email you can go back and look for it.
Most people do.

Web app security is a big deal, but not if what you're securing isn't worth
the usability hit.

EDIT: I wasn't talking about storing plain-text passwords in the db, but more
about sending it via email to the user before you encrypt it and store it in
the db.

~~~
pj
In this example, it was "just a blog" but there are serious sites that will
email you your plain text password too. Verio stores two way encrypted
passwords and domains are important to some people and they do get stolen and
they are valuable, so this is a serious issue.

Security is very difficult. You can't treat it glibly. Your users deserve more
respect than that.

~~~
aditya
Sure, anything that has sensitive information about you needs to treat
security as a priority.

Most web apps (other than banks and people that store credit card data (not
process)) are probably fine. right?

~~~
pj
aditya, from a developer perspective, I cannot think of any reason to ever
store recoverable passwords in a database. It's just too easy to do a one way
hash.

Okay, there is only one reason, if you are building a system that allows the
storage of multiple accounts and passwords that are "re-used" like in some
browsers' auto-complete feature. Then the concern is security of the local
machine and if you use that technology, you're increasing your personal risk.

In the scenario I mention there, it is absolutely imperative to use an
advanced two-way encryption algorithm. In that case, the hacker will need to
compromise the database and the code, which should be obfuscated as well so
the decryption keys are more difficult to discover.

There are some hackers who will always be able to hack you and some that will
never be able to hack you. It's a probability game and you want to reduce the
probability as much as possible that anyone will get in...

~~~
democracy
Really?

I have a dozen of reasons to have the passwords recoverable - when the angry
big customer is having problems with the application and you need to access
his account to reproduce the issue being on a level 4 support, you really want
to have the password straight away, and there are many other scenarios, like
when you need to test something on a production server with some real data but
cannot get access to any accounts as it takes years in a big corp to have
something done.

So from a developers perspective - as opposed to business/marketing side - i
cannot think of any reason to ever store unrecoverable passwords in a
database. Makes it easier to implement, easier to restore, easier to maintain,
easier to test.

------
trickjarrett
I highly doubt Wordpress.com is storing the passwords in a reversible
encryption, or in plain text. It seems to me that when the user hits that
page, the password is generated and displayed.

Yes it should be https at the least, but aren't you going to go in and change
the password immediately anyways?

~~~
pj
If you look at the actual WP create account page here:
<http://en.wordpress.com/signup/>

You'll see that there is a box for your password and a confirmation of the
password, so that leads me to believe that they are actually sending the user
the password they created the account with, rather than a randomly generated
one. Otherwise, why have the input fields there at all?

Therefore, they must be storing either plain text or two-way encryption.

~~~
TallGuyShort
Which also suggests that these are passwords that most users use for other
online accounts...

------
guns
as pointed out in the article comments:

site:en.wordpress.com "your account is now active"

------
democracy
The whole thing reminds me of that old joke when you encrypt/cypher/code the
beast, but the user will still put it on sticknote on his monitor.

------
snorkel
Am I only one not too concerned about the Chinese hackers stealing my
WordPress support forums password then posting WordPress support questions
using my login credentials? It's almost a nuisance that a support forum
requires you to create a user account at all!

------
robryan
Wordpress defiantly encrypt there passwords in some unreversable format using
a salt.

I don't think SSL is really necessary for a community site like the wordpress
one.

~~~
icey
Ugh. I wish there was some kind of voting undo. (I accidentally upvoted you.)

First: I assume you mean that Wordpress _definitely_ encrypts their passwords,
not defiantly.

Second: What is your proof they they are hashing passwords, salted or not?

~~~
diego
From the source code of Wordpress MU:

    
    
       // If the stored hash is longer than an MD5, presume the
            // new style phpass portable hash.
            if ( empty($wp_hasher) ) {
                    require_once( ABSPATH . 'wp-includes/class-phpass.php');
                    // By default, use the portable hash from phpass
                    $wp_hasher = new PasswordHash(8, TRUE);
            }

