How Not to Do Web Site User Registration

The Internet is FULL of real life scenarios of how NOT to do web application security...it is unfortunate when a large, popular site shows the rest of the world some form of this inappropriate behavior. Unfortunate because it becomes both a HOW-TO for programmers, marketers, decision makers to repeat as well as an illustration of what NOT to do for the infosec community to harp on - both are undesirable.

Here's a few screen shots I took while going through Account Registration on WordPress - this is a classic case study in what not to do.

While jumping through common hoops of account creation, WordPress required email address verification before activating my newly created account. After creating my account and waiting a few minutes, I was greeted with the following email requesting that I click on a link to verify that my email address did, in fact, belong to me:

The names and email addresses have been removed to protect the innocent. This is pretty standard so far, no surprises - create an account, get an email, click the activation link, activate the account, login, good to go...

But then to my surprise, I'm greeted with the following Activation web page:

This is one of the very very few times I recall being shown both my user name and password on a web site. This can only mean that WordPress is storing my password in plain-text in their database or using reversible encryption - I suspect the former - plain text...with this knowledge I then glance up at the URL. *Sigh* - http:// - no 's', meaning this was sent over the wire unencrypted for anyone paying attention as my credentials bounced from Columbus, OH up to Cincinnati, OH -back down to Atlanta, GA and then over to Dallas, TX - at first I wanted to kick myself - I should have been paying more attention to the activation email link and noticed the lack of the 's' and added it manually - but wait, why would I? I didn't expect to be shown my credentials...this is not common.

Then I notice I have new Email...WordPress has also sent me an email notifying me that I have activated my account. View it in all its glory:

Good GOD how many times do I need my credentials delivered to me over an unencrypted channel! Not to mention they managed in the email to group all information conveniently together - user name, password, AND login link...

I've seen flawed Password Reset schemes, but I think this might be the first poorly implemented Registration workflows I've run across and took notice.

Some quick tips for a more Secure User Registration:

1. Perform all operations containing credentials (user name/password) over a secure connection. E.g. SSL/TLS
2. Store passwords in the database using a one-way hash algorithm like SHA-1.
3. Additionally, salt users password when generating the hash based on something unique to the user whose account you are protecting. The salt doesn't have to a secret piece of information.
4. If passwords must be recoverable (which should be a RARE requirement) store them using accepted open encryption algorithms - e.g. AES, 3DES.
5. Never email a user their password.

Finally, I noticed that if you have my activation ID - without an authenticated session, you can go back and visit the activation page - anyone can now retrieve my email address and login name. Thankfully after the account is activated the first time, all subsequent requests do not reveal the password again, however, they do reveal my email address and user name which is completely unnecessary. Here's what you see if you visit the activation page again after already activating your account:

I'm going to add a 6th tip: There's no need to keep telling the user they have activated their account once the activation key has been used- and there's also no need to reveal the user name and email address to an unauthenticated user on the activation page - this only gives an attacker more information that they can use to reset the victim's password and gain access to the account - for instance, when an attacker finds a valid activation id they could follow it up with a spear phishing attack to easily gain that final piece of information from the victim to compromise their account.

And here comes Tip #7: Since the activation page can be revisited and because the Activate ID is in the URL, this URL will be cached not only on the local users computer browser, but in web server logs, proxy server logs, router logs, firewall logs, etc. on potentially any system from here to Texas. If the activation key was discarded after first use or did not reveal any interesting information to begin with..who cares...but this is not the case.

While these features may be a benefit to users of WordPress (which is debatable, as it was overly repetitious), these features add an unnecessary level of Risk with little gain.

Also, I'd recommend going in and changing your WordPress password after registering - and hope they don't email it to you again...they don't appear to anyway...*fingers crossed*

* Update - it's been over 16 hours and the activation link still works, revealing my user name and email - I'll be checking back to see when it actually get's removed. Additionally, I did not receive an email containing my updated credentials after I changed my password on WordPress...so the recommendation to change your password seems like a good one.

* Update 2 - Readers are reporting that WordPress does in fact hash the password, but only after mailing the plaintext one back to the user. And to clarify - many have suggested that WordPress is sending a randomly generated password. That is not the case. The password emailed to me was most certainly one of my creation.