X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/c455d5155654c2dc107a267e0b7754cc585f39e9..bf8b7fe2d1602827f7419521d140bac4be6200a8:/doc/todo/emailauth.mdwn

diff --git a/doc/todo/emailauth.mdwn b/doc/todo/emailauth.mdwn
index fa3d26bfb..a164b783b 100644
--- a/doc/todo/emailauth.mdwn
+++ b/doc/todo/emailauth.mdwn
@@ -3,13 +3,20 @@ be dying on the vine, and no other replacements looking very likely (except
 for Oauth type stuff perhaps), it would be good to have a new easy way to
 log into ikiwiki, that doesn't need pre-registration.
 
-I've read about email being used this way, and seen it once or twice. While I
-can't remember any links right now, the basic idea is:
+Importantly, I want something that is not going to go
+the way of openid in the future. I think that email is here to stay; at
+least anyone who wants an email address is going to be able to get one in
+the forseeable future. (Google and large providers are making it harder to
+run small email systems, but it's still very possible, and there are at
+worst many large providers.)
+
+I've read about email being used for login auth, and seen it once or twice.
+While I can't remember any links right now, the basic idea is:
 
 1. user enters email address into form
 2. response page says "a login link has been emailed to you"
 3. user opens email and clicks login link
-4. user is logged in
+4. user is logged in until the cookie expires or is cleared
 
 A few points to make this more secure:
 
@@ -24,13 +31,14 @@ A few points to make this more secure:
 Still, this could be attacked:
 
 * If an attacker can access a user's inbox, they can generate a new login
-  link, and log in as them.
+  link, and log in as them. They are probably busy draining their bank
+  account by this method and not logging into some wiki though.
 * If TLS is not used for the email transport, a MITM can snoop login links
-  and use them.
+  and use them. Again probably more lucrative ways to exploit such a MITM.
 * If https is not used for the login link, a MITM can intercept and proxy
   web traffic and either steal a copy of the cookie, or use the login
   link themselves without letting the user log in. This attack seems no
-  worse then using password authentication w/o https, and the solution is
+  worse than using password authentication w/o https, and the solution is
   of course https.
 * If an attacker wants to DOS a wiki, they can try to get its domain, IP,
   whatever blacklisted as a spam source.
@@ -59,9 +67,35 @@ Implementation notes:
   passwordauth, by creating a passwordless account (making up a username,
   not using the email address as the username thankfully). That account can be
   upgraded to a passworded account if the user follows a link in comment
-  mails to login. So there is considerable overhead between that and
+  mails to login. So there is considerable overlap between that and
   emailauth.
 * Adapting the passwordauth reset code is probably the simplest way to
   implement emailauth. That uses a CGI::Session id as the entropy.
 
+----
+
+So this all seems doable. What I'm unsure about is this: Is emailauth going
+to be sufficiently easier than passwordauth that it will let users
+contribute to wikis who otherwise wouldn't?
+
+Using passwordauth, the user can register by just picking a password, and
+username, and entering email. That's 2 more things that need to be entered,
+but then there is no need to wait for an email link to arrive. Which can
+take a while, or be an unreliable, opaque process for users.
+
+OTOH, maybe some users don't want to have to make up a username and
+password, or pchycologically don't want to register. emailauth would then
+let them contiribute.
+
+I also have a motivation for ikiwiki-hosting/branchable. That needs the
+user to be able to log into the site, create their own wiki, and then log
+into their own wiki. Currently, openid is the only way to do that;
+emailauth would be another way.
+
+Another motivation from ikiwiki-hosting/branchable is that with google
+openid going away, many sites can have only google openids as adminusers, and
+that has to be manually dealt with. But if emailauth is added, those
+adminusers can be converted, perhaps automatically, to use the email
+addresses on record.
+
 Thoughts anyone? --[[Joey]]