There seems to be a lot of confusion outside the core computer security community about what the goals and methods of computer and network trust and security are. This blog entry is a non-professional's attempt to solve some of these problems. It is inevitably going to be incomplete, since I'm busy, and contain mistakes, since this isn't my top specialization. Suggestions for improvement are appreciated...
The most basic function of computer security is access control. This is a bit of a misnomer, actually, since what is really being controlled is whether a given entity has permission to execute a given action on a system, be that reading data, writing data, printing documents, executing arbitrary code, shutting down the system, etc. We will call the person requesting access the supplicant, and the system that has the power to grant permission the trusting party. This casts the permission problem in the proper light; it is really a trust problem. The trusting party has to decide whether to grant permission to achieve the given action based on whether it trusts the supplicant. The set of rules used by the trusting party in making this decision is the trust policy; the trust policy determines how evidence of trust is to be weighted and combined to achieve an overall trust metric. Writing good trust policies is hard, especially since many times the available evidence is poor.
There are a multitude of ways that a supplicant can gain the trust of a trusting party. The ones getting the most attention these days are identity and reputation.
The classic trust policy is one where only specific parties that are identified as trusted are allowed to execute actions. This identity-based trust policy is simple to write and administer, as long as it involves only small numbers of supplicants and simple actions. In the most common case, the action allowed is to "log into" a trusting machine. To do so, one establishes the supplicant's identity through an authenticator, most commonly a password.
The problems with passwords as an authenticator are manifold and well-known. Human memory is unreliable; remembering a password of sufficient length to be secure against a guessing attack is impossible for many people. Attempts to improve recall by allowing humans to select a mnemonic password can improve the length of the password remembered, but may or may not decrease its guessability. The password is a reusable authentication shared secret. Any time the secrecy of the password is compromised by either the supplicant or the trusting host, the ability to properly authenticate is lost. Because the password is reused, opportunities to compromise its secrecy are frequent. In particular, if the supplicant fails to properly authenticate the host, the supplicant may be sending the password to an unauthorized third party. Thus, passwords induce a two-way authentication problem.
Beyond password-specific problems, the use of identity as a source of trust has its own general problems. As the number of trusted supplicants and the number of actions to be controlled grows, the trusting host can encounter serious data management problems. Access-control lists are a known source of confusion and thus mis-specification of desired trust relationships. On the other side of the coin, there are situations in which a host needs to trust a supplicant whose identity is unknown or cannot be authenticated. While password-authenticated identities are the state of the art for trust today, there is considerable movement beyond this simplified paradigm.