It seems most security mechanisms nowadays default to a username + password combination for authorization. I want to know why there are 2 "keys," if you will. Won't one credential suffice?
Put differently, why can't I (or don't I) run a login form on a site using just one field, the secret password?
Let a server which only requires a password for opening a session; no username. Let's imagine that user 'Alice' has registered, with password 'ILoveBillClinton'.
Now, a new user wants to register; let's call him Bob. Out of (bad) luck, Bob elects to use password 'ILoveBillClinton' too. Such collisions happen in practice; indeed, even if users choose passwords with 30 bits of entropy (an already optimistic figure), it suffices to have 30 thousands or so users to have a good chance of triggering such a collision (this is called the Birthday Paradox).
The registration server then has three ways to handle this situation:
The server warns Bob about the collision. Bob then immediately learns that there is another user with the same password, and since the server does not require the username, just the password, Bob gains immediate access to Alice's account.
The server does not warn Bob about the collision, but just ignores the registration. When Bob actually connects, he has the surprise of being greeted with a banner stating "Hello, Alice !". Bob has gained immediate access to Alice's account.
The server does not warn Bob about the collision, and replaces Alice's registration with Bob's registration. Bob has his own account, alright. But when Alice logs on again, she types her password, and is greeted with "Hello, Bob !". Alice has gained immediate access to Bob's account.
None of these methods is satisfying.
The entry of the username would not be necessary if password collisions did not happen (or would happen only with negligible probability). But as long as passwords are chosen by human minds and stored in human brains, collisions will happen, and a username (or user ID or any similar discriminant value) will be needed.
Edit: as @mikeazo alludes to, if the passwords are not chosen by the user, but generated by the registration server, then the server can enforce uniqueness and avoid this problem. However, in practice, human users do not like machine-generated passwords.
Also, lack of username prevents user-specific salting, which is a problem for password storage, as long as passwords are of sufficiently low entropy to be exhaustively scanned (see this answer for details on how password should be hashed, including salting). This happens even if the passwords are server-chosen (with enforced uniqueness). Unless you can convince your users to remember long and random passwords which they did not choose...
It would seem for logon credentials to be effective they must be unique and secret. Thus if you view the tuple (username, password) as a logon credential, the username is the unique part and the password is the secret part.
Changing this to simply (password), you lose the uniqueness unless it is enforced during registration. If that is the case though, when you deny someone entrance saying that their password is not unique, you have now told them that they can use that password to log in to the system as someone else.
The probability of this happening depends on how passwords are chosen. If, for example, when a user registered, you generated a random 80 character password for them, the chance of collision is very small. On the other hand, if you let them choose their password, the chance of collision is very high. Thus we tend to instead satisfy the uniqueness requirement with some public information (e.g., username or email address) and let the password be chosen by the user.
Usernames are for identity.
A password or other type of factor are used to authenticate an identity.
They serve different purposes. You may want to change a password used to validate your identity, but would you want to also change your username each time you needed to change your password? At the same time, you may want to change you identity but use the same information to validate your new identity.
In some cases, a long cryptic string may be sufficient to identify you without worrying about authenticating the identity as well. If there are low confidentiality requirements or in other special cases such as password resets, the risk of the long random identifier being guessed are low or the probability of guessing it in a sufficient period of time is low.
Another ragion is that a hacker would have a lot of probability to enter into an account! Because with the username and password the hacker must finding the correct combination [username]+[password], else if there is only the password, the hacker could try to enter random password into the login page without the username restriction.
Your name is your Identification. Identification is generally public (or at least easy to discover). Frequently your identification is your email address, which is very easy to discover. Your identification is an assertion that your meatbody matches a digital profile that the website has stored.
Your password is your authentication. Authentication by password relies on a secret value known only to you (and loosely speaking to the website).
If the site used only your ID, then )ANYONE( who knew your email address could log into your bank account, your gmail account, your stackexchange account, your tax return, etc.
If the site used only your authentication secret, it would be very difficult to keep the secret. Moreover if you and I both chose the same password, we'd have the same profile. Any hacker running a list of dictionary terms would almost be guaranteed to get into some acccount. And the fact that people find passwords difficult to manage almost guarantees that people would choose the same password. (statistics show that there is a high concentration).
For more information check NIST's 800-63
