[Cryptography] On mobile passwordless logins and established technologies

[Nico Williams]

Your approach is Persona-like, which IMO puts it on the right track even
though Persona failed.

My variation would be as follows:

 - clients enroll public keys for site-specific ad-hoc identities using
   per-site random PK key pairs

 - a user's devices can share these keys using a protocol for the
   purpose or can enrol multiple (1 per-device) keys for each identity

 - to the extent that sites wish to allow it their users could use their
   IDs elsewhere; for this a light-weight short-lived/fresh cert issued
   by the site's online issuer should suffice.

Note: no PKI in sight for client IDs.

I.e., Persona-like, with extensive device support.

http://www.mozilla.org/en-US/persona/

LoF/TOFU can be made workable, such that any MITM had better have been
in the middle at enrolment time and thereafter (for at least the
observed TACK periods for server credentials).  Insist on tack periods
of at least a week, use periodically so as not to miss rollovers, done.
No PKI in sight.  DANE and PKI for server auth don't hurt, to be sure,
but the combination of DANE, PKI, and LoF/TOFU would be quite strong by
comparison to the lame TLS server PKI.

The key is the ability to win trust over time.  Roughly how off-line
natural "authentication" works: recognition (here, online, with PK) +
trust building.

No passwords other than device unlock and/or recovery passwords.

No PKI.  Just Persona-like certs (if that; bare public keys should work
too).  If a site knows you well (e.g., you've made payments to them with
a credit card) they might vouch for you.

Problems:

 - Sites don't want a standard enrolment protocol that doesn't allow
   them to have highly customized interactions with prospective new
   users.  But any enrolment protocol would have to have a component
   that is completely standard and automated in mobile devices,
   otherwise we'd either not have universality or the UI would be very
   user un-friendly.

 - Mobile device OS vendors would have to agree on something rather
   important.  Either identity key sharing or facilitation of multiple
   key enrolments.  The latter actually wouldn't require much from
   mobile OS vendors... but it'd require more of users in terms of
   enrolment interactions.

   We'd still want to be able to share LoF/TOFU and other persistent
   state across devices, for extra security, but then we'd really need
   the OS vendors to cooperate.

 - Key rollover should be fine, but account recovery if you lose all
   your devices and recovery passwords -or if your devices are
   compromised- could be anywhere from difficult to impossible.  In the
   worst-case scenario the user would need new IDs and might not be able
   to do much to revoke compromised ones.

Persona just closed shop, so maybe this won't fly either, but IMO this
is the right approach.

On Mon, Mar 24, 2014 at 10:08:22AM +0100, Felix Ruzzoli wrote:
> I had a look at OAuth and OpenID and while in theory the idea seems
> [...]

I find them wanting.  They don't really help with the server
authentication problem, which is the hard one.

> I am wondering why people don't employ client-side SSL certificates
> for simple ID checking purposes? Someone please tell if I am wrong
> here..

Many reasons:

 - There's no need for a PKI for this, but TLS' user cert functionality
   is PKIX-based.  All pain, no gain.

 - Poor application/library integration on the client side.

 - Most importantly: lack of an enrolment protocol for ad-hoc
   identities.

See Persona.

> By just generating client certificates for each user of a (mobile)
> application on-the-fly and using them for ID checking we achieve
> passwordless logins with a good degree of security. Of course as
> long as the secret key is stored unencrypted on the device, the
> device acts like an ID token. Thus if the phone gets stolen the ID
> is too.

Yes.

> Of course backups of the ID could easily be done by encrypting the
> private key to a secret password. But at this point there seem to be
> no alternatives to letting the user input a secret.

a) enrolment has to be standard
b) sharing of identity keys and/ enrolment of alternate keys
   (per-device) needs to be standard
c) account recovery / revocation processes need to be solidly designed

> I claim this a feasible solution for your run-of-the-mill low
> security application which just needs a reliable way to
> differentiate between users and make sure it is not too easy to
> impersonate another user or break into his account.
> 
> What are your thoughts on this?

It's the correct approach, but getting all the relevant players to agree
is going to be like pulling teeth.  But then, who knows, it could
happen!  I'm willing to put some effort into it.

Nico
--