Would it be a good idea if you had one account which would require two different passwords ?

For example your login details were:

email: [email protected]
password 1: P4$$w0rd1
password 2: HereIsMySecondPassword

Now when the user logs in to my site he is required to enter both passwords. Would this be a better idea than just one stronger password ? The user could choose two passwords which he can easier remember than one strong.

  • 44
    Consider how many users will have password2=password1 (or, if explicitly forbidden, password2=password1+2) Commented Jan 25, 2016 at 13:36
  • 3
    Just prevent that they are equal and they can't contain each other.
    – gab06
    Commented Jan 25, 2016 at 14:21
  • 1
    Or that the passwords have to be a certain % different on top of @gab06's ideas. Commented Jan 25, 2016 at 15:13
  • 2
    A username kind of has this same effect. Usernames for my bank, for example, are something like (part of first name)(part of lastname)(random number). So if my name is Jonathan Smith, the username might be jonatsmi022, or jonsmit840. This would make it harder for a brute force attack since the attacker would need to find or guess both username and password.
    – zundi
    Commented Jan 25, 2016 at 15:51
  • 13
    Obligatory (related) xkcd ... xkcd.com/936 . Stop making it overly complex .. just allow longer passwords .. would help more than all these (overly) complex rules ;) (which just encourage people to write things down - thereby compromising all those rules anyway)
    – Ditto
    Commented Jan 25, 2016 at 16:18

10 Answers 10


Not really. It's essentially one password, with a press of the return key as one character.

It adds complexity to the log in process, which isn't generally a good thing (users would probably choose one good password, and one quick to type password). Don't forget @AviD's rule: "Security at the expense of usability, comes at the expense of security"

Depending on how the passwords were stored, they would slightly decrease the ability of attackers to brute force accounts, since an attacker would need to break both parts. I doubt that this balances out the usability issue though.

  • 52
    Depending on how this is implemented, the attacker might be able to break the two parts separately. The system would have to prompt for both passwords even if the first one were wrong, or the second password prompt would reveal that the first password had been correctly guessed. In this case, splitting into two passwords would improve attackers' ability to brute-force accounts. Commented Jan 25, 2016 at 15:34
  • A good real-world example of what @MontyHarder suggests can be seen with the known vulnerability of WPS PINs. And, even if you implement rate-limiting, you're still probably to be storing the two parts separately in your database - which increases risk if the attacker gains access to the DB.
    – Bob
    Commented Jan 27, 2016 at 5:48
  • @MontyHarder "The system would have to prompt for both passwords even if the first one were wrong" IN A CONSTANT AMOUNT OF TIME.
    – Aron
    Commented Jan 27, 2016 at 10:51
  • 1
    @Bob: A better example might be LM hashes – it's a password hashing algorithm that also has the identical problem.
    – grawity
    Commented Jan 27, 2016 at 14:40
  • @Aron Either a constant amount of time or such that any variations in the time are orthogonal to whether the first password were correctly entered, to avoid leaking information about the first password's validity. But I was starting to run out of room to make my point and decided to omit that part. Commented Jan 27, 2016 at 18:49

I've seen banking sites where a user is required to answer 2 security questions(randomly chosen out of a set of 5 pre-decided questions, at the time of account creation).

The point is, if one password can be compromised(either on user's front or because of website loopholes), how much likely is that the second password will remain safe? If the website can employ better encryption algorithm for one of the passwords, why not employ it for a single password?

I guess a better option is, the user can concatenate the 2 passwords to make a much stronger password. For example, setting 2 passwords "aBcD" and "eFgH" can be cracked within minutes(or hours), but a password like "aBcDeFgH" would require much more time to get broken from a hash.

  • 9
    Exactly that. One good password is way better than two weak passwords. Commented Jan 25, 2016 at 13:34
  • 2
    Isn't this exactly what happened with WPS that made it so infamous: the first four digits were evaluated independently of the last four?
    – lc.
    Commented Jan 25, 2016 at 17:35
  • What about hashing aBcD with seed of eFgH?
    – ave
    Commented Jan 26, 2016 at 8:49
  • 1
    @ardaozkal Most of the time, seeded hashing is just hash(pass+seed). So hashing "aBcD" with seed "eFgH" would, in most systems, be the same as hashing "aBcDeFgH" except less secure because the hacker can choose their own seed, thus making rainbow tables easier.
    – wizzwizz4
    Commented Jan 26, 2016 at 18:51

A disadvantage not mentioned yet in the other answers, is that such a scheme will probably defeat some popular password managers.

Since you should be encouraging your users to use password managers, so that they can use long completely random sequences of characters as their password, this is probably a bad idea.


Such a system could have some benefit if (1) the two passwords were chosen independently, and (2) the lockout policy for wrong attempts on the second password were stricter than that for the first.

Having a fairly strict lockout policy for incorrect password attempts can greatly improve resistance to brute-force attacks, but also greatly facilitates denial-of-service attacks. If an account will get locked out for 30 minutes after three incorrect password attempts, anyone who knows the account ID can make it very difficult for a legitimate user to get in by submitting three false login attempts every 30 minutes.

If there is a two-part password, and the lockout is only applicable to entry attempts where the first password is correct, then it would be necessary to breach the first password in order to even conduct a denial-of-service attack. Further, searching the key space for the second password would be much slower than for the first. Further, while notifying an account holder of repeated incorrect primary passwords would yield many false alarms the account holder couldn't do anything about, notifying the account holder of incorrect secondary-account passwords could be much more useful. If Adam Baker receives notification that an attempt was made to log into his account with a correct primary password but incorrect secondary password and Adam himself wasn't responsible for that access attempt, he'll know that his primary password was breached and may be able to take action before the crook can breach the second password.


Using 2 passwords is not better than one password as the main issues with passwords are not addressed. 2 passwords will not defeat key-loggers, or prevent crackers from successfully recovering passwords using rainbow tables. Also, 2 passwords are harder for people to remember than one.


An additional weakness of this password system is that it renders the system far more vulnerable to brute-force hash cracking by techniques such as rainbow tables. This could happen if your password hash database was leaked in some way.

If an attacker has gained access to the hashed password database, the two passwords would have to be stored separately as two hashes (since storing them together prevents direct comparison of each password). This therefore greatly reduces the entropy of each hash, allowing an attacker to easily crack both hashes far faster than it would take to crack one single hash of the concatenated passwords.

If the two passwords are of equal lengths and are drawn from the same pool, the time taken to crack two hashes in isolation takes half the exponential time (i.e. if cracking the full hash takes 1,000,000,000,000 tries, it would only take 1,000,000 tries to crack each sub-hash).

A good case study of this is the NTLM hash used in Windows XP and below, which has a design flaw very similar to the password system mentioned. A relatively strong password is split up and stored as two separate hashes, which makes the entire password significantly weaker.

Even computers of 10 years ago could easily crack the vast majority of NTLM hashes in a few days without using rainbow tables, and with the tables, the cracking is almost instantaneous.

enter image description here


I've seen this done with the second password being (1) used not to log in, but to make a major action within the account, e.g. a monetary transaction; (2) of different type from the first password, e.g. first password is constant text, second password is from 1-time pad or SMS message. Used that way, it seemed like a good idea.

This could be used to log in, if the account contains highly sensitive data and logging in is used not that often, but this way it alredy seems like not that good idea.

Using one constant text password to log in, and another constant text password to perform major actions might make some sense in some circumstances, but much less than with one-time secondary password.

Using two constant text passwords just to log in offers very little benefit over one longer password, and also have some major drawbacks, as per the other answers.


A common method used by banks is a pin number and a password. then random characters in a random order are asked for e.g. enter number 3 1 2 of your pin number and enter characters 3 9 5 of your password... this makes it harder for keyloggers to get any information but this requires a method of 2 passwords to ensure random attacks cannot happen, along with a fail2ban, respectively.

so the answer is no, its not a bad idea but nothing is a bad idea, its the implementation which makes it great or a mistake.

  • 6
    Some ideas are bad ideas, it's not just the implementations that can suck - e.g. WPS.
    – domen
    Commented Jan 25, 2016 at 12:24
  • @domen haha ok maybe im being a bit optimistic
    – TheHidden
    Commented Jan 25, 2016 at 12:32
  • 3
    This is a bad idea. Being able to compare parts of a password implies unsafe server side password storage. Commented Jan 25, 2016 at 15:02
  • 1
    @NeilSmithline implies but does not define. I think when alot of banks do it, large banks im sure its probably safe but I could be wrong and my money could disappear any day now. alot of government and money holding organisations use this method, its not new nor unique but actually tried and tested.
    – TheHidden
    Commented Jan 25, 2016 at 15:08

Neither are completely fail safe because usually the one trying to access the account has other means to obtain the user made password then giving them access to the two step authentication password which frankly is pretty easy to get because it uses a back up phone or alternate email with that being said I believe one longer password with random character other than just letters and numbers


Businesses call the arrangement "two-factor authentication," but it boils down to having one password that you make up for yourself and another password that you get from someplace else. This is the computer equivalent of the security provided by a safety deposit box: Your key alone can't open the box, and neither can the bank's key; both parties need to use both keys at the same time.

  • 8
    This is not two-factor authentication.
    – Ángel
    Commented Jan 25, 2016 at 22:08

You must log in to answer this question.

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