Subject: [Mathmesh] Alternative approaches to Web passwords

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Nov 2019 10:38:06 +0800

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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Nov 2019 16:05:57 +0800

Do you mean:
   Alternative approaches to Web passwords
or:
   Alternative use cases than Web passwords
   ??

    > Browser application and that is probably not the early adopter area.

I think that it's worth recasting this slightly.
The problem is not about synchronizing passwords between browsers on
different devices, but between enabling access between devices with full user
interfaces, and those with limited user interfaces.

I write access rather than passwords, because I believe that more and more
the "login with X" is really important.

My TV's netflix would like to login with facebook, but I really don't want my
facebook password to be simple enough that I'd be willing to type it in with
the TV's <->^V remote control keypad.

While netflix could (and maybe they do) solve this by having me login to
facebook and connect my account up from my laptop or phone, and then store
the resulting OAUTH token in their cloud, (and there are dozens of reasons
why this model is less desireable), the problem is that it does not
generalize to arbitrary services and arbitrary devices.

There are extensions (plugins) to many browsers that will let you send a URL
to your phone.  This usually uses the infrastructure of the phone makers. I
don't know if it works cross-browser/phone. (So Chrome->Android works, and I
imagine Safari->iPhone works, but I don't know about the other combinatorics)

I am imaging a system where it could be common to be able to send
authorization to your TV/fridge,ec.  We need to this in a standard way
because we don't expect all our IoT devices to run the same browser as our
desktop, nor for every member of the household who wants to do this to have
to run the same browser.

As a simple and direct use case, if I had a fridge with an LCD
display (I think you have one Phill) then it would be nice if the detailed
(not just public) calendars for all the members of the household were visible
on the LCD.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-