[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.
The cryptography mailing list
cryptography AT metzdowd.com