0

Why do most websites use the pair of username and password as we can just use a long password like a token to identify a user?

A simple example: On the server, we create a JSON file with user data inside of it (email, role etc.) and give it a random 32-characters name. Then if a user wants to log in, he just copy/paste his long password into one form input and submits the form. If submitted password matches with the name of JSON file on the server, the authorization is successful and the server identifies the user.

So why not and why username and password?

stckvrw
  • 117
  • 2
  • 2
    Does this answer your question? [Why do we authenticate by prompting a user to enter both username and password? Does prompting the password only suffice?](https://security.stackexchange.com/questions/2384/why-do-we-authenticate-by-prompting-a-user-to-enter-both-username-and-password), [Why have username AND password?](https://security.stackexchange.com/questions/34098/), [Using only password to authenticate user (no “username” field)](https://security.stackexchange.com/questions/20072/). – Steffen Ullrich Jun 11 '20 at 07:38

1 Answers1

0

You've just described API keys and that concept is used everywhere.

You want a username and password pair for two practical reasons:

  1. if users can create their own passwords, you risk people having the same password
  2. if a user needs to change their password, doing so won't invalidate the identity of the user on the system if the password is also the user's identity
schroeder
  • 123,438
  • 55
  • 284
  • 319
  • I know about both aspects you've mentioned, but 32-characters string is always unique, otherwise anyone can hack such password even if he is not a hacker. And if a user decided to change his password, he just rename the JSON file. – stckvrw Jun 11 '20 at 07:42
  • "32-characters string is always unique" -- that's not true. It's close to being true if it is a ***randomly generated 32 char string***. – schroeder Jun 11 '20 at 07:43
  • 1
    "he just rename the JSON file" -- then the file name becomes the username... – schroeder Jun 11 '20 at 07:43
  • In my question I mentioned "**random** 32-characters name", as API key. As for your comment about renaming the file, sorry I can't understand what you mean. A user just generate new random string and set it as new file name. – stckvrw Jun 11 '20 at 07:46
  • Your question's details are very confused. You have mentioned a file, the data, the filename, and a password. The file is on the server not on the user side. The user copy/pastes a long password. But the password is actually the file name? The user cannot create it? Then everyone and their dog knows the password? Then you cannot hash or protect the password at all since it is a file name that needs to be looked up? You are violating a few design principles here in addition to security principles. – schroeder Jun 11 '20 at 08:02
  • When a guest creates an account, the server generates random string, creates a file with the same name and displays the string on the screen. The guest saves the string and becomes a registered user. It's the same as creating normal password, but the password just is stored in a file name and not in DB – stckvrw Jun 11 '20 at 08:12
  • 1
    No, there is nothing in that process that is anything like a normal password process. – schroeder Jun 11 '20 at 09:23
  • @stckvrw Let me offer you an additional insight: If that system would work, don't you think more sites would have adopted it? –  Jun 12 '20 at 08:54