Merge branch 'emailauth'

[git.ikiwiki.info.git] / doc / todo / emailauth.mdwn

diff --git a/doc/todo/emailauth.mdwn b/doc/todo/emailauth.mdwn
index fa3d26bfb92e51d2141c01f793e8e0d569412667..fa1995712b3f2896f1fb62e7533ccb25782813e8 100644 (file)
--- 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.
 
 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
 
 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:
 
 
 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
 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
 * 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
 * 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.
   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,39 @@ 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
   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.
 
   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]]
 Thoughts anyone? --[[Joey]]

+
+> 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...
+> 
+> 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]]