doc/todo/emailauth.mdwn

   1 With many users no longer having an openid account, and Persona seeming to
   2 be dying on the vine, and no other replacements looking very likely (except
   3 for Oauth type stuff perhaps), it would be good to have a new easy way to
   4 log into ikiwiki, that doesn't need pre-registration.
   5
   6 Importantly, I want something that is not going to go
   7 the way of openid in the future. I think that email is here to stay; at
   8 least anyone who wants an email address is going to be able to get one in
   9 the forseeable future. (Google and large providers are making it harder to
  10 run small email systems, but it's still very possible, and there are at
  11 worst many large providers.)
  12
  13 I've read about email being used for login auth, and seen it once or twice.
  14 While I can't remember any links right now, the basic idea is:
  15
  16 1. user enters email address into form
  17 2. response page says "a login link has been emailed to you"
  18 3. user opens email and clicks login link
  19 4. user is logged in until the cookie expires or is cleared
  20
  21 A few points to make this more secure:
  22
  23 * Only 1 login link should be active at a time; old ones won't work to log in.
  24 * A login link is only valid for a single login. Once it's used, it cannot
  25   be used to log in again.
  26 * A login link is only valid for a certain period of time. 24 hours seems
  27   like more than enough, and 12 hours would probably be plenty too.
  28   This timeout means a user doesn't need to worry about their email
  29   archives being used to log in.
  30
  31 Still, this could be attacked:
  32
  33 * If an attacker can access a user's inbox, they can generate a new login
  34   link, and log in as them. They are probably busy draining their bank
  35   account by this method and not logging into some wiki though.
  36 * If TLS is not used for the email transport, a MITM can snoop login links
  37   and use them. Again probably more lucrative ways to exploit such a MITM.
  38 * If https is not used for the login link, a MITM can intercept and proxy
  39   web traffic and either steal a copy of the cookie, or use the login
  40   link themselves without letting the user log in. This attack seems no
  41   worse than using password authentication w/o https, and the solution is
  42   of course https.
  43 * If an attacker wants to DOS a wiki, they can try to get its domain, IP,
  44   whatever blacklisted as a spam source.
  45
  46 These attacks don't seem worth not doing it; many of the same attacks can
  47 be performed against openid, or passwordauth. Eg, reset password and
  48 intercept email.
  49
  50 Implementation notes:
  51
  52 * Use the email address as the username.
  53 * Sanitize the email for display in recentchanges etc.
  54 * The login link should be as short an url as possible, while containing
  55   sufficient entropy. Some email clients will let the user click on it,
  56   but some users will need to cut and paste.
  57 * The `adminemail` config setting has a bit of overlap with an `adminuser`
  58   set to an email address. Probably worth keeping them separae though;
  59   the `adminemail` is an email address to display, and we may not want to
  60   let anyone who can read the adminemail's mailbox to log into the wiki.
  61 * Will want to make passwordauth reject registrations that contain `@`.
  62   Otherwise, someone could use passwordauth to register as a username that
  63   looks like an email address, which would be confusing to possibly a
  64   security hole. Probably best to keep passwordauth and emailauth accounts
  65   entirely distinct. Update: passwordauth never allowed `@` in usernames.
  66 * Currently, subscription to comments w/o registering is handled by
  67   passwordauth, by creating a passwordless account (making up a username,
  68   not using the email address as the username thankfully). That account can be
  69   upgraded to a passworded account if the user follows a link in comment
  70   mails to login. So there is considerable overlap between that and
  71   emailauth.
  72 * Adapting the passwordauth reset code is probably the simplest way to
  73   implement emailauth. That uses a CGI::Session id as the entropy.
  74
  75 ----
  76
  77 So this all seems doable. What I'm unsure about is this: Is emailauth going
  78 to be sufficiently easier than passwordauth that it will let users
  79 contribute to wikis who otherwise wouldn't?
  80
  81 Using passwordauth, the user can register by just picking a password, and
  82 username, and entering email. That's 2 more things that need to be entered,
  83 but then there is no need to wait for an email link to arrive. Which can
  84 take a while, or be an unreliable, opaque process for users.
  85
  86 OTOH, maybe some users don't want to have to make up a username and
  87 password, or pchycologically don't want to register. emailauth would then
  88 let them contiribute.
  89
  90 I also have a motivation for ikiwiki-hosting/branchable. That needs the
  91 user to be able to log into the site, create their own wiki, and then log
  92 into their own wiki. Currently, openid is the only way to do that;
  93 emailauth would be another way.
  94
  95 Another motivation from ikiwiki-hosting/branchable is that with google
  96 openid going away, many sites can have only google openids as adminusers, and
  97 that has to be manually dealt with. But if emailauth is added, those
  98 adminusers can be converted, perhaps automatically, to use the email
  99 addresses on record.
 100
 101 Thoughts anyone? --[[Joey]]
 102
 103 > I had looked at something like this before, through [[todo/indyauth_support]] - which basically turned out to outsource their own auth to http://intridea.github.io/omniauth/ and http://indiewebcamp.com/RelMeAuth...
 104 >
 105 > But it seems to me that your proposal is basic "email opt-in".. the one impact this has on (drupal) sites i know is that spammers use even those forms to send random emails to users. it's weird, but it seems that some bots simply try to shove victim's emails into forms with the spam data as they can and hope for the best... it seems this could be vulnerable as well... - [[anarcat]]
 106
 107 >> Implemented now. [[done]]
 108 >>
 109 >> Only thing that we might want to revisit sometime is that the email address
 110 >> is used in git commits. While it won't be displayed on any static wiki
 111 >> pages (AFAICS), spammers could find it in the git commit log.
 112 >>
 113 >> Of course, spammers can troll git repos for emails anyway, so maybe
 114 >> this is fine. --[[Joey]]
 115
 116 >>> I'm not so sure this is OK: user expectations for "a random wiki/blog"
 117 >>> are not the same as for direct git contributions. Common practice for
 118 >>> websites is for email addresses to be only available to the site owner
 119 >>> and/or outsourced services - if ikiwiki doesn't work like this,
 120 >>> I think wiki contributors/blog commenters are going to blame ikiwiki,
 121 >>> not themselves.
 122 >>>
 123 >>> One way to avoid this would be to
 124 >>> [[separate authentication from authorization]], so our account names
 125 >>> would be smcv and joey even on a purely emailauth wiki, with the
 126 >>> fact that we authenticate via email being an implementation detail.
 127 >>>
 128 >>> Another way to do it would be to hash the email address,
 129 >>> so the commit appears to come from
 130 >>> `smcv <smcv@02f3eecb59311fc89970578832b63d57a071579e>` instead of
 131 >>> from `smcv <smcv@debian.org>` - if the hash is of `mailto:whatever`
 132 >>> (like my example one) then it's compatible with
 133 >>> [FOAF](http://xmlns.com/foaf/spec/#term_mbox_sha1sum).
 134 >>> --[[smcv]]a
 135
 136 >>> Email addresses are now cloaked in commits, using foaf:mbox_sha1sum. --[[Joey]]