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?

  • 52
    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 7:46
  • 64
    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. – Justin Lardinois Feb 19 '15 at 8: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 8:27
  • 6
    @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
  • 6
    A regular password is just 'character knocking'. You have to put some characters in the right order... – Gusdor Feb 27 '15 at 8:52

17 Answers 17

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.

  • 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 0:10
  • 13
    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 0: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

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.

  • 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 9:03
  • 84
    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 9:28
  • 7
    @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
  • 11
    @IsmaelMiguel in other words, long passwords take longer to guess. – tylerl Feb 19 '15 at 20:15
  • 27
    To be more clear, if you consider typing this password in, your effective password is literally 123<Enter>456<Enter>789. 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 9:25

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.

  • 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 9: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. – Justin Lardinois Feb 19 '15 at 17:54
  • 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

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.

  • 6
    +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

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

  • 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 8: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 8:29
  • 8
    @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
  • 4
    @AviD I feel like this result must be patently obvious. Your password is literally now A <Submit> B <Submit> C. They are now simply concatenated by using the Return key. – Stephen Touset Feb 20 '15 at 0:58
  • 5
    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 0:12

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

  • 8
    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: 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. – Archimedix Feb 27 '15 at 18:10

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.

  • +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

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.

  • 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

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

  • 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 3: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 3: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

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.

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.

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.

  • 2
    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
  • 1
    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

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

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.

  • 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 1:11

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.

  • 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 3:50

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.

  • "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

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.

protected by Rory Alsop Feb 19 '15 at 23:31

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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