[OpenID] Choice of recovery method(s)

[Rabbit]

Our standard view of account recovery is really strange. My favorite  
example is Facebook which has security questions like "When is your  
mother's birthday?" which is the kind of question people actually turn  
to Facebook to answer in the first place!

OpenID recovery will probably need to be a little more creative. I  
don't presume to have the answer but here's my thoughts...

With login authentication off-shored to the OP I would imagine  
recovery authentication off-shored to recovery agent(s). I recommended  
something along these lines a few years ago but was met with negative  
feedback due to an obsession with having only 1 password and 1  
authentication point which I personally disagree with specifically for  
the use cases you've outlined as well as the "belly-up" case services  
like Stackoverflow encountered ( http://blog.stackoverflow.com/2010/04/openid-one-year-later/ 
  )

The way I envision this working is the OP would supply a default  
trusted recovery agent (RA) and optionally allow the user to edit or  
add multiple RA's.

The OP would then ask the user to set their recovery password which  
has to be different from the login password. The recovery password is  
not stored at the OP; instead it is sent to each of the RA's. To  
update the recovery password, the user must first enter their existing  
recovery password. This would create a system where User-to-OP and  
User-to-RA can authenticate.

When a user logs into a RP, the service can perform discovery to  
retrieve the users RA's.

When a user wants to do account recovery, they do it at the RP. The RP  
asks for the users OpenID and Recovery Agent. The User is redirected  
to the Recovery Agent where the user is asked to enter the recovery  
password for the supplied OpenID, upon success the user is sent back  
to the RP and the RA pings the OP to alert that recovery has been  
performed. The RP should then ask the user to replace their OpenID on  
file.

The reason I like this approach is minimal effort on the users end and  
it removes the single point of failure. The recovery password can not  
be used to sign into the OP and the RA is unaware of the users RP's  
until recovery is performed. I'm sure this can be improved upon.

=Rabbit

On May 11, 2010, at 5:29 PM, SitG Admin wrote:

> A recovery method is, in some circumstances, equivalent to a back  
> door; claim that the primary account has been hacked, and you trump  
> the trusted authentication method. If that primary authentication  
> method (let's assume OpenID) does get hacked, though, or turns  
> hostile/rogue (or is compromised/replaced), you *want* to be able to  
> override its authority somehow. OpenID gives users an account with  
> their OP (*it* worries about password recovery, to authenticate the  
> user), and that OP an account (more, if multi-user) with its RP  
> (*it* has to worry about password recovery, complicated by needing  
> to decide whether to authenticate the OP or the user), and the sheer  
> variety of password/recovery methods (and which might be reliably,  
> why/when) could take paragraphs if I tried to go into it all.
>
> The question I raise (for discussion) is whether security would be  
> improved by setting up for flexibility, and then permitting the  
> *user* to choose how their accounts would be configured for  
> authentication and recovery?
>
> -Shade
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general