<div dir="ltr"><div class="gmail_default" style="font-size:small">Reply to various points.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes... but who wants to start off trusting a completely new password manager??</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So I am looking at some slightly lower sensitivity applications first.</div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For password replacement, I think we need a two stage approach.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the requirements for this type of password vault are:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) Open specification, documentation</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3) Open service: Anyone can set up a service without permission from a central authority. People can run their own services.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Switching costs break both ways. They keep your existing customers in but they make it harder to expand as the customers wise up.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Current status is I have addressed the first three and have a plan for the fourth.</div></div>