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