james mckay dot net

I’ve noticed recently that some websites have a very elegant solution to the problem of login recovery. If you forget your password, rather than sending you an e-mail with either your existing password or a new one, they send you a link that you can click on, which takes you straight to a page that logs you in automatically and allows you to choose a new password.

This works particularly well because it fixes the problems of both the “password reset” and “password reminder” approaches. Password reminders are bad because they require you to store the users’ passwords in plain text in the database, but password resets are also bad because they are completely user-unfriendly.

Not long ago we deployed a website for a client that used the ASP.NET membership provider for authentication and generating passwords. Unfortunately, we had to change it, because the ASP.NET membership provider generates seriously ugly passwords that look like “aFi$#3-Il1=+2x\{zZ14^” or something, prompting at least one user to send in an e-mail that said this:

I tried starting again from scratch and this time I was assigned a 21-character (!) password - the sort of thing you would expect to use if you were trying to get into Fort Knox … I find your site definitely “user-unfriendly”. What can I do?

This is why some teams settle for password reminders, even though they may be aware of the security risks. It’s also one thing that I dislike about the ASP.NET membership provider.

The login link approach gives you the best of both worlds and offers additional advantages on top of each. It bypasses both the login page and the process of navigating to the page that lets you change your password (which many users find confusing), making it much more user friendly than either. Certainly you won’t be asking your users to faff about copying and pasting “aFi$#3-Il1=+2x\{zZ14^” from their e-mail client to the login page. Furthermore, because your password is not reset until you actually change it, your old one will continue to work if you manage to dig it out in the meantime. And from a security point of view, you can still store passwords as a salted hash in the database.

Comments (2) »

Posted at 14:00 in Security

How does your website handle users who have forgotten their password?

Chances are, you ask for their e-mail address, look them up, extract their password from the database, and e-mail it to them. Nice and simple, and convenient for the end user, and easy to program.

Unfortunately, it is seriously and dangerously flawed.

Almost everyone re-uses login details across multiple web sites. It simply is not realistic to expect them to do otherwise. As a result, if an attacker manages to compromise your user database, they will be able to impersonate your users on potentially thousands of websites, including some that store their credit card details.

Never think you are immune to this. It happened to Reddit, a popular user-generated news site similar to Digg, and it can happen to you. It is very difficult to be 100% sure that your database will never fall into the wrong hands: unless you have enterprise-level security staff, infrastructure, procedures and budget, every single person involved with your data will be a weak link in the chain, from the developers to the DBAs to the dodgy geezer who comes in as a contractor to do the building’s networking. Do you know where all the copies of your data are — even the partial, out of date ones that your developers use for testing? Are you sure there aren’t any hanging around on backup CDs, USB key disks, laptops, or old PCs that you are throwing out?

No, you should never store your users’ passwords directly in a database. Instead, you must use a salted hash: a one-way encryption algorithm which makes it impossible — or at the very least, computationally very expensive and impractical — to reverse engineer them into the original password.

Unfortunately, this means that you can’t send password reminders to your users. Instead, you have to send them a single-use link to a page where they can reset their passwords on confirmation of their e-mail address. Because of this, some people prefer to sacrifice security in favour of convenience here. In fact, if the comments that were left on Jeff Atwood’s blog when he wrote about this subject are anything to go by, sometimes this design decision is imposed on developers, against their recommendations, by their managers.

I think that Mats Helander comes up with the best response to this, when he says that it should be illegal to store passwords in a database in plain text:

Many comments on Jeff [Atwood]’s blog lamented the fact that sometimes your boss will decide for you that passwords should be stored in plaintext (or two-way encrypted using a secret key, which the hacker will of course be able to obtain as readily as your password list, meaning it’s as good as plaintext). One often suggested reason would be a requirement that the system must be able to mail back a user’s forgotten password.

In my opinion, this is one of the very rare cases where I think the law should get involved, protecting the developer from having to compromise my security in order to keep his job. The developer should be able to say “No boss, that would be against the law”.

I couldn’t agree more. Really, the extra complexity introduced by the “reset password” option is very minor, and given the potential consequences of losing your data to an attacker, seriously compromising my security in favour of convenience in this way is inexcusably reckless, especially in a day and age when identity theft is a serious and growing problem.

Comment on this »

Posted at 00:55 in Security

Automattic releases the WordPress Stats 1.1 plugin, and the next day, it is found to have a SQL injection vulnerability.

Fortunately, the vulnerability has been fixed, but it is this kind of bug that I was talking about earlier today. With a solid, well thought out database access architecture using parametrised queries, SQL injection vulnerabilities like this could be all but eliminated.

If the WordPress guys don’t change their tune about GoPHP5 sometime soon and come up with a firm action plan to rework their application architecture to use PDO and nail these things on the head, I’m looking for another blog engine.

(Updated: added link to the fix)

Comment on this »

Posted at 20:03 in Security

I’ve been thinking a bit more about what to do with my blog. More from a technical perspective than anything else, mind you — I have been wondering a bit whether WordPress is the best solution to use for it, and if not, what I should be using instead.

WordPress is very popular and very fully featured, but it has a poor reputation when it comes to security. Stefan Esser, of “Month of PHP Bugs” fame, is particularly critical — a week or so back he gave an interview on BlogSecurity.net about the problems with WordPress, citing architectural problems that make it difficult to write secure code.

I must admit that while there is a lot that WordPress does very well — it is a very full featured application, supported by a lively community — I find its codebase pretty tacky. Some of it isn’t too bad, but the admin section in particular is a right unholy mess, with HTML, PHP code and SQL statements bundled together haphazardly in a monstrous plate of gone wrong spaghetti bolognese on the loo.

Matt Mullenweg is pretty defensive about WordPress security, however. In a blog entry about a month ago, he made the point that (a) all software has bugs and security vulnerabilities, which is true, and (b) that the WordPress developers do a great job of tracking down and fixing bugs and security holes before releasing a new version, which is also true. However, he did not address the point that the overall architecture of WordPress makes the process of tracking down and eliminating bugs — and keeping out whole classes of certain bugs in the first place — unnecessarily difficult.

The fact that Mullenweg has stated his opposition to the long overdue GoPHP5 initiative and the end of life of PHP 4 is also far from reassuring. PHP 4 may still be amazingly popular, but it has some serious shortcomings as a language which make it much more difficult to write robust, secure and easily maintainable code — shortcomings which were addressed in version 5. It has no support for parametrised queries, for instance, forcing developers to adopt the dangerously insecure practice of concatenating SQL code and user input to construct database queries. In an attempt to protect against SQL injection attacks, PHP offers magic quotes — an ugly, naive, broken and widely criticised hack that causes more problems than it solves and doesn’t always work.

What makes this more serious is that these days, writing WordPress plugins and themes is for many people the introduction to the world of software development, and while it does need to be kept simple so that newbies can learn and participate to some extent, it also needs to show the way in terms of good programming practices and robust code, and when you are using a language that limits your ability to do so, it is not good.

So how could WordPress improve in this respect?

First of all, the WordPress core team needs to take PHP 5.2 seriously and sign up to GoPHP5. The new features of PHP 5 are not merely luxuries; they do make it much easier to adopt good programming practices and write robust, easily maintainable code. It would not make it more secure overnight, but it would make it considerably easier to evolve it towards a better, more secure, more robust and more easily maintainable architecture.

Secondly, it needs as complete a suite of unit tests and integration tests as possible. I know that there are moves afoot to add unit testing to some particularly error-prone parts of the application, but the automated tests need to go beyond this and cover as much of the code as is possible. These would not only increase confidence in the code quality dramatically, they would also make it a lot easier to track down and fix bugs that creep in during development. Automated unit and integration testing seems much less common in PHP open source projects than in their counterparts in .NET or Java, and if WordPress takes a solid lead in this respect, it will be a smart move and bring them kudos among serious developers.

This would, however, necessitate some fairly fundamental architectural changes. It is much more difficult to write meaningful unit tests for an application with a monolithic structure where HTML, PHP and SQL code are all wrapped into one than for an application that adopts a three-tier or Model-View-Controller approach. This does not have to be done all at once, and it does not have to become fully object oriented, but WordPress does need to move towards a more structured approach with a better separation of concerns between database access, network communications (such as e-mail and pings), business logic and the UI.

Finally, the upgrade process needs to be made as simple as possible for the end user. I wrote a while back about how we have moved to a scripted, single step process for one of our major projects, which makes the process of applying changes a doddle. WordPress needs to do something similar. It can be, and should be, as simple as pressing a button on your dashboard. Novice users certainly should not need to bother with making backups, FTPing some parts of the application and not others, and so on — it is an error-prone process that can be so daunting for inexperienced users that there are still a lot of blogs out there running WordPress 1.5, wide open to attack.

Comment on this »

Posted at 12:30 in Security