[Cryptography] "password manager" --> _authorization manager_

[John Denker]

On 08/16/2014 04:38 AM, Michael Kjörling wrote:

> Off the top of my head, there are four or five passwords (which serve
> as anything much more than signposts) that I actually _remember_. Two
> are system login passwords where resorting to a password manager is
> not practical; one is the passphrase to unlock the password manager's
> database.

I do things the same way.

> It's nigh impossible to come up with passwords of high enough entropy
> to withstand an offline attack, _especially_ within the limitations
> sometimes enforced (maximum length, allowed character set, ...). And
> that doesn't even touch on trying to remember any significant number
> of such passwords. XKCD style (done right), Diceware and so on can
> help generate quite secure passphrases, but you still have to remember
> not just that one (or many) passphrase(s), but also _where to use each
> one_.

Agreed.

> Given how many people end up with passwords like "password1",
> "12345678" and so on, I think it isn't as much _passwords_ that need
> to be dealt with as password manager integration.

I appreciate the sentiment, but there may be better ways of
dealing with the details.

> Then, ideally, when I view a sign-up form that asks for a password,
> the password field would have some sort of visible indication

<snip>

The objective makes sense, but there may be better ways of getting
there.

The frequent discussions of "ideal" password schemes remind me of
the "optimal" way of eating vichyssoise with a fork.  There ain't
no such thing.  Spoons are more practical, and readily available.

In particular: a "password manager" is a small step in the right 
direction, but it is not a logical stopping point.  With the same
amount of workload on the user, the manager could be doing some 
sort of asymmetric crypto, so that there is never any need to 
transmit a password.
  a) Certificates are the most obvious way of doing this.
  b) If somebody absolutely needs compatibility with the idea of 
   "password", we could use some variant of PAKE;  for a list of
   variants, see
     http://en.wikipedia.org/wiki/Password-authenticated_key_agreement

==================

It is important to have a migration path.

To those who think this cannot be done, or who think it would be
unduly burdensome, here is a counterargument by way of analogy:

I run very little risk that any online merchant will compromise my
credit-card account, because my bank provides an app that generates
ephemeral credit-card numbers, one per transaction.  The virtual
card has a credit limit that suffices to cover that one transaction
and nothing more, so the merchant cannot overcharge me.  Also, the
virtual card is locked to a particular merchant, so even if the
balance is not used up, stealing the card number would be of no
use to anybody else.  I could safely publish all my past card numbers
on my web site.

There are some important ideas here, including:
  a) ease of use, and
  b) seamless compatibility with the huge installed base of vendors
   who ask for a credit-card number.

Part of the ease-of-use comes from the fact that the virtual card
app uses "automatic form filling" to stuff the card number, date,
cardholder name, etc. into the merchant's form.  This makes it
actually /easier/ to use than a non-virtual plastic card.

Furthermore it is vastly /more secure/ than a plastic card,
because in addition to identification and authentication, it
provides /authorization/ for a particular dollar amount.

Migration away from the existing addiction to passwords will not
be quite so smooth, but there is no doubt that it can be done.
The "automatic form filling" features can be put to good use
here.

So, can we please stop talking about the "password" manager?  Instead
let's call it an identification/authentication/authorization manager 
or something like that.  Let's keep eyes on the prize, the real prize.
The real objective is not the password.  The real objective is secure
identification, authentication, and /authorization/.

A password manager is a step in the right direction, but it is not
a logical stopping point.