16

I don't know why do we authenticate by prompting the user to enter both username and password. In my mental model, prompting password only suffices.

The reason is as follows:

Assume there are x valid characters to use.

Case 1 (prompting username and password)

Let the length of username and password be n/2 characters each. Since the username is exposed to the public, the probability of success to break the password is one over x^(n/2).

The username is unique.

Case 2 (prompting password only)

Let the length of the password be n characters. The probability of success to break the password is one over x^n.

Why do we authenticate by prompting a user to enter both username and password? Does prompting the password only suffice?

The password is unique.

schroeder
  • 125,553
  • 55
  • 289
  • 326
LaTeX
  • 355
  • 2
  • 7
  • can you tell me how to you want to log access attempts? on which basis? I am sorry but this approach simply cannot be regulated... – Phoenician-Eagle Mar 04 '11 at 20:50
  • 2
    I often see that attacker try random usernames with (I guess) a common fixed password. So they get around a temporary ban on account names for too many failed login attempts. – Hendrik Brummermann Mar 17 '11 at 08:01
  • 4
    @LaTeX: If I didn't enter a username and just entered "passw0rd1", which of the dozens of accounts using that password am I going to gain access to? ;) – bstpierre Oct 27 '11 at 23:15

8 Answers8

42

I think the issue is in requiring passwords to be unique. If I entered my desired password, and you told me I can't use it, it's already in use, then I know that I can log in to a random persons account with the password that I would have wanted.

So, you need a username, which is unique, and can be known to everyone. Then you have a personal password, which is not necessarily unique, making even harder to guess.

While you are at it, hash and salt that password.

Justin C
  • 882
  • 1
  • 9
  • 15
  • 6
    > While you are at it, hash and salt that password. < Even better, don't invent your own scheme. Use existing proven schemes. – Bradley Kreider Aug 31 '11 at 18:42
22

There are already good answers here, but the simple, basic concept is still missing:

Identification and Authentication are not the same thing.

Simply put, these are two separate requirements, and should not be mixed up.
A username provides for identification, and a password allows you to verify that claimed identity (i.e. authentication).

See also Difference between authentication and identification [Crypto and Security perspective]

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
AviD
  • 72,708
  • 22
  • 137
  • 218
  • 1
    Good point. I'll also note that it is also possible to do authorization without identification or authentication. Perhaps not as common as it might be, but that is what cash lets you do, e.g. in the real world. So some sort of bare password or token could also be used to access a system, though that isn't how most systems are structured. – nealmcb Mar 06 '11 at 04:11
  • 1
    @nealmcb, I agree with that. However, authorization sans identification actually is performed more often than you might think - e.g. in all the pr0n sites "I am over 18", I wouldnt count that as identification... Also this is *kinda* what claims-based authorization (see MS Geneva) is about... – AviD Mar 06 '11 at 05:52
  • Good example. Hmmm - what's the relationship between Geneva and U-Prove, which seems to be the name they're focussing on now? – nealmcb Mar 06 '11 at 17:18
11

Both the user and the administrator benefit from a username, typically unique, that is not a secret, which they can freely use to refer to the account. If the username is not unique, it can be associated with an email address or other unique contact id. This way a user can reset their password and get a new one, or change their password without changing their account.

Besides that, as noted by others, requiring just a unique password is also problematic when it is the only identifier and there is a collision.

nealmcb
  • 20,693
  • 6
  • 71
  • 117
5

The point of the username is to identify the user. If you only ask for a password, multiple people will (sadly) have the password 123456 or password. How do you identify now, which user with that password is trying to log in? That's why there is also a username.

And since the password shouldn't be saved in plain text, you shouldn't check that the password is unique.

The other point that you miss in case 2: I just need to find a password that someone used, and not who actually used it. So if one person uses the password 123456, I only have to know that and can log in. If there is also a username, the password alone doesn't log one in successfully.

Andreas Arnold
  • 2,423
  • 20
  • 19
  • 1
    Excellent summation. I wanted to add that passwords shouldn't be encrypted either, but hashed with a salt so you shouldn't be able to compare passwords in any case. – Steve Mar 04 '11 at 15:04
5

Your probabilities of finding a password are definitely wrong.

Example:

You have 8 users & each password is 64 bits long (standard 8 chars, not salted in any way).

For case two:

An attacker will have to run his breaking the password algorithm only once to get all 8 users (total work at worst = 64 bits, 32 bits on average)

For case one:

To break all passwords an attacker will have to run his algorithm 8 times (once for each user), which is obviously more work (e.g. total work at worst = 67 bits, 33-34 bits on average)

Probability for breaking the password should be:

For case one:

1/(2^bitsUsedForPassword)

For case two:

numberOfUsers/(2^bitsUsedForPassword)

Therefore the second case has more of a chance of getting the password if there more than one users.

schroeder
  • 125,553
  • 55
  • 289
  • 326
Sigtran
  • 244
  • 1
  • 6
4

Having a username and a password is definitely more secure. Suppose your site has one million users:

  • If you use just a password, then an attacker only has to guess one of the million valid passwords, to break into the site.

  • If you use a username and a password, then the attacker has to come up with a valid username and the correct password for that username (not just any password on the site). That's a lot harder for the attacker.

Requiring both a username and a password provides much better security.

Example: Suppose we assume that each password is chosen uniformly at random from a set of one billion possibilities, e.g., it is a random 9-digit number. (Yeah, I know that's an unrealistic assumption, so this example will be a simplification, but the similar results apply to more realistic assumptions.)

  • If the site only requires a valid password to log in, then an attacker who enters random 9-digit numbers will manage to get into the site after about 1000 tries, on average.

  • If the site requires a valid username and its corresponding password to log in, then even assuming the attacker knows everyone's username, the attacker will have to try about 1,000,000,000 (one billion) times before getting into the site, on average. (Actually, half of that, but whatever.)

You can see that the difference in security is dramatic.

In addition, @Justin C's and @nealmcb's comments provide additional, orthogonal reasons to require both a username and password. Any one of these reasons would be sufficient; taken together, the case for requiring both a username and a password is that much stronger.

D.W.
  • 98,860
  • 33
  • 271
  • 588
1

In theory @Sigtran is correct that having a username is always better, by a general rule the more obfuscation the more security :) In implementation, in situations where you don't need UUID or specific user privileges, you really don't need a username (something like a general repository that multiple people are accessing). In those scenarios, requiring a lengthy and complex password (alphanumeric + special chars) and then salting it is the way to go.

mrnap
  • 1,308
  • 9
  • 15
1

The reason you need both a username and password is so you can look up that user's unique salt before hashing and verifying the password.

A typical, secure scheme has a user table with at least 3 columns: username, salt, passwordhash. The passwordhash is the user's password with their unique salt (a random, unique combination of characters) added to it, then run through your hashing algorithm. Authentication involves looking up the user by username, adding their unique salt to their password, hashing the result, and verifying it matches the passwordhash in the database.

If you just hash the password and store it in the database, than an attacker that gains access to your user table can figure out some of the common passwords using a rainbow table (list of common passwords). That is, they take the list of common passwords, hash them all, and see if any of them match the passwordhash stored in your db. If each user has a unique salt, than they would have to add that salt to every password in the rainbow table, then hash all of them, just to see if they find a match for that one user. Then they have to repeat this for every user in your table. This massively increases the computation needed to find a matching password from a stolen user table.

JMB
  • 111
  • 2