[Mathmesh] Alternative approaches to Web passwords

[Phillip Hallam-Baker <[e-mail]>]

1) The Mesh Password Manager is not intended to be limited to the Web
Browser application and that is probably not the early adopter area.

2) Early adopter might well be SSH key management + functional passwords
for scripting etc.

That said, I began thinking through the issues of Web password security in
isolation last night and I think there is actually another approach that
doesn't involve the Mesh infrastructure that is a really low hanging fruit.

The core problem of Web passwords is that users have too many of them. 250
in my case (I just checked). So of course they are often repeated, that is
inevitable. And they are also horribly weak.

So my idea is a combination of HTTP Digest auth and the ideas in Russ
Housley's draft on Quantum security hardening of CMS.

Each user has at least one password salt that is generated with a decent
amount of randomness. It might look like this:

NCE2-VJXS-X5AR-BVRI-73HO-POOA-STAA

This is short enough to be typed in by the user when they change machines.
It is not quite a password though. It is a salt that we are going to add in
to every password the user enters.

So now we change the password dialogue so that when the user enters a
password in a particular form, a KDF with the supplied password as the IKM,
salted with the user nonce and then salted with the host domain is used.

So Alice goes to example.com, enters #password into the password box. The #
is recognized as meaning 'use the KDF scheme'

We then calculate the PRK:

PRK = KDF1('password'.UTF8(),
'NCE2-VJXS-X5AR-BVRI-73HO-POOA-STAA'.UDFData());

The password used is:

Password = Passwordify ( KDF2(PRK, 'example.com'.UTF8());

Where 'Passwordify' is a function that ensures the generated password meets
a generic profile (e.g. 16 chars, at least one upper, lower and symbol
character)

This approach is essentially password hardening for transport. There is
abundant prior art.

This approach can be used in combination with traditional password managers
but we now store the scope across which the password is used and the
constraints on the password generation profile rather than the password
itself.

What I like about this approach is that it allows me to divide my passwords
into two buckets, the ones that protect my assets and the ones that don't.
I make absolutely no apologies for not wasting my brain space remembering a
password for anyone else's benefit.

So NYT, the password I enter might be #, same for WaPo, etc. etc.

But for Fidelity it would probably be #mysecret which is giving an
additional bit of security above and beyond the embedded secret.

The main limitation of this approach is that it makes password sharing
between users very very hard. Which is quite possible a feature rather than
a bug.