[Cryptography] Possible reason why password usage rules are such a mess

[Phillip Hallam-Baker]

Reply to various points.

Some of the password stupidity we suffer from today comes from the two
weeks after the release of Crack. At the time, UNIX password files were
world readable by default and anyone suggesting shadow password files was
the way to go was attacked for 'security through security'. Crack upped the
ante because it could make 6? 60? attempts a second and so a moderate sized
cluster of SPARCstations could test every password in a million entry
dictionary in a weekend.

And so the solution to this was to insist on the special characters which
increased the cost of a dictionary attack by an order of magnitude (sorta).
Only they don't because...

Modern cracking machines can do 600 billion attempts per second and exhaust
the Windows NT 4 password space in a few hours. And no, slower digest
functions are not a solution because there is simply no password that is
long enough to be secure that is short enough to be memorable. Battery
Horse Staple Correct is 2^60 bits of work factor. That is not strong enough.

So yes, we have to move away from human memorized passwords. And I have
been building a threshold PKI to make that practical. And it is very very
nearly complete. The current status is that all but 5 out of 400 unit tests
are passing. I should have the final unit tests cleared in a few weeks and
then be able to start deployment.

Yes... but who wants to start off trusting a completely new password
manager??

So I am looking at some slightly lower sensitivity applications first.

For password replacement, I think we need a two stage approach.

1) Long term has to be to move to public key based authentication for the
Web so that we don't expose the secret we are using as the basis of
authentication to authenticate.

2) Transition strategy has to be a password manager that provides end to
end security such that the cloud has no access to the stored passwords in
any form and is ubiquitous so that the user can access their password vault
from any device, any browser they authorize to access it. Only then can the
user start using machine generated passwords in place of memorized ones.

The first is actually a precondition for the second. Any system that
deploys the private keys necessary to make the password vault end to end
secure is also going to be able to support PKI based replacements for
passwords.

The second is what I am using the threshold encryption for. And I am now
very confident that I have the right model. I have tested out every part of
the system in isolation, I just need to complete the integration.


The hard part is making the vault 'ubiquitous'. Up to now, password vaults
have been proprietary solutions that are all about locking the user in to
one provider. I am all about giving the user autonomy. So the password
vault is going to need some sort of service to provide a synchronization
point between devices. But the user should have a free choice, not be
forced to pick iCloud or OneDrive or Google cloud because that is what
their Web browser is welded to. And having made a choice, users should be
able to change it any time they choose without any switching cost
whatsoever.

So the requirements for this type of password vault are:

1) True End to end security, only the user's devices ever have access to
the plaintext of the passwords. The cloud controls decryption (so it can
disable lost devices) but cannot decrypt.

2) Open specification, documentation

3) Open service: Anyone can set up a service without permission from a
central authority. People can run their own services.

4) Autonomy: Users can switch services at any time without changing their
call sign (aka address). If Alice switched from Verizon to Comcast, she
remains @alice

Note that making the service unsticky might well be the key to deployment.
A lot of people used their Comcast or Verizon emails when they first got
broadband. And the ISPs loved that because the customers were sticky -
changing providers meant an expensive change of email address. But
customers quickly realized that was a problem the first time they moved and
couldn't keep their old ISP. Hence the rise of Gmail etc.

Switching costs break both ways. They keep your existing customers in but
they make it harder to expand as the customers wise up.

Current status is I have addressed the first three and have a plan for the
fourth.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20201117/0b7451d5/attachment.htm>