Why do use webApps userID + password instead of a password only?

Question

Just out of curiosity, I wonder why web apps typically user a userID and a password.

I don't see reasons, why a sufficiently long password doesn't fit too. For example, a password generated by a server-application.

Are there reasons an app ultimately has to use a userID too?

As long as password are unique and long, it perfectly allows to identify a user.

Answer 1

For one thing, password resets would be quite complicated without user IDs.

---

But the real reason would be that it's not possible to use salting to protect passwords if you don't have an user ID, which means that you would effectively not really be protecting your passwords.

Here's why. Salting requires you to know the salt that was used to generate the password hash. The process is as follows:

1. Locate salt using the User ID in your DB
2. Salt & Hash the password that was provided
3. Check whether this matches the password hash you have in the DB.

If you don't have an user ID, you'd need to check your password against every user in your database.

This is equivalent in complexity to checking one password is against your entire database, which is something you purposefully want to make prohibitively expensive (in time or money) by design.

Answer 2

One of the most important reasons why web applications don't use passwords only is that two users could have the same password.

When the password is the only factor to identify a user, user A could log in with his password and would have access to user B's account and not his own account since they use both the same password and the system needs to pick one user to log in.