107

With port knocking, you have to "knock" on specific ports in defined order to expose a port on which service is running.

How about password knocking? For example you have three passwords: A, B and C. None of them is correct by itself, but entered one-by-one in this order they will grant you access.

Some scenarios to make this idea clearer:

Scenario 1.

  • You: Password A.
    • Server: Invalid password.
  • You: Password B.
    • Server: Invalid password.
  • You: Password C.
    • Server: Password accepted.

Scenario 2.

  • You: Password A.
    • Server: Invalid password.
  • You: Password C.
    • Server: Invalid password.
  • You: Password B.
    • Server: Invalid password.

Scenario 3.

  • You: Password A.
    • Server: Invalid password.
  • You: Password B.
    • Server: Invalid password.
  • You: Password B.
    • Server: Invalid password.
  • You: Password C.
    • Server: Invalid password.

Scenario 4.

  • You: Password A.
    • Server: Invalid password.
  • You: Password A.
    • Server: Invalid password.
  • You: Password B.
    • Server: Invalid password.
  • You: Password C.
    • Server: Password accepted.

I can't think of any drawbacks of this method over regular single password login. Moreover, it makes dictionary attacks exponentially harder with each added password.

I realize it's security by obscurity and doesn't abolish the need for strong passwords. Password sequence itself is as strong as a concatenation of passwords used. Added security in this method comes from unexpectedly complex procedure.

Is it a good idea? Is it a better idea than classic password?

gronostaj
  • 1,290
  • 2
  • 10
  • 17
  • 54
    From users perspective it is very fustrating. if say you misspell one of the passowrds. It will get difficult to know which went wrong A,B or C. – Nikitesh Kolpe Feb 19 '15 at 07:46
  • 65
    What does this method obscure that traditional passwords don't, and why do you think it's more secure? It seems to me that it's no more secure than if you just had a single password that was the concatenation of `A`, `B`, and `C`. At the same time, I don't see why it would be any less secure. – user2752467 Feb 19 '15 at 08:01
  • 20
    @Justin unless the attacker knows that I'm using this kind of additional protection he will try each password only once and will most likely never find correct password sequence. – gronostaj Feb 19 '15 at 08:27
  • 1
    comments are not for extended communication. – Rory Alsop Feb 23 '15 at 19:48
  • 8
    @RoryAlsop I'm a regular user on StackOverflow, but new to this site. I'm confused by your response, and wondering whether it's applicable to all SE sites or just this one. From what I can see, your comment followed exactly 3 comments that appear (to me) to be on-topic and contributing to the discussion. That seems different than is expected on SO. Am I missing something? (Note: not a sarcastic question at all.) – mbm29414 Feb 25 '15 at 18:33
  • 1
    @mbm29414 I'm confused as well, and a normal user of SA. The best I can figure is that some comments were deleted, and Rory Alsop left a comment saying as to why. As to whether or not this is a good idea over a classic password, it would probably depend on your "knocking" system. Is it accumulative until pass, or does it reset each time? Basically, it won't let you in until you have A,B, and C in that order, and A, B, B, C should not work. I'm not sure how you would implement that, but if you're going to do it, that seems the most secure route. – kayleeFrye_onDeck Feb 25 '15 at 19:04
  • 4
    @gronostaj one should not rely on [security through obscurity](https://en.wikipedia.org/wiki/Security_through_obscurity) – tar Feb 25 '15 at 22:14
  • If your aim is to prevent dictionary attacks what's wrong with a password policy - http://security.stackexchange.com/questions/3248/recommended-policy-on-password-complexity Also, if you already *have* a proper password policy that's resistent to dictionary attacks (that's the whole point of the policy) then why the need to add this extra obscure "password knocking" procedure. – Brandin Feb 26 '15 at 11:16
  • 1
    As @tar obersved, you should not rely on security through obscurity. And by the way, it wouldn't be very much obscured; how are your user going to know to keep inserting passwords? Because you tell them. Now this does not seem a very difficult information to obtain after all! :) – Ant Feb 26 '15 at 16:31
  • 9
    A regular password is just 'character knocking'. You have to put some characters in the right order... – Gusdor Feb 27 '15 at 08:52
  • 2
    mbm - many, many comments were deleted. – Rory Alsop Feb 28 '15 at 17:21
  • If you're looking for enhanced security, it would be better to use a two-step authentication method, e.g. send an authorization code to a user's mobile device or email address. – Jason C Mar 01 '15 at 00:40
  • Possible duplicate of [Port Knocking is it a good idea?](https://security.stackexchange.com/questions/1194/port-knocking-is-it-a-good-idea) – techraf Mar 10 '17 at 02:12

17 Answers17

161

The system outlined in the question is actually weaker than simply requiring a single password of length A+B+C, because it permits a class of attacks that can't be used against single passwords:

Say your three-password combination is E F G. An attacker can send the passwords A B C D E F G, making five attacks (A B C, B C D, C D E, D E F, and E F G) for the price of two. The general term for this is a de Bruijn sequence, and it lets you attack any state-based system (such as a digital lock) using far fewer tries than there are possible combinations.

Mark
  • 34,513
  • 9
  • 86
  • 135
  • 13
    +1, none of the other answers emphasize that this scheme is weaker than a normal password of the same (total) length. – 2012rcampion Feb 20 '15 at 15:27
  • The OP's scheme doesn't have a security hole by definition since they didn't mention implementation, although I bet most people would overlook this. +1 for noting this. However, if you implement it to reset the variables for the last three passwords every three passwords (so password1, password2, password3, evaluate, clear, repeat), it could be more secure (from an obscurity perspective). – Anonymous Penguin Feb 23 '15 at 00:10
  • 14
    The post mentions that `A A B C` works, meaning it's got a rolling window of "last three passwords" rather than resetting after a group of three. This is sufficient to make it vulnerable to sequence-based guessing. – Mark Feb 23 '15 at 00:24
  • 4
    I disagree that the scheme is weaker. De Brujin sequence gives 3x speedup, however adding two splits into the password gives us `(|A+B+C| over 2)` slowdown. (Which is 28 for password of 6 characters) – Erbureth Feb 23 '15 at 15:14
148

From a raw security perspective, your password is simply "A B C", and the relative strength of the password is calculated accordingly.

From a user perspective, this is arguably too difficult to be usable. The server isn't giving any indication as to the current state (is it looking for the second password yet?) and therefore the user can't tell which password to provide.

From an defense perspective, there's a small amount of value here. Password attacks become a bit more complicated to carry out and existing attack tooling will have to be re-written to accommodate this weird scheme. That may be enough to convince an attacker to move on, but if you're an important target, then it won't help at all.

tylerl
  • 82,665
  • 26
  • 149
  • 230
  • 4
    I concur. Security needs to be balanced with usability. Your idea may frustrate legitimate users (the people you are looking to protect), since it makes more difficult for them to access the services behind the password. – gerlos Feb 19 '15 at 09:03
  • 85
    Note also that if the server DOES give an intermediate status "right so far", then the passwords are actually weaker than just "A B C". Isn't this what happened to WPS, or was it some other protocol? – kutschkem Feb 19 '15 at 09:28
  • 'From a raw security perspective, your password is simply "A B C"' --> I disagree strongly. Since you have no idea which one you failed, and if you did so, you may be needing 10yottabytes to store the first password. And you won't reach the point of finding it. If you limit it to 30 chars, the password might be 31 chars long. And you wasted your time. Or one might be 10, the next one 50 and the next 1. But you won't know. – Ismael Miguel Feb 19 '15 at 18:48
  • @kutschkem that is exactly correct. – tylerl Feb 19 '15 at 19:05
  • 8
    @IsmaelMiguel Which is exactly the same situation as trying to guess a single password "ABC" and not knowing which individual character in it was wrong, or if all of them were wrong, or.. It's tempting to think that this helps, but it doesn't. – Chris Hayes Feb 19 '15 at 19:09
  • 1
    @IsmaelMiguel No, the attacker will just try ["A","A","A"], ["A","A","B"], etc., until he gets to ["A","B","C"]. He doesn't have to try every combination on the first field before moving on to the second. If I told you my password had three spaces in it, you wouldn't be paralyzed trying to figure out what came before the first space. You'd just try the shortest possibilities first. – tylerl Feb 19 '15 at 19:09
  • True, but you don't know that. The password `A` could very possibly be "staples corn fried potatoes", which would take you a **VERY** long time to guess. – Ismael Miguel Feb 19 '15 at 19:42
  • 11
    @IsmaelMiguel in other words, long passwords take longer to guess. – tylerl Feb 19 '15 at 20:15
  • 4
    Actually, it's sort of equivalent to something like A+"[ENTER]+B+"[ENTER]"+C, since simply typing ABC into the first prompt presumably won't work. The number of possible guesses would be the same as ABC*(LengthOfABC-1)*(LengthOfABC-2) if the scheme prohibits zero length passwords at any step. – psr Feb 19 '15 at 20:22
  • Still, you have a few characters before `A` (65, if I'm not mistakened). Any of those may be part of the password. – Ismael Miguel Feb 19 '15 at 20:25
  • 4
    @IsmaelMiguel You may continue to disagree all you like, but as members of the community have attempted to explain to you through *several* different approaches, the strength of the proposed scheme is virtually indistinguishable from concatenating the individual passwords. – Stephen Touset Feb 20 '15 at 00:55
  • @StephenTouset I accept that. To me, in my mind set, seeing from another point, this is stronger than concatenating the passwords and trying to find only one. In fact, I would say that it is almost impossible to find the 3 passwords, depending on their security individually. – Ismael Miguel Feb 20 '15 at 09:10
  • 3
    But that is precisely mathematically equivalent to having those three passwords concatenated. If your "first" password is "123", your second password is "456", and your "third" password is "789", an attacker must spend the same amount of effort as if they were attempting to guess the *single* password "123456789". With the argument that they might not know that this is your scheme, that is true of the password itself; the attacker does not know that it's a nine-character password (or, equivalently, three three-character passwords). They must try all combinations until they find the right one. – Stephen Touset Feb 20 '15 at 09:20
  • 28
    To be more clear, if you consider typing this password in, your effective password is *literally* `123456789`. You could argue that an attacker wouldn't know to hit enter at those precise locations, but that argument could be made for *any* character that could be typed there. This would be no different than if your password was instead `123|456|789`. Ask yourself, when considering the literal act of sitting at a keyboard and typing in this password, what somehow grants the Enter key additional security over the `|` key. – Stephen Touset Feb 20 '15 at 09:25
  • 2
    @StephenTouset I partially agree with you, in theory `123456789` is equivalent to `123|456|789`, but in practice the first schema requires 3 requests to the server, while the second only one, even if everything is super fast the first option takes more time, thus it adds some extra security (of course I wouldn't use this either) – Felipe Pereira Feb 20 '15 at 17:25
  • 4
    Something like `bcrypt` is a far better way to slow down an attacker, as that also helps even if the attacker has your hashed passwords. Regardless, the latency of two extra requests to the server could be trivially simulated by calling `sleep`. – Stephen Touset Feb 20 '15 at 21:49
  • @StephenTouset I also stated that this wasn't a good approach, just saying that you can't compare a request/validation step to a character on the password, also, were would the `sleep` be? – Felipe Pereira Feb 26 '15 at 01:01
38

I'm going to address a few points here.

First off, assuming that the attacker doesn't know the password scheme is a bad assumption, and you're correct that it's security through obscurity. If every user can learn this login scheme, then the attacker can too. Because of that, the knock is no better than if there was just a single password ABC.

You might think, "Doesn't having more passwords increase the number of brute force guesses exponentially?" The answer is no. Consider an alphabet of length z, and three passwords of length a, b, and c. The number of possible passwords for each is, respectively, za, zb, and zc. If you're to try all possible values for each password in every possible order, you'll need za * zb * zc guesses, which is equal to z(a + b + c). It just so happens that the length of the single password ABC is a + b + c, so the number of guesses required is also z(a + b + c).

There's also the design concern that users will be confused and/or frustrated by this system, especially if they're having trouble remembering their passwords. People have enough trouble remembering one password for each site they visit (and that's why many people reuse passwords). Three passwords would be even harder to remember, and I wouldn't be surprised if some of your users used the same string for all three.

Requiring three form submissions to log in will certainly slow down a brute force attack, but you could just as easily achieve that by adding a delay in the server-side password verification.

user2752467
  • 971
  • 7
  • 11
  • 1
    Agree with your other points except that it is more likely for the attacker to miss the sequence using brute-force if he does not know the scheme. – Question Overflow Feb 19 '15 at 09:06
  • 2
    A normal dictionary attack will most likely never enter A B C. The reason is, that if A or B or C are tried once without success, they will never be tried again! – Josef Feb 19 '15 at 10:45
  • You're all right that I was wrong about the scenario where the attacker doesn't know the scheme. I've removed that sentence. – user2752467 Feb 19 '15 at 17:54
  • I agree with your update, but I'm pretty sure that, due to the complexity, you will need to go from '!' to '~' (ASCII chars) to AT LEAST find one possible combination. Failing one password will revert to password `A`. And you will failt too often and you won't know exactly which failed. For each char you have to go through '!' to '~' a billion times. Doubled for each password. You have 3 entry points, each may be different and will revert if you fail one. Either you know the passwords or you will be locked forever. Until 4 quadrillions years have past (or much more). – Ismael Miguel Feb 19 '15 at 18:45
  • I don't feel like doing the math to figure out _exactly_ how many tries or how much time it would take, I can't because I don't have actually numbers to play with, and it's not relevant anyways. I leave this exercise in hopes of convincing you that it's not as difficult as you think: out of all the possible values of _ABC_, how many of them have the correct value for _A_ as a prefix? – user2752467 Feb 19 '15 at 19:04
  • You don't have to convince me. I keep wrapping my mind to try to find a shortcut, but all I could find was a major headache. I think you are hitting the right tree. I won't disagree with you because there is nothing to disagree, except the dificulty it is to guess the passwords. – Ismael Miguel Feb 19 '15 at 19:41
  • 1
    You can think of it as having the password substrings being from an alphabet of length `z`, and the "concatenated" password being from a superset of that alphabet, specifically the entire alphabet plus a single delimiter (which represents sending the substring). – corsiKa Feb 19 '15 at 21:32
  • 1
    @corsiKa: Plus the additional constraint that the "concatenated" password must have exactly two instances of the delimiter, plus perhaps constraints along the lines of "each subpassword must contain at least one special character" . . . the end result could be that you actually end up with *fewer* possible trios of passwords than if it were simply one long password. – ruakh Feb 20 '15 at 22:01
19

It's security through obscurity -- if widely adopted, attackers will just try three times. At which point you might as well just have a single password but set a longer minimum password length to ensure it's as long as three separate passwords concatenated.

Mike Scott
  • 10,134
  • 1
  • 28
  • 35
  • 7
    +1 even though the OP states `I realize it's security by obscurity`. It's worth adding that this is _only_ security through obscurity, with no benefits over any other method. You could swap the user name and password fields and keep the labels the same, or rename the password field `birthday`, there are a million options that will confuse users in the name of 'security'. Clearly the OP, while understanding that this _is_ security through obscurity, doesn't understand why that's bad. – Shep Feb 20 '15 at 22:59
  • 4
    As for _why_ this is bad. If I were forced to use such a system, the first thing I'd do is write a password entry script to automate away the annoying interface. Then I'd probably check the script into my public github repository. – Shep Feb 20 '15 at 23:06
11

This is indistinguishable from your password simply being A || B || C.

Stephen Touset
  • 5,774
  • 1
  • 23
  • 38
  • 3
    If attacker doesn't know I'm using "triple password" he will try each password only once and most likely will never find the correct sequence. This is not the case for `A || B || C`. – gronostaj Feb 19 '15 at 08:25
  • 4
    If an attacker doesn't know your password is `A || B || C`, s/he will have to try each possible password once and most likely will never find the correct sequence. So yeah, it is the case. If an attacker has `A`, `B`, and `C`, you've lost regardless. – Stephen Touset Feb 19 '15 at 08:29
  • 9
    @Stephen your answer is not very clear to those who dont already know this, can you please elaborate a bit to make it a proper answer? – AviD Feb 19 '15 at 15:21
  • Even if the attackers knows the scheme, he has to try every possible password 3 times. If the password `A` is `123`, password `B` is `123` and the password `C` is `1234`, to reach that password, you have to try `0|0|0`, `0|0|1`, `0|0|2`. And this is made worst since the server won't tell which one is wrong! The password could be `0|1|0` and you would take a stupidly gigantic ammount of time to find it. – Ismael Miguel Feb 19 '15 at 18:22
  • @IsmaelMiguel The part you claim is being made worse, is simply the same as using a much longer string. Example: suppose A,B,C can each be a one digit number, 0-9. Then there are 1000 possibilities for A,B,C. The same as for a 3 digit password. – Jean-Bernard Pellerin Feb 19 '15 at 20:55
  • @Jean-BernardPellerin There is also the addition of the separator characters. It is ABC. So strictly speaking injects 2 separator characters into the sequence. Concatenation doesn't simulate the *end* of A and *start* of B etc. – Shiv Feb 19 '15 at 23:33
  • 4
    @AviD I feel like this result must be patently obvious. Your password is *literally* now `A B C`. They are now simply concatenated by using the Return key. – Stephen Touset Feb 20 '15 at 00:58
  • 2
    @StephenTouset I don't disagree, but the fact that it is being asked - and some comments - proves otherwise... FWIW I had already +1'd you... :-) – AviD Feb 20 '15 at 08:11
  • 6
    If I have the passwords 3 passwords "AB" "BC" "CD", the concatenated password is ABBCCD. This is provably not equivalent hence this answer is incorrect. "A" then "BBCC" then "D" is a different wrong password in this scheme for example but the concatenation is the same. The separators are the crucial difference that makes the equivalence false. – Shiv Feb 25 '15 at 00:12
  • 1
    It's not, in that A\n || B\n || C\n is in fact distinguishable from A || B || C – Xander Mar 01 '15 at 01:00
9

Two-factor auth is more user-friendly yet more secure.

Without, one password is still hardly less secure than password knocking.

An attacker who can find your password is likely to find out about your knocking scheme as well.

Choosing to knock is like choosing an algorithm. Consider it public.

Though passwords are security by obscurity, they can be replaced by completely different ones very easily.

That said, there are schemes that are somewhat similar to your "knocking" but a bit more useful:

  • Randomly requesting one out of multiple secrets (passwords, phrases, iTANs...).
    This is much quicker than entering all of the secrets, and is more secure because the attacker only gets to know one secret at a time (which can be invalidated after use).
    The chances of the attacker being able to authenticate correlates with the relative number of secrets they know. Still, it requires the user to know all secrets and their order.

  • Input Timing, i.e. analyzing the times between and for all password characters while the user is typing.
    This is harder to find out about and to fake than knocking and has been researched a couple times IIRC. Drawbacks:

    • Timing varies slightly each time a user enters the password, though it may still be enough to distinguish users
    • Timing may even change entirely when the user chooses to enter it differently, e.g. during the initial phase after choosing the password (the user is still learning to enter the password), or when they cannot enter it the way they usually do (injuries, holding a sandwich in one hand...)

Security by obscurity is good when you can quickly modify your obscurity scheme, i.e. "change the maze" with little effort, rather than the concrete its walls are made of (make sure the maze cannot be bypassed).

Arc
  • 652
  • 5
  • 11
  • 9
    Dude, overuse of bold makes this nearly unreadable. – xorsyst Feb 25 '15 at 11:02
  • 1
    I wouldn't say passwords are security by obscurity. Every secure system needs some "thing" that you need to obtain entrance - either something that you know, you possess or you are. To classify something as security by obscurity you need to look at the algorythm and not at the "key". – nsn Feb 26 '15 at 12:17
  • 1
    I don't define the words. From [Wiktionary](https://en.wiktionary.org/wiki/obscurity): 2. _The state of being unknown; a thing that is unknown._ 3. _The quality of being difficult to understand; a thing that is difficult to understand._ The latter is what people usually refer to in a derogatory manner when speaking of "security by obscurity", but anything that is difficult to "grasp" can be considered obscure. – Arc Feb 27 '15 at 18:10
8

The concept of port knocking does not really apply directly to logging into websites. At least not in the sense that you have suggested. With port knocking, you connect to different ports in a certain order to open the desired port. In your example, you are putting all the passwords into one site. As others have pointed out, this isn't really any different from putting all the passwords together. Unless all the passwords you use are very long, you might as well just concatenate them and use one password. The obscurity of this method is also not so helpful, because someone will have to build it and someone will have to know how to use it, which is enough for an attacker to find out how it works. Also, you just explained it to the world.

Instead, maybe you could use different websites to represent different ports. Let's say you are trying to log into website D. When you connect to website D, it won't even display a page unless it can see that you have logged into websites A, B, and C, correctly and in that order. This way the attacker would not only have to crack the different passwords, but they would have to be done on 3 different sites, and used in the right order to even access site D, where another password would be required.

This is still relying on a certain amount of obscurity, but it is more distinguishable from simply splitting up a password on one site.

fooot
  • 249
  • 3
  • 6
  • +1 for addressing the core of the problem: the proposed scheme for password knocking *does not* replicate the scheme used for port knocking, thus the presumed benefits don't transfer. – Jason Apr 21 '16 at 14:32
6

Positive

  • It would fool standard brute-force attacks. Automated attacks from botnets or simple tools would not work out of the box.
  • It might be possible to fool a keylogger this way. In the logs it would look like the user remembered the password on the third try. If the attacker uses this password it would not work. But only if he does not know or guess what's going on. But he does own you anyway in this case.
  • The user is forced to use multiple words => longer password.

Negative

  • Too complicated for a normal user.
  • Like port knocking, it is partly security through obscurity. If the attacker knows he can adapt the attack.

Total

Like port knocking it does add only a small advantage against simple attacks. The main benefit would be longer password and that can be enforced more easily be password rules.

Anyway, if your users do not mind it is something you can do. In the end, every security feature counts. But I would not advice to do it.

Peter Mortensen
  • 885
  • 5
  • 10
PiTheNumber
  • 5,414
  • 4
  • 21
  • 36
  • 3
    Well, the brute force attacks that it would fool are somewhat pointless anyway. Given a reasonable login rate limit (like, 1 per second) brute force is pretty futile. An offline attack on a stolen database, on the other hand, won't be held back since it's obvious that three passwords must be used, and what their hashes are, so the difference is neglegible. – Damon Feb 19 '15 at 18:23
5

Just a note: this methodology is already used in password-recovery schemes in some parts of the industry. If you forget your password, you can use your e-mail address to initiate a sequence of personal questions to recover your password (though many times it is just one question). It is made more palatable to the user, by usually limiting the context to a sequence of well-chosen questions that provide the user with an opportunity to use (hopefully) secret but well known answers.

Also, some of the better banks provide an additional set of security questions if they do not recognize the computer you are logging in from (in the same vein as the aforementioned password recovery scheme).

For example:

Enter your password:  *****

Your computer is not recognized, please answer the following additional questions:

What city did your mother grow up in?  *********
What is your favorite movie? *************

This can enable savvy users to provide fairly obscure answers to a range of questions which they choose, while still allowing for an easy-to-remember sequence of 'passwords'. Of course, typical users might still use easy-to-guess answers for the "unrecognized computer" questions, but the onus has always been on the user to provide good passwords, anyway.

enter image description here

Ogre Psalm33
  • 195
  • 1
  • 2
  • 9
  • 1
    Of course, adding security questions, the answers to which are essentially passwords whose entire purpose is to be easily guessable by the user, just makes your entire system weaker than if you just had the one password. (Assuming a typical user that follows directions in the UI, and won't choose random answers.) The burden is shared between the user, and the designer – if your system is only secure with a good backup password, at least instruct the user to choose one! – millimoose Feb 21 '15 at 03:38
  • Any bank that still uses security questions as their only backup might be "better" than some other bank, but security-wise, it's terrible. Mine actually impressed me by gradually transitioning everyone to requiring authenticators, and voice fingerprinting for phone support. – millimoose Feb 21 '15 at 03:43
  • Multi-factor authentication is definitely a better option, but sadly the majority of banks are not there yet, at least as far as I've sampled. But even my wife, who is not a technical person by any means, knew enough (without me even telling her) that when she chose the security question "Favorite Pet?", that she should *NOT* put our dog Fido as the answer (she uses a different harder-to-guess, non-pet-related answer that she can easily remember). Many people are smarter than we give them credit for, but unfortunately, I must concede, many are not. – Ogre Psalm33 Feb 23 '15 at 13:25
  • I must also point out, a subtle difference in the "back up passwords", so to speak. Their purpose is to make the answers easily guessable by a *particular* user, but hard to guess by others (sadly not everyone implements them that way: "Favorite color?" *REALLY???*) – Ogre Psalm33 Feb 23 '15 at 13:26
  • i personally hate that kind of system, first of all i never remember WHAT question I've choose. Unless i write them down, or pick them always the same. In the end i put random data, and this only increase the attack vector. – Lesto Feb 23 '15 at 22:27
  • @OgrePsalm33 Well, once you tweak the design to be more secure, you're not really talking about the rightly maligned security question. (I.e. the kind that actively prompts for information that could probably be found by looking at their Facebook page.) And my point was that the design of a security feature should not involve the user having to do the opposite of what they're told. (E.g. your wife.) My personal favourite so far is the OS X password hint, where I use synonyms of the words in my passphrase, which should be enough to jog my memory; however that might not be appropriate for a bank – millimoose Feb 25 '15 at 05:30
5

PROS: This system does share some benefits with two-factor authentication.

1) Most browsers and password saving systems do not support it, so will remember only one of the passwords at most. So it at least won't be stored in plaintext somewhere.

2) People who use the same password everywhere will have to use at least two passwords which are not shared with other sites.

CONS: The system, however, is overall flawed, and I'd argue it is worse than single-password authentication.

1) Because their preferred, password-protected password storage system that they use for the more important passwords cannot be used, odds are they'll use something less good for this one password. Post-it, text file, whatever.

2) Others have claimed that this is as strong as the password "ABC". It is not. I would say that in the worst case, it is only as strong as the password "A".

This is because I (and the typical user) would use the passwords "password1", "password2", "password3" This password generation system gives me the benefit that I can ctrl-c, ctrl-v the password and then just type the number.

If I cannot use similar passwords, then you have reduced the scope of possible passwords that I can have: rather than as secure as ABC, you now only have the same security as ABD where A!=B!=C: you've made the cracker's job easier by reducing their search domain.

And I'd still choose whatever predictable sequence that the password entry script permitted: "Jan", "Feb", "Mar" perhaps.

And since I'd be using a natural sequence, this is likely to be the order that a password cracker would have in the dictionary, so a password-cracking machine will naturally try those passwords in the correct order and walk right in. Any cracker knowing your system absolutely would order their dictionary in this manner.

3) The other factor that reduces security is that to change the password, you now need to change three different fields. This would discourage many from changing their passwords.

4) This is terrible, terrible user experience, as others have noted. Unless you have a captive audience (employees, students, etc), you will lose custom through this user-hostile approach.

Dewi Morgan
  • 1,340
  • 7
  • 14
3

As others have stated, this is equivalent to just having a password that's equivalent to A\nB\nC or the like. However, there is one advantage I can think of to this scheme: it helps to reduce phishing-type things; if a system accepts the first password in lieu of accepting the others, then you know that the system is compromised and simply logging your username and password.

However, in that case it's better to just attempt login with a random password before attempting login with your actual password; otherwise you've just compromised a good chunk of your password since now the first third (roughly) has been logged by the compromised system.

fluffy
  • 1,352
  • 1
  • 8
  • 10
2

I don't think it's even security through obscurity as some have said—the three password login is presented publicly, no? Sure it will take some work tweaking a few tools, but nothing too difficult.

As for the brute-force complexity. The number of possibilities are the same as having one single password with length A + B + C. So for this reason the only defensive you get with this scheme is frustrating the attacker a little at first. Furthermore, if the scheme became common, then standard tools would quickly adapt.

Peter
  • 132
  • 4
  • 3
    The 3 password login is not presented publicly. It looks like a standard userid, password login. Except instead of credentials {userid, password}, you have credentials {userid1, password1, userid2, password2, ...}. You enter userid1, password1 and the system "rejects" you, but secretly records you passed hurdle 1. You enter userid2, password2 and the system "rejects" you, but secretly records you passed hurdle 2. When you pass the last hurdle, the system lets you in. Having said that, I am not enthused. – emory Feb 19 '15 at 17:36
  • @emory, sure, but what I mean to say is that users of the system are clearly aware of the scheme—thus so will attackers. – Peter Feb 19 '15 at 20:57
  • 2
    If the user base is small (e.g., just me) then password knocking is obscured but still not recommended. If the user base is large, then password knocking is horrible. I implicitly assumed the user base was small. – emory Feb 19 '15 at 22:13
1

As many have mentioned, for dedicated attack purposes, it is no stronger and no easier/harder to remember than a concatenation of passwords. However, there is some operations security (OPSEC) value to be had which is independent of password strength. Not much value, mind you, but as someone who spends a lot of time on the Worldbuilding Stack Exchange site, my imagination ran wild.

Consider if you want a service to not only be restricted to authorized users, but you want to prevent someone from accidentally stumbling on its existence. This is no longer a simple entropy problem, but rather a spy-vs-spy information theory problem. Your job is now to minimize the signal-to-noise ratio (SNR) of anyone glancing across your password input. This is now unrelated to password strength.

One approach would be to set up a dummy behavior. Make it look like it is a log in for a different system. Only accounts with the correct privileges are redirected to the meaningful content. You could even let others sign up for your dummy project to let people poke around and satisfy their curiosity.

However, we're talking spy-vs-spy now. Someone's going to realize that James Bond really isn't all that interested in a forum discussing the latest trends in rubber duckies, and start prying. James Bond is good at not revealing information, but at some point, with a gun held to his [latest] girlfriend's head, it's going to be suspicious if he doesn't reveal his rubber-ducky-forum password to Dr. NoGood. Dr. NoGood's no fool; he'll figure it out.

So we set up James with two passwords. One lets him into his normal rubber ducky forum, the other into the top secret nuclear missile simulator. We can't ignore real-life password security here. His nuclear missile simulator password is going to have to be long: as long as the concatenation of your three passwords. His ducky password is probably shorter. Good thing too, because someone has watched him log into his ducky account before. They know how many characters to start brute-forcing. We don't want them to accidentally find the secure password before we find the ducky one.

So, given that it's still secret that the missile simulator exists, returning "invalid password" part way through will hopefully discourage brute-forcers from continuing. Plus you can do a huge climactic reveal when James "types his password wrong twice," before the wall next to him suddenly creeks open to reveal the vault beyond.

Community
  • 1
Cort Ammon
  • 9,216
  • 3
  • 26
  • 26
  • FYI, the late Truecrypt system allows you to create hidden partition where one password decrypt the drive to produce important-looking files that you don't actually care about and a second password to decrypt a hidden partition for the data that you truly need to keep secret. This is done so you can have plausible deniability. – Lie Ryan Feb 20 '15 at 01:11
1

"The fewer the moving parts, the less there is to go wrong."

In addition to not providing any notable benefit, this idea is more complex to implement than a single password. As such, there are more points of potential failure. For instance...

Depending how it was implemented, it might allow a denial attack wherein Malcolm sends password X at regular intervals. If he times it right such that he interrupts a legitimate attempt, the system receives A X B C and denies you entry. Similarly, if he times sending password C right after you've sent A B then the system lets him in and not you.

A response-timing attack might be able to figure out that A was the correct first password in A B C where it would not notice that D was the prefix of single-password DEF.

Vynce
  • 111
  • 2
0

To add to all the other great answers, this type of password protection scheme would not provide any protection against keyloggers or man in the middle attacks. Since you would still be putting your password in within a sequence, the keylogger can replay your actions and still gain authorization. 2-factor authentication as suggested by @Archimedix would be the most effective way to mitigate this.

PressingOnAlways
  • 133
  • 5
  • The keylogger would be confused because of the submission of the password. The keylogger would have to know about the scheme in order to not be fooled by it. So, as long as "Obscurity" was maintained, it would work. – schroeder Feb 20 '15 at 22:16
  • 1
    Mind you, a keylogger that reports the same triplets of submitted passwords over and over again would work to dispel the obscurity. – millimoose Feb 21 '15 at 03:50
0

As others have mentioned, functionally, this is the same as one long password. To make the implementation less confusing, it could be implemented by asking all three passwords in the same screen.

Something along these lines is done by my online broker where it asks for the member password and trading password during the login. We have to get both the passwords right in order to login. Besides, I have to change my member password every 10 days or so and there are rules about not repeating the previous three passwords, etc.

My bank (ICICI Bank) previously implemented two passwords, one for viewing to be entered to login and get access to information, and another for transacting to be entered anytime an action which would result in a financial transaction was performed. My Visa debit card is also secured by a system they call 3-D Secure where, irrespective of the payment gateway, they take me to their own site to enter a password to complete the transaction. I know that this is the genuine Visa site, because they let me customise the message to display.

So the idea is not unprecedented, though not implemented in exactly the same manner as you say. Adding multiple passwords is something that at least the bankers and stock brokers seem convinced about.

Deer Hunter
  • 5,327
  • 5
  • 34
  • 50
Kinjal Dixit
  • 131
  • 3
  • "Multiple passwords" is not the same thing as "multiple passwords where you don't acknowledge the correctness until all of them have been entered in the right order". It's even weaker, because an attacker can go after them one at a time -- the strength is roughly the same as the strength of the longest single password (see: WPS). – Mark Feb 26 '15 at 10:17
0

Stop useless technical complexity

According to a previously correct answer,

A\nB\nC

is approximately the same as

A B C

(or maybe lighter, regarding @Mark's answer, about Bruijn sequence).

From there, if you really need to keep your secret:

  1. Use standard tools strongly tested for a while. (If you're not sure, prefer to share and ask around, instead of using any kind of obscurity.)

  2. Keep them up to date.

  3. Teach your users about passphrases (see xkcd: Password Strength and discuss on IS)

  4. Keep in mind that social engineering (on Wikipedia) is the first way of security flaws. (Another famous xkcd: Security).

  5. Monitor your system, and check your logs.

Community
  • 1
F. Hauri - Give Up GitHub
  • 4,616
  • 2
  • 20
  • 32