[messaging] Password reset mechanisms with an SRP authentication framework

[Michael Rogers]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Dave,

I've recently been thinking about a similar problem for a P2P
messaging app I'm working on, where the messages and contact list are
stored on the user's device, encrypted with a key derived from her
password. If the user forgets the password, everything's lost.

The approach I'm considering may or may not be suitable for Inky -
it's based on some assumptions about users being able to meet face to
face, bringing with them the devices they use for messaging. But if
that sounds like it might be suitable for some of your users, here's
the idea:

* Derive a key from the user's password
* Split the key into n shares using a secret-sharing algorithm, such
that any k shares are sufficient to reconstruct the key, 2 < k < n
* Store two shares unencrypted on the user's device
* Give the other n-2 shares to trusted friends (this can be done
in-band, and the shares can be stored in the friends' own accounts)
* The friends don't have enough shares to reconstruct the key even if
they collude
* If the password is lost, the user has to collect shares from k-2 friends
* To collect a share, the user meets the friend face to face,
establishes a short-range confidential and authenticated channel, and
copies the share to her device
* The shares are collected on the user's device - the k'th share is
never written to disk, only held in memory while the key's reconstructed

I suspect few people will be willing to go to this much effort to
recover their keys, but it's the only solution I've been able to come
up with. Perhaps you could adapt it to your use case by storing the
shares in the user's other accounts (Dropbox, Google Drive, etc)?

Cheers,
Michael

On 22/04/14 16:43, Dave Baggett wrote:
> 
> 
> Hi all,
> 
> 
> 
> I'd love to get your collective thoughts on a challenge we have. We
> make the Inky mail client (http://inky.com) <http://inky.com%29/>
> and, not coincidentally, it embeds a version of trevp's tlslite,
> extended to do cert validation. Inky connects to our "mothership"
> server via tlslite using an SRP authentication scheme. (Not
> TLS-SRP, but something essentially similar.)
> 
> 
> 
> In a nutshell, we take the user's Inky password, key-stretch it
> using PBKDF2, and then use this as a key for AES-256 encryption;
> this allows us to store encrypted secrets on the user's behalf
> without us knowing what the secrets are. (Because the
> authentication is done via SRP, we don't know the user's Inky
> password, hence we don't know the key derived from it.)
> 
> 
> 
> One usability issue with this scheme, though, is that when users
> forget their Inky passwords, we can't do anything but wipe their
> account and let them repopulate it.
> 
> 
> 
> What we do now is allow users to set up a secret question / answer 
> combination on each device they have Inky installed on. I believe
> this is essentially the approach LastPass takes: you can reset your
> password using a client you've previously set up to do so.
> 
> 
> 
> The problem is that many users just skip the secret question /
> answer setup. Then when they forget their password, they can't
> reset it. And when they ask us to wipe their account so they can
> recreate it with the same user name — people actually care about
> the user name — we have no way of knowing they're actually the
> owner of the account.
> 
> 
> 
> So I'm soliciting clever ideas for ways to improve the usability
> without changing the fundamental security properties. (Or,
> alternatively, dire predictions about the feasibility of any such
> clever idea working.)
> 
> 
> 
> Dave
> 
> 
> 
> Sent with inky <http://inky.com?kme=signature>
> 
> 
> 
> 
> 
> _______________________________________________ Messaging mailing
> list Messaging at moderncrypto.org 
> https://moderncrypto.org/mailman/listinfo/messaging
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJTVpW7AAoJEBEET9GfxSfMrKkH/0V35vLhQsPuxAsXfM+c/VGa
HHTJ4liDSWMZJKAwi+A+q8zn2qk+JxJIsuS4HonuCbVykw40kMLhsQCX9NnVM+uD
AliZKIj1vbgLReJo6O3Xmv4f9STmrtrEuu4xxGl4FsusUioFOrJyeRFymj7t4uTO
euUzvF+yrzChfoRagCGLcPszUbSLQz6pFiWBX59EVNi33mumjlBlGBbHwIt2ODsK
a5p1rTFi0lYa9YhAOlcswei0C+UHKSrANeI7f3mD7c6dPDFlPeMZhOIf/jR3d8uk
JugWGGtkHeyJWNo69OwIwi0uGHxhV9Clj/xTbIbp/TBLeUaOKHtS0CFQ+QbHjf8=
=4OZi
-----END PGP SIGNATURE-----