[messaging] Password reset mechanisms with an SRP authentication framework

[Tom Ritter]

There seems to be two problems here:

1) How to recover someone's password when they forget it
2) How to assert they have/had control of the account when they want
it deleted/recreated with the same name.

Have you considered an unprotected token on the user's device for #2?
Stored as a file or in HTML5 Storage as appropriate?  The token
doesn't allow access to the account, but possession of the token would
prove that the user either controlled the account during signup or
stole the token subsequent.  Combined with no activity on the account
for N days, you could use the token to migrate the account to a new
name (in case they remember their password) and create a new one with
the old name.  An attacker can DoS a user, could even see incoming
data until the situation is rectified, but not gain access to past
data.

-tom

On 22 April 2014 11:43, Dave Baggett <dmb at arcode.com> 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) 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
>
>
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>