"A password is a secret word or string of characters that is used for authentication, to prove identity or gain access to a resource. The password should be kept secret from those not allowed access." -- so says wikipedia.
That page actually has a useful summary of the pitfalls of passwords, but I recently had to revisit the topic in the context of accidentally internally leaked password at $WORK. As you would expect, we have a number of systems accessible to most engineers: an internal wiki (twiki/foswiki), an internal bugzilla (and other ticket tracking systems), internal concurrent version systems (including CVS and SVN) etc. etc. It will not surprise you to know that we regularly find that passwords are leaked into these systems (by accident or due to ignorance). The cleanup work required (changing the password everywhere it's used, deleting it from the various databases, updating processes to prevent leaking in the future etc.) are generally not considered particularly fun, and often the questions arise: "So what? What's the big deal? Why should I care, really?".
And I actually understand this attitude. The problem is that passwords are, in general, a pretty poor way of achieving "security" for the simple reason that their safe use is just much too inconvenient -- and convenience will win over any security concerns any time.
That is, if whatever mechanisms we come up with get in the way of people getting their jobs done, then they will find ways around them. Today, that may be people storing passwords on wiki pages or in SVN; previously it may have been the much-alluded-too-but-actually-rarely-seen post-it note on the monitor; tomorrow it will be another insecure way of "remembering" (and sharing) more and more complex passwords.
One of the reasons that many people do not think twice about "proper" handling of password is that they do not feel or see any kind of negative impact from them breaking any such "common sense" rules. For the most part, the only time this practice has a direct impact on them is if somebody finds out about it and forces them to change it (and all the hosts that had it). Since the real impact and cost of a password, passphrase or secret being compromised and actually used against us is not (directly) shouldered by those people, why would they care?
Passwords are a bad way of proving authenticity for the same reason that they're -- paradoxically -- convenient: they're easy to implement and easy to share (ie not mapped to individual people or processes). But they're also easy to break/guess, so we require so-called "strong" passwords, which make them become less convenient (and hence get in the way of security, for the most part). As a result, people don't remember them and instead write them down (in ways that make them available to others).
Tangent I: The recent xkcd comic on password strength made some good points (and was widely quoted, referred to, retweeted etc.), but does not address the underlying problem of using single-factor authentication. In addition, the systems I'm referring to here are autonomous; that is, it is software that needs to have access to authenticating credentials, so "remembering" a complex (and cryptographically strong) string is not a concern.
Tangent II: There is an important difference between authentication and decryption keys. Leaking a decryption key, as has been shown in the WikiLeaks case, has a deeper impact, so the cleanup work required is much more intense (and possibly entirely impossible).
Tangent III: I'll note that writing down passwords by itself is not this horrible, terrible thing people have been trained to believe. It is writing them down where others can see them, such as on a wiki page or in a file in SVN. Writing down a passphrase and encrypting it is perfectly fine; as is writing it down on a piece of paper that is kept in a secure location (possibly your wallet) may also be a reasonable approach for some secrets.
Alright, where was I? What we need to do is get away from the use of passwords as a single way of authorization. That is, passwords should not be a super-secret OMG-we're-screwed-if-anybody-finds-out-what-it-is kind of token, but just one factor. If knowing a password does not unlock everything, then we can find ways to share the password that are more convenient and make it easy to use. Or, even better, don't use passwords at all (where possible) and instead use other mechanisms of authorization. At Yahoo!, for example, we have a central key distribution infrastructure and API that applications can tie into.
Remember the three ways of authentication? "Something you forget", "something you lose", "something you seize to be". I mean, "something you know" (such as a passphrase), "something you have" (such as a security token) and "something you are" (such as biometrics). Using just one of these is poor security. N-factor authentication (where N>1) is where it's at, yo! Not only do you have to beat the password out of me, you also have to hack off my thumb. (You see, it all depends on the motiviation of the adversary.)
Google, for example, offers world-wide 2-step verification for end users (a very different use case from what I discussed above, it should be noted). Of course retrieving the one-time password component is much too inconvenient, so people will simply cache it (a feature that is effectively a must-have for the implementation to provide, or else nobody would use the system) for 30 days or so...
Anyway, there's another argument to be made: most organizations or engineers shouldn't have to care about security. If the tools they use are appropriately designed, they will be secure without requiring any additional thought. If it requires people to consciously think about whether or not what they're doing is "secure", then you're fighting a losing battle.
Security will always take a backseat to convenience. Consider key-based ssh authentication. With a passphrase protected key, this is two-factor authorization: it's something you know (the passphrase that unlocks the key) combined with something you have (access to the private key). Now typing in these passphrases is awfully inconvenient, so we invented ssh-agents (or used passphrase-less keys, turning this into a single-factor method of authorization). Those run on your local host and supply the credentials to ssh as needed - wonderful. That only works when you connect from you local host to the target, though, which is inconvenient. So we invented ssh-agent forwarding. And start or forward agents on/to massively shared hosts. (Check your organization's shared hosts or jumpboxes-- see how many accounts you have, how many users have sudo access and how many ssh agents are running.)
Security is really, really difficult, in part precisely because if it gets in the way of people doing what they want, people will find ways around it -- and not because they are malicious, dumb, or indifferent (as we like to portray them as). Security problems are frequently best addressed not in contrast to expediency and convenience, but as an enabling factor. We should not ask "how can I make this secure and not take away too many options", but rather "how can I build this so that all options are secure".
Secure by Default does not have to fight usability.
September 12, 2011