A nice list of rules, but what really makes software hard is when the rules end up being contridictory.

For example, for security reasons (rule #3), I never want to see a plaintext password in a database. Instead, I use SHA1 hashes with salt. The problem is that users forget their passwords, and when they come to ask us, we have no way of getting the orginal (thus breaking usability, rule #4). We have to set the password to something else and give them that. IMnHO, this is perfectly reasonable, and the random password we give them is probably more secure than whatever they were using before (their dog's name, favorite food, etc.). As far as I'm concerned, users who don't like this are themselves a security hole. Management doesn't agree, so now it's plaintext passwords everywhere.

As a side (and off-topic) note, I'm convicinced that password authentication is a failure. I read a book by a conviced cracker written about 15 years ago (sorry, I don't remember the name, but I do remember that it was (ironicially enough) published by the Microsoft Press). He said the biggest security hole is your own users, and highly emphisized the need to train your people, especially with regards to passwords. If we haven't succeeded in doing this by now, I don't think we ever will.

Unfortunately, password authentication is often the only practical option at this point.