Thanks for taking the time to clear things up; apologies for the incorrect assumption.

You are completely correct on the whole trade-off element to security, couldn’t agree with you more.

I have updated the article accordingly.

I’m the Head of Application Development at the agency responsible for the Slug and Lettuce website, and while I think you’ve written an excellent article on the subject of password security, I’d like to clear up an assumption you’ve made.

The Slug and Lettuce website does not store your password in plain text. At time of account creation, we send a one-time email with the plain-text password, as we’ve found sites that do this see a marked drop in the number of users of any “Forgotten password” facility they provide. I’m not going to share the full details of the hash we use, for obvious security reasons, but I will say that I agree with your recommendations around how to chose an hashing method.

We could go back and forth on the security pros and cons of even sending the one time email, but as any security researcher will tell you, security is a matter of trade-offs, of deciding what level on inconvenience it is reasonably to put your users to, in exchange for what level of protection, weighed against the risk that would be posed by any security breach. As an agency, we make recommendations to our clients based on these factors, and then leave the final decision about the level of security to employ up to them.

Since the site stores no particularly sensitive data, and does not therefore use SSL encryption in the registration process, we don’t feel that the one-time email represents a security risk any greater than the one posed by entering the password in the unencrypted form in the first place.

As I said, I think this is an excellent article, that many developers could learn from, but I just wanted to clear up your misconception of how the Slug and Lettuce website operates. We absolutely do not store our users passwords as plain text for exactly the sorts of reasons you’ve laid out above.

Thanks for letting me clear that up.

Another reason why you don’t want to be paid by cheque is that pretty much every UK bank I know of will charge you for paying them in to a business account (once any introductory “free banking” period is over), so yet again, online transfer wins the day.

The sooner these archaic pieces of paper are consigned to the rubbish bin of history, the better!

Obviously you have to pay for the work that has been done, that’s just the way it is. What you can do however, if you feel that the final piece is inadequete or you feel that it needs to be looked into further, is get another developer to review the work and give details on estimated time taken, level of skill, whether or not attention needs to be applied to certain areas.

That’s all I can think of really.

I enjoyed reading your post – a lot of it applies to us too. However, we occasionally sub-contract work out and on this occasion have had the misfortune of hiring somebody who is absolutely shit. As he is a sub-contractor, we are relying heavily on him to finish a project that will bag us a good relationship and further work from our client. So far, the developer has gone over the agreed timescale, required almost constant assistance from us, fails to respond to communication and is generally giving me heart palpitations from the moment I wake up in the morning until I go to bed at night. This developer is going to be sorely disappointed when he presents us with the final bill because he’s not going to get the full amount. Maybe this is wrong on my part, but as far as I’m concerned he’s just one of many “cowboy” developers out there.