Define an account recovery policy

[KellerFuchs]

We don't have any agreed-upon policy about how we handle users wanting to recover their account.

[RyanSquared]

From IRC, there was a solution discussed about managing this via GitHub; should we stick with that or provide a different solution? Also, if we do stick with GitHub, how can we prove a user is who they say they are.

[KellerFuchs]

AFAIK, there is no concrete proposal (using Github or otherwise).

[RyanSquared]

Just to boop this, so far I think the best way to do this is to provide a GitHub or Twitter username that can be used when registering a user. Thoughts?

[KellerFuchs]

@RyanSquared Github only, as we can easily pull SSH keys from a Github account.
(Though in principle, we could find GPG keys associated with a Twitter account using keybase or somesuch, and get authentication subkeys, but that might be hard to use for most people)

[RyanSquared]

(Though in principle, we could find GPG keys associated with a Twitter account using keybase or somesuch, and get authentication subkeys, but that might be hard to use for most people)

That implies that Twitter would be insecure for transferring the data. Is there any reason to trust GitHub and not trust Twitter?

[KellerFuchs]

1. Github is currently “trusted”, in the sense that they could serve bad content during the build of the LDAP container and use that vector to compromise our infra, though there is an issue about enforcing signatures
2. This wasn't at all about trustworthyness or security, but about the usability of the scheme: we can easily fetch keys associated to a Github account.

[RyanSquared]

Oh, alright, my bad. I don't suppose there's anyone who doesn't have a GitHub anyways, so at this point I'm probably all for going GitHub for verification. However, a new question comes up: how do we store it?

[KellerFuchs]

We have users who don't have a Github account, yes.

The easiest would be to make it an LDAP attribute (or in the data object, for userdb).