Why don't we use single input authentication?

Question

Two input authentication uses both username (may be available publicly) and password (kept secret).

For the sake of comparison, assume the length of username is the same as the length of password, i.e., n characters. Also assume we can only use case insensitive letters from a to z. If both username and password are kept secret then at most we need 26^(2n) trials to pass the authentication.

Now consider a new authentication system with only one single input, i.e., password that is kept secret of length 2n. The allowed characters are case insensitive, spanned from a to z. This system also needs 26^(2n) trials to be passed.

Questions

Why don't we use single input authentication?

Answer 1

When signing up for a service, you have a good chance of getting "This name is already in use, choose another" - or something to that effect.

In the system you propose, this would tell you that the access code is in use - great, open a new browser and log in with this access code! You've just hijacked somebody else's account.

You could find any number of existing access codes, just by trying to change your own.

Also, what if you forgot your access code? This can be mitigated if the system knows your e-mail address and can send you a new access code, but then you'd be close to a two-input authentication; you might as well use your e-mail to log in then.

Answer 2

User name is an identifier, a label that indicates which user you are, and identifies which resources belong to you (or refer to you).

Password is an authenticator, a way of proving that you are permitted to assume that user identity.

User names can't be secret, as an information system needs this knowledge in the clear, to label resources and to authorize your use of resources. Passwords should be secret, even to the service and its operators - this is why stored passwords are hashed with a one-way function.

By "resources" above, I'm being deliberately inclusive. For a user login, it may be files and processes; as a database user, you have tables and other database objects; for a web site, it might be your posts and reputation points.

Answer 3

We do use it in some cases.

An example is the share using a link feature of Google documents. The link contains an access key or document ID that is 45 alphanumeric characters long. This is long enough to both ensure uniqueness and make brute-forcing difficult.

Answer 4

This single-input authentication system would be interesting, but there are a few security issues with it:

The key obstacle is the requirement for uniqueness. In order for different users to be able to log in to their respective accounts, login credentials (typically username + password) must be unique. In theory this means that in a typical dual-input system, usernames don't necessarily need to be unique as long as no two users share the same username and password. The problem is that in a single-input system, the only credential available is the single password, meaning that each user would need to have a different password than each other, and this introduces a number of vulnerabilities:

1. You could assume that in any sufficiently popular service, a number of obvious passwords are used by somebody. Just by trying to log in with passwords like "password", "12345" and "Beatles", you could probably get into at least a few accounts.
2. As mentioned by S.L. Barth, anyone could find existing passwords just by trying to change their password until they run into a "password already used" message. Because passwords have to be unique, you'd need to stop a user from choosing an existing password, thus revealing that the password is already in use.
3. Dictionary Attacks: This is basically just the logical sum of points 1 and 2. If you make an account, and then have a script try to change the password using a password dictionary, recording every "already in use" password it runs into along the way, you could quickly and easily build up a list of thousands or even millions of existing passwords, which is all you would need to break into all of those accounts.

Note that one interesting security plus you get out of this is that while it would be very easy to break into any number of random accounts (as described above), it would be far more difficult to break into any one account in a targeted attack. Because passwords would need to be unique, you'd end up with more complex passwords in a single-input system than in today's dual-input systems, and there would be no username you could use to target a particular user, so the only way of breaking into one target account would be to brute force your way into all of the accounts until you happen to get the account you're looking for. Plus, it would be more difficult to confirm that the account you're logged into is the account you're looking for, because you can't use the username as identity proof. That's a really interesting security effect, so bravo there.

Answer 5

The user name is an id, and should never change (*). Security best practices recommend to change the password on a regular base and each time it could have been compromised.

As those 2 parts have different life time, it is better to keep them separate.

(*) In fact there are use cases that do require a change in a username, for example when there is a fusion between two entities and two different users used same username. But the lifetime of a username should be much longer than the one of a password

Answer 6

Password fashion mostly

and in the past it would have required extra storage/processing requirments that much much cheaper now.

There is no significant technical reason for it

A user could log in just using a strong password like "9so48dsf67$h9e6ghfoubyf2gfuDywbnefo8g2H3fg2fkngsd6_g3ty7g63gs74g" and the server could automatically match it with the relevant identity and safely assume it was correct.

This is effectively what Google Docs etc do when generating a shared doc url.

They just use it for access to the that one doc, not for identification.

i.e.

They dont know your identity (no login name)

But the url authenticates (is valid in their database)

and it also automatically grants you authorization (to view or edit that doc)

The system could easily handle changing/lost passwords, "nickname"s, email addresses etc

People are VERY used to picking their own much shorter and much less secure passwords which would make this approach too insecure to be practical

People are also very used to the "login" + "password" method and would take significant training to understand and trust an alternative.

Answer 7

Wikipedia has the following to say about authentication:

In contrast with identification which refers to the act of stating or otherwise indicating a claim purportedly attesting to a person or thing's identity, authentication is the process of actually confirming that identity.

_{(emphasis is mine)}

In the real world imagine you go to the bank:

1. You: Hi my name is John Doe and I would like to open an account.
2. Clerk: Can you provide me some form of proof of your identity?
3. You: (Provides an ID card or drivers license)

On point one you identified yourself as John Doe and on point three you proved that identity in a way that the bank trusts. In the real world your identity was usually decided by yours parents a long a time ago when they chose your name.

In the online world, sites using the traditional two input registration process, allow you to pick your identity and also the way you prove that identity.

It's true you could try to merge both the identity and the proof in the same actual piece of data, but is there really any benefit? The username plus another piece of data to use as proof is already understood by everyone because it somewhat matches the real-life. Additionally it also makes the underlying implementation much simpler as was stated on other answers and comments.

It's also true that being forced to always be creating an identity and a proof in every online site you go to is kind of boring. Specially considering that the identity part needs to be unique within that site and you're a late adopter meaning all the cool identities have already been picked.

Initially this has been solved by accepting your email address as the identity, this way, the user does not need to think about it and the uniqueness is still ensured.

However, some are even going one step further and try to simplify the process even further by allowing what's known as passwordless authentication. The cool thing here, is that you don't need to create either a new identity nor even a new password to proof the identity.

An example of this is the Auth0 implementation of passwordless authentication which allows a user to authenticate into a site either through a link provided through their email address or a one-time code provided through an SMS.

Passwordless connections in Auth0 allow users to login without the need to remember a password. This improves the user experience, especially on mobile applications, since users will only need an email address or phone number to register for your application.

Without passwords, your application will not need to implement a password-reset procedure and users avoid the insecure practice of using the same password for many purposes.

_{(emphasis is mine)}

From the perspective of the user this very simple to perform and from the perspective of the site using this type of authentication it's still possibly to identify recurring users either by matching their email address or phone number.

If you think about it this is just simplifying what many users used to do. I, for example, admit that many times that I wanted to authenticate to a new site I would just use my email address and a random password that I would never ever remember and in the eventuality that my browser lost the session or stored password I would just reset the password.

_{Disclosure: I work at Auth0.}

Answer 8

PKI certificate based authentication is kind of like a userID and password in one.

sign the public key

PKI

Answer 9

This is not really feasible with passwords. This is feasible with any scheme where the key/secret/credential/token/whatever is stored on a client's computer and not inside human's brain.

Convoluted? Turn exactly the same thing around: if you have a sufficiently random and sufficiently complicated key/secret/credential/token/whatever, it doesn't even make sense to ask a human for a username, a nickname, a GUID, any other identification for an everyday authentication. Software will tell them all these.

If your software doesn't welcome suckpuppet accounts that is. (Some do welcome. For example ssh is happy with "sockpuppets", different accounts used by one human; it asks for account name even if you provide an RSA key. Sockpuppet RSA private keys sitting one next to another on the same device would be unnecessary complication, not more security.) Asking for a nickname is the easiest way to support sockpuppets.

"Sufficiently complicated" key implies we don't ever expect a collision. It implies we don't ever expect a need to salt it. It implies average human cannot remember it. And it implies we don't need the additional bits of complexity from human remembering the username.

Account reset

The only problem is reset after losing the key or after it is compromised. It means a lost or compromised device. Here we need to use a more secure authentication (also possibly a more troublesome one). Do you need user to remember their nickname here? If you ask user only for a mother's maiden surname, the collision is near-certain. That doesn't mean you need a nickname, it means surname authentication is too weak! All the attacks would be about the poor mothers' maiden names. But you will likely need to ask for some global outside-of-the-app identifier, most likely a mobile number for SMS verification (this excludes the threat of attacker controlling your mobile).

Alternative scheme is e-mail verification, also requiring a global outside-of-the-app identifier (this excludes the threat of attacker controlling any your device, so it's really weak in this setting).

Observe that, in most cases humans don't need to remember their global identifier, but sometimes they do need to go check it up and enter it manually.

Alternative scheme is pre-shared paper verification: ask user for a one-time password number 04 from the paper card mailed to them when they opened an account. It is one case when I find it handy to augment with a "trivial secret" authentication, so that just about any person who obtains a letter doesn't reset access just for fun or out of sheer curiosity. It could be "what postal code did we use to mail this paper?", it could be the dreaded maiden name, but it could as well use a nickname.

Passwords remembered by humans

The password, or a short secret text that could be remembered by a human, is an inferior scheme that is long overdue. The associated unnecessary costs include:

• "please login" page
• "this nickname is occupied" problem
• "this password is too weak" problem
• need for a server-side salt (upgrading the weak secret to a truly random one to counter rainbow tables)
• KeePass and similar databases - overcomplicated solution to a simple problem of getting a proper scheme to work over old login prompts

These all vanish with machine-stored key scheme (symmetric or asymmetric, the latter suggested) .

Answer 10

We don't don't use it because it's impractical.

Imagine you've got a huge database of users, say, 8 billion, because everyone on earth uses your website. Someone just handed you their single input key. How do you know if they're in the database?

You can't just store keys and look them up since they're basically plain text passwords, and storing passwords in plain text is bad. You can't just hash it a few hundred times with md5 either because you'd be vulnerable to rainbow tables. You need to use a proper password hashing algorithm like bcrypt with a big, random salt.

Now you have a key and a big table of salts, and you need to figure out which one goes with this key. But if you could look up the salt, you could have just looked up the hashed key in the first place! You're stuck.

Your only choice is to hash the key with all 8 billion salts, then search the database 8 billion times (once for each key). A lot of people suggest that you set hashing to take around 1/10 second. Imagine that: 8 billion hashes at 1/10 second each would take 25 years to log in.

Unless your users are especially patient, you'll need a massive number of computers to compute all those hashes in parallel, which costs a lot of money, which your customers will have to pay, which makes the competition look more attractive. Otherwise you'll have to lower the work factor so hashes are easy for you (and, by extension, attackers) to compute. Or maybe develop specialized hardware that has the same effect as lowering the work factor since you can bet attackers will buy it too.

All of that is conveniently side-stepped by having the user supply a name instead. The name isn't secret, so it can be stored as plain text in the database. Then the database can sort its tables by name so the server can efficiently look up the salt that goes with the user's password.

That's why we'll probably always have usernames in some form or other: We need a lookup key to make the login process efficient, and the demands to salt and hash passwords make anything password-like a bad candidate for the task.