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 I've read about email being used this way, and seen it once or twice. While I
   7 can't remember any links right now, the basic idea is:
   8
   9 1. user enters email address into form
  10 2. response page says "a login link has been emailed to you"
  11 3. user opens email and clicks login link
  12 4. user is logged in
  13
  14 A few points to make this more secure:
  15
  16 * Only 1 login link should be active at a time; old ones won't work to log in.
  17 * A login link is only valid for a single login. Once it's used, it cannot
  18   be used to log in again.
  19 * A login link is only valid for a certain period of time. 24 hours seems
  20   like more than enough, and 12 hours would probably be plenty too.
  21   This timeout means a user doesn't need to worry about their email
  22   archives being used to log in.
  23
  24 Still, this could be attacked:
  25
  26 * If an attacker can access a user's inbox, they can generate a new login
  27   link, and log in as them.
  28 * If TLS is not used for the email transport, a MITM can snoop login links
  29   and use them.
  30 * If https is not used for the login link, a MITM can intercept and proxy
  31   web traffic and either steal a copy of the cookie, or use the login
  32   link themselves without letting the user log in. This attack seems no
  33   worse then using password authentication w/o https, and the solution is
  34   of course https.
  35 * If an attacker wants to DOS a wiki, they can try to get its domain, IP,
  36   whatever blacklisted as a spam source.
  37
  38 These attacks don't seem worth not doing it; many of the same attacks can
  39 be performed against openid, or passwordauth. Eg, reset password and
  40 intercept email.
  41
  42 Implementation notes:
  43
  44 * Use the email address as the username.
  45 * Sanitize the email for display in recentchanges etc.
  46 * The login link should be as short an url as possible, while containing
  47   sufficient entropy. Some email clients will let the user click on it,
  48   but some users will need to cut and paste.
  49 * The `adminemail` config setting has a bit of overlap with an `adminuser`
  50   set to an email address. Probably worth keeping them separae though;
  51   the `adminemail` is an email address to display, and we may not want to
  52   let anyone who can read the adminemail's mailbox to log into the wiki.
  53 * Will want to make passwordauth reject registrations that contain `@`.
  54   Otherwise, someone could use passwordauth to register as a username that
  55   looks like an email address, which would be confusing to possibly a
  56   security hole. Probably best to keep passwordauth and emailauth accounts
  57   entirely distinct.
  58 * Currently, subscription to comments w/o registering is handled by
  59   passwordauth, by creating a passwordless account (making up a username,
  60   not using the email address as the username thankfully). That account can be
  61   upgraded to a passworded account if the user follows a link in comment
  62   mails to login. So there is considerable overhead between that and
  63   emailauth.
  64 * Adapting the passwordauth reset code is probably the simplest way to
  65   implement emailauth. That uses a CGI::Session id as the entropy.
  66
  67 Thoughts anyone? --[[Joey]]