5

While browsing this community I notice that some people say that the main advantage of usernames accompanied by passwords is as they take more tries to be brute forced, however I don't think that is the case, for example:

#Easy password just for example

Username: admin
Password: c1235

Is just as tough to crack as just a single token/password to log in:

Password: adminc1235

Another argument people give is that usernames accompanied by passwords can be salted however you can also salt a single password by splitting into two different substrings and salting them.

Also SQLinjection is way harder to find the details of the account you want to hack if there is no username...

Apart from safety measures of course I understand that usernames also serve as the user's memory for the password, but looking at the security facts I don't see a lot of difference between a username with a password and a long password phrase/sentence.

So I would like to ask, are there anymore reason why passwords accompanied by a usernames are deemed safer? If I made mistakes in my posts please say so, i'm not an expert!

3
  • 1
    I think most of your points are valid if there was only a single user named 'admin' How do you plan on identifying users if not a username? Commented Jun 2, 2015 at 16:37
  • 1
    I think you are missing the idea of "identity"
    – schroeder
    Commented Jun 2, 2015 at 16:38
  • This would be a beautiful system to do a dictionary attack against, all you have to solve is the password and you own every account that matches, more safe because there could only be one password1 and therefore only one account would be compromised on that match. Commented Jun 3, 2015 at 2:00

4 Answers 4

11

In most systems, username is required to be unique but password is not.

If password was used as a login credential without a username, then password would have to be unique. In that case the same attacks against username would work for password, such as trying to sign up with a dictionary-word password and looking for an error that the password is already used.

1
  • 3
    if i get already in use for the password i sign up with ... then i know a way in to someone else's account. and what if i did not notice that error and thought i was now signed up?
    – Skaperen
    Commented Jun 3, 2015 at 12:39
8

Before the password can be validated, the user's record must be looked up in the database so that you know what salt to use when hashing the password. If you didn't have a username you'd have to extract the salt from each stored hashed password, salt and hash the inputted password, and compare the result to the stored one. This would need to be done for each record in the database until a match is found. This would be prohibitively expensive as the password storage algorithms (eg: bcrypt and PBKDF2) are designed to be expensive so that they protect against brute-force attacks should the password database get stolen.

So, in a world with only passwords, an entirely new password storage mechanism would need to be created. One that would be expensive for the attacker to do en masse but not for the system to do en masse when logging a user in. I won't say that it's impossible, but I suspect any solution would be even more complex than what we have today.

3

In addition to CoverosGene's answer, you have the issue that there are now only passwords for both identity and authentication. Think of it this way, if a person just chose their password as "bob," you only have to solve that once and you're into their account since you don't have to apply it to any specific username/identity. It's incredibly easy to break since you never have to match passwords up with a specific account, since it is the account's identifier now.

Assume in a system with both usernames and passwords that your attacker has gotten ahold of a list of all of your registered usernames, and is trying to break into the accounts. S/he is going to have to try to crack the password for each account separately to get into each of the accounts. If there were no separate username, there's no such safeguard, since they only have to try the passwords in one pass of the system.

3

Apart from unique passwords and computational problems, you still need to be able to identify a user in most systems without authenticating the user. The best example is e-mail: you need to have a public ID of a user in order to be able to send him a message.

And since you want to prevent password collisions you'd have to, in your world, make sure that the password of a user who wants to receive the mail is at least partially delivered from the user ID which makes that part of the password a not-a-password. The authentication "token" would still consist of an ID and a secret so there is no reason to put these two together and treat them as a single secret as explained in other answers.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .