[Cryptography] client certificates ... as opposed to password hashing

[Jerry Leichter]

On May 26, 2014, at 7:14 PM, John Denker <jsd at av8n.com> wrote:
> Ideally, there are several properties we would like a
> password (and the surrounding system) to have:
>  a) Easy to remember over long times.
>  b) Easy to type in.
>  c) Sufficient entropy content.
>  d) Not shared between sites.
>  e) Resistant to passive eavesdropping.
>  f) Resistant to active MITM attacks.
>  g) Resistant to catastrophe, such as when Target or
>   eBay loses a huge database.
Passwords - or any authentication mechanism used by human beings - live or die on their user experience.  Note that your list only has two items, a and b, which address the user experience.  If you step back and think about how people want to use computers, you need to restate the ones you have and add others (keeping in mind that you wanted to describe an *ideal* system):

a')  Is consistent with human memory characteristics (difficulty in remembering large amounts of meaningless data, prone to forgetting over long periods without rehearsal, etc.)
b')  Does not require long or complex physical operations.
1)  Identifies the *person*, not the computer they log in from.
2)  Can be used by a person carrying no specific hardware.

If you look at historical real-world identification systems, they are mainly built to match these requirements.  There are compromises made in specialized, situations.  For example, opening safe doors may deliberately not match b'.  Entry gates for residential complexes often identify cars, not individuals (which can be a pain when you have guests).  But by far the most common one to compromise on is 2.  We carry physical keys, identity cards, credit cards.  But notice how often we "compromise on the compromise".  When the technology to build them became widely available, people started using combination locks on doors that would historically have had key locks.  If not specifically required not to, guards who are supposed to check ID cards historically will let people they recognize through without checking.  A credit card system that nominally relies on possession of physical token comes to be used over the telephone system and later on-line.  Phones use fingerprint sensors.  (Actually, fingerprint sensors have been used as an adjunct to password systems where people have to repeatedly and quickly log on to large numbers of distinct endpoints - think nurses and doctors logging on to access medical records in each patient room, something that's becoming increasingly common.)  So the pressure to implement 2, or as good an approximation to it as you can manage, is hard to resist.

Much traditional security is based on ad hoc implementation of biometrics (people recognizing other people's faces or voices) or knowledge of complex matters (speaking a particular language/dialect, appearing to know the right other people/names of departments/ways of referring to things).  Social engineering is often, perhaps almost always, about ways to hack such identification systems.  And note that such systems do a good job of implementing my list of UX requirements.

One interesting thing to note is that passwords as personal identification are an invention of the computer age.  Earlier uses of passwords were for group identification:  Soldiers in a particular (subgroup of) an army is the standard example.  Police departments often use a "color of the day" signal to identify themselves (very approximately and noisily) to other police.  Passwords in these roles are easy for attackers to observe and would be easy to guess, except that the nature of the usage makes guessing slow and risky.  So deliberately changing passwords frequently provides sufficient safety in the relatively limited security tasks they fulfill.  This is quite different from the way we've historically tried to use passwords in computer-based systems.

Yes, once you formalize and computerize and pack large amounts of information into very small, easily exfiltrated form, you find that it's impossible to actually build a system with all these properties.  It's not as if we haven't known this for years:  When we guard large amount of money or valuable information, we force people to put up with inconvenience (you must have and show your id card to enter, even though you and the guard have known each other for 5 years).  But that doesn't make the drive to meet these requirements any less.  It's why the *real* alternative to as-good-as-possible password systems isn't client certificates or magic one-time-signon, it's badly implemented password systems.  It's why, whatever the facts about their limitations, we're going to see biometric systems keep getting designed.

And there's another factor here, from the other side of the table as it were:  Businesses are leery of outsourcing their identity/security systems to others.  Something like the RSA (or other maker's) key fobs that generate one-time-passwords would be a great alternative (we're willing to carry physical keys most of the time if they are small and light enough, and you can imagine even better form factors for some people, like rings) - except that the alternative only works if I can carry *one* such fob, and that requires that everyone I identify to has to agree on using it - which no one has managed to make happen.

*Maybe* smart phones will end up providing the solution.  Maybe smart wearables will improve on it.  All speculative.  The hardest part of any proposal to replace passwords is the UX.  The technical parts are easy and have been understood for years.
                                                        -- Jerry