[messaging] Password reset mechanisms with an SRP authentication framework
dmb at arcode.com
Tue Apr 22 08:43:26 PDT 2014
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
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.)
Sent with [inky: <http://inky.com?kme=signature>]
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging