5

For the purposes of security, is there any difference in having a 50 character randomly-generated secret username accompanied by a 50 character randomly-generated secret password, versus a 100 character randomly-generated secret username with no password?

schroeder
  • 123,438
  • 55
  • 284
  • 319
RockPaperLz- Mask it or Casket
  • 3,114
  • 21
  • 50

5 Answers5

9

I think it depends on how you define "username". Usually a username is something that is derived from the name of the user. So it is guessable.

A username is often displayed in the Application at some kind of user preferences. So the username is visable.

Then a username is sometimes used to reset a password, and thus the username might be sent over the wire - maybe via smtp. So the username can be fetched from the traffic.

Sometimes users need to communicate to each other - so the username becomes a public data.

However, if you think of some kind of authorization token as a username, you could very well take a 100 characters long "string" to authenticate. But do not think of that as a "username"!

cornelinux
  • 1,993
  • 8
  • 11
  • I agree, a "username" is an identifier, so it should be a public data, then you need somethind to be sure that someone is owner of that identifier, in this case a password, they are different things for different purposes. – hmrojas.p Mar 27 '18 at 00:03
  • 1
    You are right. And if you do not draw this line, then you should not call it "username". He is maybe thhinkg of a kind of "service account". And in fact he could use a 100 byte string auth token instead of a service account. But there would be no "username" involved. – cornelinux Mar 27 '18 at 06:16
  • In some systems, for example [here](https://www.vaultproject.io/docs/auth/approle.html) credentials are two guids, one serves, as application id and the other as the secret. In this case it's not really visible or guessable. Here, using the pair, as I understand, is not used to increase *security*, just to make secrets management more convenient (like an ability to have several passwords, or more obvious way of linking credentials to the entity they protect) – Andrew Savinykh Mar 28 '18 at 08:38
  • It's probably more accurate to assume OP is talking about a user login (which many sites do call a username, even some that literally just make it your email address). You can have a display name on top of that. "Name" just means how "a person or thing is known, addressed, or referred to", which can certainly include the string you're using to log in with. That assumption would largely invalidate your answer. This assumption seems more likely considering that OP said the username is secret. – NotThatGuy Mar 28 '18 at 19:06
7

The main disadvantage of a single "token" (or "username") to authenticate is that in order to authenticate the user you have to do one of two things:

  1. Store the token in the database in a retrievable form such as plain text or encrypted. This means if the DB is compromised the attacker will know everyone's token.
  2. Hash the token. But if you do this it's best to use unique salts per user, but in this case you can't. You would have to use the same salt for every hash, which opens the door for rainbow table attacks.
TTT
  • 9,122
  • 4
  • 19
  • 31
7

You're combining two concepts, identity and authentication, into a single entity. You are then calling the result "username". This name incorrectly implies to the reader that it's only embodying identity, hiding the fact that it should be kept secret to secure the authentication aspect of it. Remember that identity is not normally something people keep a secret.

"Unguessability" is an important attribute of a secret used for authentication. But security doesn't come only from having an unguessable secret. It also comes from people properly handling that secret. By calling it something it's not, you risk confusing your users into treating this secret like they would their email address.

This is not a theoretical problem -- it's the foundation of all the problems with credit card theft the world suffers from today. Credit card numbers were always associated with identity, not authentication, but they serve both purposes making them valuable to thieves.

To avoid this problem, I would not call the 100 character string either a "username" or a "password"; instead, calling it a "token" might help people understand how to handle it.

John Deters
  • 33,650
  • 3
  • 57
  • 110
2

The most important aspect to passwords is secrecy. If a username is completely secret from everyone but the user, then you don't need a password. If a username is ever shared with anyone else, then you do.

Additionally, having a secret username would be a UX nightmare - people don't expect usernames to be secret, and won't treat them as such.

Monica Apologists Get Out
  • 4,021
  • 1
  • 14
  • 21
1

If by "username" you mean an auto-generated long account identifier not visible to other users, and where an email/username is not needed for account recovery, it can make sense. Examples would be Resilio/BitTorrent Sync "indentities" or cryptocurrency private keys. For the purposes of this answer we'll call this secret the "password," not the "username."

In fact if some service allows the public username to be used (along with a password) to authenticate, then it's essentially already using just the one secret, the password, to authenticate.

If you have just one single password for authentication, what happens if a user attempts to use a password someone is already using? You can't warn the user that "that password is already taken." To avoid this scenario, the app itself would have to generate the long and unique password, and in turn this would most likely mandate the use of a password manager.

Another problem is account recovery -- you may need the user to associate their email with their account anyway to allow the password to be reset. If this is the case you might as well use both a username and password to log in.

not22
  • 181
  • 4