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.


Why don't we use single input authentication?

marked as duplicate by Anders, techraf, Matthew, Tobias Kienzler, AviD Nov 3 '16 at 16:27

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 41
    We do use single-input authentication. The username is for identification, not authentication. Different problem. Look at it this way; why do you, as a person, have a name and a key to your house? Why not just the key? – marcelm Nov 2 '16 at 15:00
  • 6
    It's already done with fingerprint and eye scan. The problem is that it has to be unique for all users. Asking a user to input their own single authentication will produce errors like "it already exist". – the_lotus Nov 2 '16 at 15:33
  • 11
    @marcelm that logic is flawed; your name is not used when accessing your house, unless you've got some screwy high-tech lock that you have to verbally address as you insert the key to successfully gain access; if anything it is an example of single input authentication (the house doesn't care WHO has the key, just that the key fits the lock). – Doktor J Nov 2 '16 at 19:27
  • 7
    @DoktorJ in your example, the street address is the username. If you just have the key (the password) but not the address (the username) you can walk around the city trying the key in different doors but just because you get inside (the key works in a lock; the same password hunter2 is used by multiple accounts) doesn't mean you got into the right house. – drewbenn Nov 2 '16 at 22:16
  • 3
    @drewbenn But it doesn't matter whose house you get into. You just take what's valuable and leave. If you enter a password and the system tells you that password is taken, then you could immediately log in to that account and do bad things without any interest in whose account it is. – sh1 Nov 2 '16 at 22:28

10 Answers 10


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.

  • 4
    @SingleFighter Indeed it isn't. Note that this hinges on the assumption that the length of the username/password/access-code is fixed. In practice, a good system allows passwords of arbitrary length. – S.L. Barth Nov 2 '16 at 8:34
  • 9
    you might as well use your e-mail to log in then. - well, there is a nice thing just about that called passwordless auth. For the not-really-often used services this can be emulated even if it requires you to have the password but allows you to restore/reset password by email - you can just set up long random password that you can use one time and forget about. Next time you need to log in just ask system to reset the password and enter new one-time long random one. :) – Ivan Kolmychek Nov 2 '16 at 16:03
  • 1
    @IvanKolmychek Interesting! I've long thought something like this should be possible. I'd need some time to check if that method is as secure as I hope. Meanwhile, consider posting that method as an answer. – S.L. Barth Nov 2 '16 at 16:13
  • 2
    @notstoreboughtdirt: randomly-generated codes ends up being like SSH key pair authentication: nobody can remember their "real password", it's just not humanly feasible, so they carry it around in an encrypted file and just remember the encryption passphrase. This has quite a lot of benefit over ordinary password login but also some usability issues. – Steve Jessop Nov 2 '16 at 20:19
  • 2
    @Bruno why bother collecting a seed at all? Especially considering it really detracts from the security of the system more than it adds, because there are few things less random than input provided by people who are being asked to provide a number and don't really care either way. Use a cryptographically-secure random number generator and you're far safer with far less "What are they making me choose a random number for?" from your users. – TheEnvironmentalist Nov 3 '16 at 0:03

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.

  • 1
    Spot on. Identity and authentication are different pieces of information. – jpmc26 Nov 2 '16 at 16:43
  • 2
    @jpmc26 but they don't necessarily have to be, hence the rather interesting question – TheEnvironmentalist Nov 3 '16 at 1:59
  • @TheEnvironmentalist: You can merge pretty much any two pieces of information into one long string, and then use logic elsewhere to make up the difference. In this case you would likely end up with some non-shared record id to identify the user and link to once the long auth token is input. So user would still have an identity, just you have not explicitly asked them for it, and hoped that their auth token is unique so you can find it. It is more common (and I would argue better practice) to keep the problems of identity and auth separate and explicit. – Neil Slater Nov 3 '16 at 10:25

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.

  • This is not authentication, it is authorization. Google doesn't need to know who you are to authorize via URL token. – bunyaCloven Nov 2 '16 at 15:44
  • 2
    @bunyaCloven It's both. With, say, a reset password link, the link references both the account and the authorization to complete a given action (change the password) on that account. Eoin's suggestion of link-based keys is a great example, one that solves the issues of uniqueness and vulnerability to dictionary attacks by choosing the "password" for you, and making it far too long to brute-force and too random to apply a dictionary attack. – TheEnvironmentalist Nov 2 '16 at 17:42
  • @TheEnvironmentalist bunyaCloven is correct. The is no confirmation of your identity here. Anyone with the link is assumed to be authorized; their identity is never challenged. – jpmc26 Nov 3 '16 at 3:53
  • 1
    @TheEnvironmentalist It is not. A reset password link is an authorization token that is sent to an authenticated mailbox. – bunyaCloven Nov 3 '16 at 6:59
  • 2
    API keys are another example of single input authentication. There are a vast number of different tools out there where you generate an API key for a user, which is then used by itself for both identification and authentication to access that tool. The drawback, of course, is that the end user cannot specify what that key is, it must be chosen by the server so that it can be unique and secure. – cscracker Nov 3 '16 at 17:31

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.

  • 1
    I've seen “single-input authentication” that deals with issue #2 by having the computer rather than the user generate the last few letters of the password. – dan04 Nov 2 '16 at 18:24
  • What happens when I change computers then? Will I lose my account? – bunyaCloven Nov 3 '16 at 7:02

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

  • I believe the question asked why this needs to be the case. Why should the user name never change. Why is the single-input system not viable? – TheEnvironmentalist Nov 2 '16 at 14:36
  • @TheEnvironmentalist well, the question also implied that the username is explicitly part of security by equating its usage to that of a password. The answer does say that this isn't true and the two things should be kept separate. It's a valid answer. – VLAZ Nov 2 '16 at 14:40
  • 1
    Unfortunately, usernames often do need to change. Hence why a unique ID is often used to map username to properties. – Brian Knoblauch Nov 2 '16 at 15:04
  • @BrianKnoblauch: I know that usernames can change, but their life time should be much longer that the one of a password. Anyway, I've edited my answer. – Serge Ballesta Nov 2 '16 at 15:37
  • 1
    These 2 parts have different life time because they are separated and given different roles, not vice versa. – bunyaCloven Nov 2 '16 at 15:41

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.


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.

  • I think it's because people expect being able to change the password while still being recognized as same user. – Agent_L Nov 3 '16 at 11:55
  • @Agent_L, they can change the password. Either whilst already logged into their account or via the usual "i forgot my password" form, where they would just enter their email and nothing else. The only restriction is that the password/token/whatever you want to call it must be of sufficiently high entropy. Most people just aren't willing to do that. – John McNamara Nov 3 '16 at 15:12
  • My bad for being unclear, I was referring to your last sentence alone. I haven't meant the google docs, because you do log into it with login and password first to generate the authenticating link. I meant a general situation where login and pass are merged into one string, this makes it feel like you can't change password but retain identity. – Agent_L Nov 4 '16 at 11:48

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.

  • 1
    "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?" Thats the interesting question. It's trivial to do, we have lots of reasons users wouldn't like it, but are there any actual unique practical benefits ? – John McNamara Nov 3 '16 at 15:21
  • In my opinion if we force the user to know and keep that single piece of data secret forever it's all downsides and no benefits. Even more so because that single piece of data would have to be generated randomly by the application because allowing the user to pick it would just not work. – João Angelo Nov 3 '16 at 15:32
  • Nothing in the scheme implies "forever". The token could easily be changed by the user via email/SMS just like current "lost my password" procedures. – John McNamara Nov 3 '16 at 15:40
  • If you bring email and SMS to the mix you already have another piece as the user identity, even if the user does not have to input it; it's the passwordless thing I mentioned. If you truly use one single piece for identity and authentication the user has all the responsibility on his shoulders. You may allow to rotate it, but the user always has to know the current one... forever or until he gets tired of the site. – João Angelo Nov 3 '16 at 15:44

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

sign the public key



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) .


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.

  • 2
    Surely this is the most practical answer? A sensible system won't store passwords in plain text, or just hashed. It would store them as hashed with a salt. The username tells the system which salt to use when verifying the password. Without that, you would have to use all possible salts against the entered password. – Nick Gammon Nov 3 '16 at 5:49
  • @Nick, that's not the only way passwords are salted, and IIRC not the usual Unix approach with traditional passwd file (or, equivalently, shadow passwd file). There, the salt is random, and stored as the first few characters of the encrypted password. So there's no requirement for the salt to be derived from the user identity. – Toby Speight Nov 3 '16 at 8:20
  • @Mirinth, I think there's a flaw in your reasoning. If the user id is part of the password, then it becomes de facto a salt for the password. So instead of rainbow tables for salt+password combinations, an attacker would need rainbow tables for username+password combinations. – Toby Speight Nov 3 '16 at 8:22
  • Addressing "we need a lookup key to make the login process efficient", that's the process that could still be efficient. The things that could be particularly problematic are more likely to be admin or operator actions - how would you request a password reset, without some identifier you could divulge? (Note that "here's a list of the email addresses I might have used when signing up" isn't really an answer to that, because you've then introduced a user-name equivalent back into the database). – Toby Speight Nov 3 '16 at 8:25
  • Salt is a random text concatenated with the human-provided password (read: puny weak password gets improved to random one). If the password is computer-generated and entirely random, it already contains all the salt needed. – kubanczyk Nov 3 '16 at 12:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.