Please do not say "Two Factor"

Thirty years ago I wrote a list for my staff to address what I thought was sloppy and problematic use of special language.  It was of the form "Please do not say _______ when you really mean _______."  I cannot even remember many of the entries but one was "Please do not say 'privacy' when you really mean 'confidentiality.'" Another was "Do not say 'secure' when you mean 'protected."  While the distinctions may seem small, they are nonetheless useful.

In the spirit of that list, I would like to suggest that one should not say "two-factor," or "multi-factor" authentication when what one really intends is "strong authentication."  Strong Authentication is defined as "at least two kinds of evidence, at least one of which is resistant to replay."  Thus, all strong authentication is two-factor but not all two-factor authentication is strong.

For example, a password and a biometric is clearly two-factor but might not be strong.   It is more resistant to brute force attacks than a password alone but might be no stronger against a record and replay attack than the password alone. We are no longer seeing brute force attacks but credential replay attacks are a major problem.  If all one wants to do is resist brute force, adding bits to the password is likely to be more efficient than adding a biometric.

If one accepts that record and replay attacks are the greater problem, then one wants a second factor that resists replay, something like a one time password (OTP), whether token-based or sent out-of-band to a phone or mobile computer.

The use of  "two factor" enjoys so much currency that it suggests that any second form of evidence is the same as any other.  The irony is that RSA, the vendor of one of the original and most popular OTP token is one of the sources of that currency.  However, when they spoke of two factor, the first factor was the OTP.  The second factor a PIN used to resist fraudulent use of a lost or stolen token.

One popular "second factor" with banks is challenge-response based upon shared secrets.  The secret is established at enrollment time.  One popular method is to ask the user to select a number of questions from a list and record his own answers to those questions.  Questions may be similar to "what was the name of your first pet, school, or playmate?"  "In what hospital or city were you born?"  "What were the names of your grandparents?"  "The mascot of your high school?"  Answers should be easy for the subject to remember but not obvious except perhaps to an intimate.  At authentication time one question is chosen at random.  Actually this method can be resistant to replay provided that the set of questions is large enough relative to how often they are used. 

One bank started using this method only for large transactions, those above a threshold value.  However, they figured if it was good for large transactions, wouldn't it be better for all?  They lowered the threshold to zero.  Because the size of the set of questions was not large enough for this kind of use, all the answers for some accounts were soon compromised.  

The Verizon Data Breach Incident Report (DBIR) demonstrates that use of strong authentication would have resisted many of the breaches reported upon.  Because it is so powerful, we should be encouraging its use by all available means.  These means should include distinguishing between it and mere multi-factor authentication.