[Cryptography] Passwords: Perfect, except for being Flawed

John Denker jsd at av8n.com
Wed Feb 18 16:55:35 EST 2015


On 02/17/2015 02:42 PM, Kent Borg wrote:
> 
> Passwords have serious problems, but they are bit like the problems 
> with one-time-pads: cumbersome--but otherwise perfect.

I would have said it differently:  Passwords are deeply 
flawed in principle, but convenient in practice.  An OTP 
is almost the opposite:  it is perfect in principle, but
inconvenient in practice -- often fatally so.

> Our use of passwords, on the other hand, is terrible. But all the 
> alternatives to passwords are worse.

Agreed.  A password, like a chainsaw, can be /used/ in 
lots of ways ... some good, some bad.  One has to think 
very carefully about how to use it.  Many things that 
look like they might be an improvement end up being 
unusable or worse.

> We should quit trying to craft fragile replacements and instead
> resign ourselves to cleaning up our act: quit reusing password the
> same passwords on different sites, pick good passwords, write them
> down our passwords, but otherwise keep them secret*.

It is better to light a candle
than to curse the damn darkness.
   http://www.buffyguide.com/episodes/outofmymind.shtml

For one thing, merely /telling/ users what to do is
not a solution.  That experiment has been done.  They 
cannot be relied upon to actually do it.  We need 
mechanisms that make it easier to do the right thing,
and harder to do the wrong thing.

More generally, we don't face a choice between "fragile
replacements" and doing nothing.  There are a lot of
ways to preserve a /user experience/ that looks like
a simple password, yet improves the results.

Back in the stone age, computers stored the passwords
directly in a file.  Then somebody got the bright idea
of storing a salted and hashed version.  This was an
improvement of the type I am talking about.  The change
was completely transparent to the users ... except that
they could no longer ask the sysadmin to remind them 
of their password.

Nowadays, we have the option of going to some sort
of zero-knowledge password authentication, which is
another step in the aforementioned direction.  It
means the user password is never on the vendor's 
site, not even momentarily.  This can be done in 
a way that is completely transparent to the user.

Seriously, it's a fairly simple syllogism:  Once 
you require people to have a whole slew of passwords,
it becomes advantageous to have a password manager,
and if you are going to do that, you might as well
do the full zero-knowledge dance.

Alas, this would require the vendors to have a clue,
so I don't expect it to happen anytime soon.  See
below for a stopgap.

> write them down our passwords,

Again, there are devilish details.  Note that 
it is a serious burden to have users choosing N 
passwords, keeping them from being lost, keeping 
them from being stolen, finding the right one 
when needed, not sending them to not-quite-right
sites, et cetera.  I consider that to be on the 
list of ideas that make things in some ways 
better but in some ways worse.

Personally, my approach is not to write them down,
but rather to compute them on the fly.  This is not 
as good as SRP, but it's way better than most of 
the lower-tech alternatives.  It is less convenient
but more secure than just using the same dumb password
everywhere.  Meanwhile it is more secure and 
tremendously more convenient than looking up the 
proper password in some file.
  https://cloud.av8n.com/security/passe-partout.pl

See also the limitations listed there.

As usual, the program is a few lines of crypto and
500 lines of user interface.  However, the interface
(crude as it is) is important.  Among other things, 
it makes it virtually impossible to send any given 
password to the wrong site.



More information about the cryptography mailing list