In this hypothetical scenario, there's an input for one username, and there are two separate password fields. A user must have two separate passwords that they must enter before they can login. Would this have any benefit over a single password that's the length of password one and two combined? (I'm not concerned about ease of use for the user here)

  • 4
    In addition to all reasons below it will prevent, or at least make harder, use of password managers. Since password one can remember is "useless" all you done is forcing users to create 2 useless passwords (compared to using for example 60 characters completly random unique password). Oct 24, 2016 at 23:10
  • 1
    @MaciejPiechotka ...make harder, use of password managers., which might be a good thing, depending on your threat model, blame model and usage model. Anyway, for this scheme to provide any benefit, the passwords must prove different things, e.g. "Only if password1 is correct, is password2 evaluated. Only if password2 is incorrect is account lockdown triggered." or "Password1 proves access to password manager, password2 is easy to remember." or some such. Not worth the trouble, usually, but the hypothetical benefit is right there. Oct 25, 2016 at 9:52

8 Answers 8


I agree with the other answers:

  • It add no or little entropy compared to just using a longer password (as Steffen Ullrich points out).
  • If you hash the passwords separately, it makes the hashes easier to crack compared to one hash of a long password (as lengyelg points out).

But I would like to add one point related to user behaviour.

Forcing the user to pick two passwords instead of one will probably make the user pick worse passwords out of pure exhaustion. You will just encourage people to repeat the same password twice with some modification to evade any blocks you put in place to prevent this.

When you factor in the human picking the passwords I think you end up being less secure, not more. It is just annoying without any security benefits at all at best, and directly harmful to security at worst.

  • +1 for this. I think its the most important answer. Security only works if its easy. Passwords are hard enough, and 2 passwords are super hard, so people are just going to get lazy. Its bad enough for the 3 security questions Oct 24, 2016 at 20:14
  • 2
    And since humans do not like to remember things most users will simply create "password"+"password1" or "password1"+"password2" or even "password"+"passwordSecond".
    – grochmal
    Oct 24, 2016 at 21:03
  • This second bullet is particularly interesting since there may be cryptanalysis techniques specifically for that for any given hash algorithm. ... This answer is well constructed. ... Readers should remember that this case is distinct from the single password typed twice, which is a fair way to ensure that the user has typed what they think they typed. Jan 23, 2017 at 22:30

It's actually less secure to have two separate password fields in the sense that if password hashes are stored separately, it can be easier to find two shorter passwords from something like a rainbow table than one long password. Of course if a single hash is stored for the concatenated password, it's the same as one password field.

  • I think for the purposes of this question, we can assume that the rainbow table would be nullified by random salts for each password combined with a strong encryption algorithm (e.g. bcrypt). How does that change your answer?
    – jpmc26
    Oct 25, 2016 at 3:50
  • @jpmc26 Cracking two n letter bcrypt hashes are still easier than cracking one 2n letter hash. Sure, crachking even the n letter hash might be impossible, but given how people pick passwords that can not be taken for granted.
    – Anders
    Oct 25, 2016 at 9:29

The only difference between your proposal of two passwords P1 and P2 and a single password P1+P2 is where the string P1+P2 is split to get the two passwords. Compared to the complexity which can be achieved already with a long password this additional step adds nearly nothing in complexity and thus does not really make cracking the password harder.




From a theoretical perspective, there is a slight increase in entropy because the position of the break between the first and second passwords constitutes additional information.

One big password. Let's say you have one password and the user enters 16 characters, and for simplicity let's say that the password must be numeric. This amounts to 10^16 possible permutations, or 10,000,000,000,000,000 (10 quadrillion).

Two passwords. Now let's say you have two passwords that total 16 characters. You would think there are 10^16 combinations, but in fact there more. Let's add them up:

If the first password has 1 digit and the second has 15 digits, that amounts to 1^10 x 15^10 = 10,000,000,000,000,000 permutations.

If the first password has 2 digits and the second has 14 digits, that amounts to 2^10 x 14^10 = 10,000,000,000,000,000 permutations.

If the first password has 3 digits and the second has 13 digits, that amounts to 3^10 x 13^10 = 10,000,000,000,000,000 permutations.


If the first password has 15 digits and the second has 1 digit, that amounts to 15^10 x 1^10 = 10,000,000,000,000,000 permutations.

There are 15 possible cases, totaling 150,000,000,000,000,000 permutations (150 quadrillion).

Comparison. Since 150 quadrillion > 10 quadrillion, yes, there is a bit of increase in entropy and therefore it is harder to guess the two passwords than the one long password.

The assumptions above (length = 16, character set = 10) can be changed and the math will still work out.


On the other hand, depending on how the system evaluates the password, the above may not apply, e.g. if the web site combines the passwords and hashes them together instead of keeping them separate. If that is the case, then no, there is no additional computational power required to forge the password, because there are in fact 15 different password combinations that will work. 150 quadrillion ÷ 15 = 10 quadrillion so you're back where you started.

It's even worse!

See lengyelg's answer which is spot on:

It's actually less secure to have two separate password fields in the sense that if password hashes are stored separately, it can be easier to find two shorter passwords from something like a rainbow table than one long password. Of course if a single hash is stored for the concatenated password, it's the same as one password field.

Why bother?

In my opinion, it is far simpler to require an extra digit than it is to require two separate passwords, and that will always have a stronger effect if your character set is larger than the length of the two passwords combined (which will almost certainly be the case).

  • You mention in the No case that it depends on how the system evaluates the password. How would the system evaluate the separate passwords to result in an increase in entropy? Would it follow a McCarthy evaluation? Oct 24, 2016 at 20:14
  • Yes, it could use a McCarthy evaluation, or it could simply hash the two passwords together with a delimiter. The position of the delimiter constitutes the additional entropy.
    – John Wu
    Oct 24, 2016 at 20:20

As far as i understand this 2 passwords with length N and K symbols respectively will be equivalent to one password with length N+K. Very small probability that users will take more strong passwords, by remembering two separate words. But dictionary attack will brute force this without serious problems


Yes, there could be a difference, depending on how the two passwords are chosen.

If one of the passwords is chosen by the user and the other is produced by a pseudo-random number generator such as the ones your bank may provide to online customers, or a password picked from a list of passwords sent to you by the site operator, from which you always have to strike out the last used password and use the next one, then that would make a difference.

If you let a user pick two passwords on his own, chances are they won't be very good, and you'd be better off with a password that was twice as long, since it would be harder for a brute-force password guesser to guess early on. But if half of a users' password is a strong, quasi-random string that changes every time he logs in, then that improves the security of the login process and all future sessions, and guards against the consequences of tricking a user to reveal his chosen password or even the current combination of passwords.

Note that this won't make a password more difficult to crack when the user password database is stolen, since the password that's actually stored in the password database would still only be the one the user chose himself.

  • 1
    obviously you are describing two factors authentication in the first case...may be slightly difference in the timing between the two passwords.
    – elsadek
    Oct 24, 2016 at 19:57

The main reason I can think of for this scenario is if you want to have the requirement that two people must authenticate rather than trusting a single person - sort of like how popular movies show two missile launch keys. P1 has a password, P2 has a password and when both enter them, the system uses both to create the actual key used to authenticate. Thus neither by themselves can unlock. It theoretically increases security, but at the possible danger of loss of access (one gets hit by the hypothetical bus).


There's one more point I haven't seen anyone address yet, which is a spec question that's not clear from your question: does the order of the passwords matter?

In some systems, such as those using a variation of Shamir's Secret Sharing, the system was designed with the assumption that the multiple passwords would be held by multiple parties, and thus, the order in which they are entered doesn't matter.

However, if you used a similar scheme in this scenario, you now allow an attacker to enter using bar and foo when the user set their passwords to foo and bar. If we compare this to a combined single password, you've doubled the number of valid entries, from just foobar to foobar and barfoo.

At two passwords, this isn't probably a big deal; it becomes more of an issue as you extend the number of passwords. At three we now have 3! = 6 valid combined passwords, at 4 we have 4! = 24, and so on, rapidly increasing.

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